CISCO Book

5259.
book Page i Thursday, October 10, 2002 5:39 PM
Troubleshooting Remote Access Networks

Plamen Nedeltchev, Ph.D.
201 W 103rd Street Indianapolis, IN 46290 USA
5259.book Page ii Thursday, October 10, 2002 5:39 PM
ii
Troubleshooting Remote Access Networks

Plamen Nedeltchev Copyright 2003 Cisco Systems, Inc. Published by: Cisco Press 201 West 103rd Street Indianapolis, IN 46290 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 November 2002 Library of Congress Cataloging-in-Publication Number: 2001096586 ISBN: 1-58705-076-5
Warning and Disclaimer

This book is designed to provide information about troubleshooting remote access networks. Every effort has been made to make this book as complete and as accurate as possible, but no warranty or tness is implied. The information is provided on an as is basis. The author, 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.
5259.book Page iii Thursday, October 10, 2002 5:39 PM
iii
Publisher Editor-in-Chief Executive Editor Cisco Representative Cisco Press Program Manager Cisco Marketing Communications Manager Cisco Marketing Program Manager Production Manager Development Editor Senior Project Editor Copy Editor Technical Editors
Team Coordinator Cover Designer Composition Indexer
John Wait John Kane Brett Bartow Anthony Wolfenden Sonia Torres Chavez Tom Geitner Edie Quiroz Patrick Kanouse Andrew Cupp Sheri Cain Cris Mattison Brian Feeny Brian Morgan William R Wagner Jonathan Zung Tammi Ross Louisa Adair Argosy Publishing Tim Wright
Corporate Headquarters Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706 USA http://www.cisco.com Tel: 408 526-4000 800 553-NETS (6387) Fax: 408 526-4100
European Headquarters Cisco Systems Europe 11 Rue Camille Desmoulins 92782 Issy-les-Moulineaux Cedex 9 France http://www-europe.cisco.com Tel: 33 1 58 04 60 00 Fax: 33 1 58 04 61 00
Americas Headquarters Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706 USA http://www.cisco.com Tel: 408 526-7660 Fax: 408 527-0883
Asia Pacic Headquarters Cisco Systems Australia, Pty., Ltd Level 17, 99 Walker Street North Sydney NSW 2059 Australia http://www.cisco.com Tel: +61 2 8448 7100 Fax: +61 2 9957 4350
Cisco Systems has more than 200 ofces in the following countries. Addresses, phone numbers, and fax numbers are listed on the Cisco Web site at www.cisco.com/go/ofces
Argentina Australia Austria Belgium Brazil Bulgaria Canada Chile China Colombia Costa Rica Croatia Czech Republic Denmark Dubai, UAE Finland France Germany Greece Hong Kong 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 2000, Cisco Systems, Inc. All rights reserved. Access Registrar, AccessPath, Are You Ready, ATM Director, Browse with Me, CCDA, CCDE, CCDP, CCIE, CCNA, CCNP, CCSI, CD-PAC, CiscoLink, the Cisco NetWorks logo, the Cisco Powered Network logo, Cisco Systems Networking Academy, Fast Step, FireRunner, Follow Me Browsing, FormShare, GigaStack, IGX, Intelligence in the Optical Core, Internet Quotient, IP/VC, iQ Breakthrough, iQ Expertise, iQ FastTrack, iQuick Study, iQ Readiness Scorecard, The iQ Logo, Kernel Proxy, MGX, Natural Network Viewer, Network Registrar, the Networkers logo, Packet, PIX, Point and Click Internetworking, Policy Builder, RateMUX, ReyMaster, ReyView, ScriptShare, Secure Script, Shop with Me, SlideCast, SMARTnet, SVX, TrafficDirector, TransPath, VlanDirector, Voice LAN, Wavelength Router, Workgroup Director, and Workgroup Stack are trademarks of Cisco Systems, Inc.; Changing the Way We Work, Live, Play, and Learn, Empowering the Internet Generation, are service marks of Cisco Systems, Inc.; and Aironet, ASIST, BPX, Catalyst, Cisco, the Cisco Certified Internetwork Expert Logo, Cisco IOS, the Cisco IOS logo, Cisco Press, Cisco Systems, Cisco Systems Capital, the Cisco Systems logo, Collision Free, Enterprise/Solver, EtherChannel, EtherSwitch, FastHub, FastLink, FastPAD, IOS, IP/TV, IPX, LightStream, LightSwitch, MICA, NetRanger, Post-Routing, Pre-Routing, Registrar, StrataView Plus, Stratm, SwitchProbe, TeleRouter, are registered trademarks of Cisco Systems, Inc. or its affiliates in the U.S. and certain other countries. All other brands, names, or 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. (0010R)
5259.book Page iv Thursday, October 10, 2002 5:39 PM
iv
About the Author

Plamen Nedeltchev was born in February 1954 in Silistra, Bulgaria. He graduated from high school as valedictorian in 1972. In 1980, he received an M.S. (Summa Cum Laude) from Saint Petersburg State Electro-Technical University. In 1989, he received his Ph.D. from the Bulgarian Academy of Science, Soa, Bulgaria. Plamen worked as the chief information ofcer of VMT (a division of the Ministry of Transport of Bulgaria) in his country of origin. He joined Sprint E-Solutions in 1999 as a senior network architect. The same year, he joined Ciscos Remote Access team as a technical consultant. During his career, he has published more than 40 publications in English, Russian, and Bulgarian, including four recent articles in the Cisco Packet Magazine. He speaks ve languages and has one technical patent. The scope of his technical expertise and interests includes bridging, switching, routing, capacity planning, compression, multicast, QoS, content networking, SOHO, ROBO, design/modeling/simulation, ISDN, Frame Relay, VPN, xDSL, cable modem, dial, wireless, and troubleshooting. In his spare time, he enjoys political history, philosophy, literature, sports, and music.
About the Technical Reviewers

Brian Feeny (CCIE No. 8036) is the senior network engineer for ShreveNet Inc., an Internet service provider, where he has been working for the last six years. He is also a Partner in Netjam LLC, which specializes in sales and support of Cisco network equipment. Brian has more than ten years experience in the networking industry. Brian Morgan (CCIE No. 4865) is a Cisco Press author (CCNP Remote Access Exam Certication Guide) and a frequent contributor in both editing and content. He has been in the networking industry for over ten years as a consultant in large internetworking environments. He has also spent much of the last ve years as an instructor for Cisco Learning Partners teaching ICND, BSCN/I, BCRAN, CATM, CVOICE, CCIE/CCNP bootcamps, and other courses. William R Wagner works as a Cisco Certied System Instructor for Skyline Computer Corp. He has 23 years of computer programming and data communication experience. He has worked for corporations and companies such as Independent Computer Consultants, Numerax, McGraw-Hill/Numerax, and Standard and Poors. He has teaching experience with the Chubb Institute, Protocol Interface Inc., Geotrain, Mentor Technologies, and he is currently teaching at Skyline Computers Corp. William also holds a degree in Computer Science, is a CNE, and currently holds his CCNA and CCNP from Cisco. Jonathan Zung (CCNP, CCDP, working towards CCIE) has been at Cisco for nearly ve years. He started at Cisco as a UNIX systems administrator, but for the last four years at Cisco, he has been working as a network engineer supporting Ciscos internal remote access environment. He graduated from California Polytechnic State University at San Luis Obispo with a B.S. in MIS and a minor in Computer Science in 1997. In addition to being one of the books technical reviewers who helped me with all phases to improve the content, Jonathan is the principal author of the design and troubleshooting content of Multi-Chassis Multilink Point-to-Point Protocol (MMP) in Chapter 10, ISDN Design Solutions and Chapter 12, ISDN BRI Troubleshooting of this book.
5259.book Page v Thursday, October 10, 2002 5:39 PM
Dedication
I dedicate this book to one of the most amazing people I have ever met, my wife Tatiana, for her sincere moral support and help through all these years. I dedicate this book to my kids, Nickolay and Irina, who make me a very proud father. Plamen
5259.book Page vi Thursday, October 10, 2002 5:39 PM
vi
Acknowledgments
To my managers: This book wouldnt be possible if I didnt have the continuous and unconditional support of my managers: Felicia Brych, who devoted her time for months to make this book happen, and Chuck Trent and Henry White, who encouraged me and created an unmatchable atmosphere of trust and encouragement to ensure the success of this project. Special appreciation goes to my Sprint E-Solutions manager, Debra Wieland, and to Chris Starsiak for believing in me and for the support. To the Cisco Press team: Many thanks to Brett Bartow for giving me the chance to write for Cisco Press, and Drew Cupp for his assistance, persistence, and remarkable language skills during the creation of this book. I would also like to thank Sheri Cain for her excellent work in managing this book through the production process. Finally, I want to thank Jill Batistick, Ginny Bess Munroe, Christopher Cleveland, Cris Mattison, Doug Ingersoll, and Marianne Huff for providing me with assistance, formatting, and editing the content, improving the language, and for technical corrections. To the technical editors of this book: My special appreciation goes to Brian Feeny (CCIE No. 8036), Brian Morgan (CCIE No. 4865), Bill Wagner (CCSI), and especially to Jonathan Zung (CCDP, CCNP) for their valuable comments, devotion and time, and helping me to make this book better. To my colleagues who helped write and edit: Many thanks to my colleagues from the Remote Access team at Cisco, who are some of the most talented engineers Ive ever worked with in my carrier. All of them are at different stages of achieving the highest Cisco certications, but all together, they make what usually is referred to as The Team and as such, everyone has their own technical strengths, preferences, and proven techniques. Some of them have written part of this book, some of them have reviewed the content, and some of them did both. Overall, sharing this collective experience, in my understanding, adds value to this book and serves the readers needs best. As a result, this book includes only the proven best practices type of information and proven troubleshooting scenarios from more than tens of thousands of cases in the recent years. I would like to thank the following team members and note their contributions to this book: Felicia Brych (BComm, MPM) is from Canada and holds degrees from Memorial University of Newfoundland and the University of Quebec. Felicia managed Ciscos Internal Remote Access Services department from December 1999 to August 2001, with successes that included the global deployment of VPN and signicant cost reduction for all remote access solutions. Prior to working for Cisco, she managed Remote Access and Technology Services for Revenue Canada. Felicia currently leads IT initiatives involving collaboration infrastructure and IP telephony for the home. In her spare time, Felicia enjoys gardening and spending time with her husband, three stepchildren, and two Labrador Retrievers.
5259.book Page vii Thursday, October 10, 2002 5:39 PM
vii
Felicia is the principal author of the foreword and the Management Considerations section for Chapter 1 of this book. Felicia edited the entire content of this book for style and language. Chuck Cardamon is an IT analyst in Infrastructure, Carrier Services & Provisioning. He has an AOS degree in Culinary Arts and is a veteran, retiring as a U.S. Navy SEAL after 20 years of service. He is a proponent of organ donation and was a live liver donor to save the life of a friend. In his spare time, he rides motorcycles and y shes. He has been married for 26 years and has 4 adult children. Chuck is the principal author of the Provisioning of Enterprise Remote Access Services section for Chapter 1. Jered T. Huegen is a network engineer supporting remote access services for Cisco Systems. He has been working towards his CCIE in Communications and Services and passed the written exam. Jered has helped to facilitate the growth of the remote access infrastructure from a few hundred clients to accommodate 40,000 clients. He has a college background in math and accounting. In his spare time, Jered enjoys being a pit crewmember and making split-second setup decisions for a dirt-track race team. He was married in September 2002. Jered is the principal author of the following chapters: Chapter 5, Dial Technology Background Chapter 6, Dial Design and Conguration Solutions Chapter 7, Dial Troubleshooting Chapter 8, Dial Troubleshooting Scenarios
Omid Kaabipour (CCNA) has a B.S. in Business Administration (MIS) from San Jose State University. As a lead engineer for Frame Relay with the Remote Access group, he participated in design, support, and troubleshooting Frame Relay, ISDN, VPN, and Dial. Recently, Omid has been working with the Cisco Northeast Transport Group on transport technologies across a wide range of Cisco platforms, including WAN, LAN, MAN and Frame Relay troubleshooting, design, and maintenance. In his spare time, he thrives on listening to classical music and enjoys going to movies. Omid is the principal author of the Frame Relay host migration scenario in Chapter 18 of this book and helped with the technical review of this book at its nal phase. David Iacobacci is a network engineer in the Cisco IT Remote Access Services group and has been the technical lead of the team for about two years. He has been working toward his CCIE in Security. A native New Yorker, he lived in Japan for over nine years, working for Nihon Cisco Systems and Procter & Gamble Far East, Inc., after obtaining an MBA from the International University of Japan. He also holds a BS in Mechanical Engineering from Rutgers University and has worked for Citigoup, FMC Corporation, and the U.S. Navy. When not working, David enjoys his free time with his wife and daughter.
fm.fm Page viii Monday, October 14, 2002 1:34 PM
viii
David is the principal author of the following chapters: Chapter 20, Remote Access VPN Design and Conguration Solutions Chapter 21, Remote Access VPN Troubleshooting
Zack Schaefer (CCNP, CCDP) is currently working on his CCIE. He has spent a majority of his post college career working for Cisco in its Remote Access department. Throughout his entire career at Cisco, he has helped support Ciscos entire VPN infrastructure, solving thousands of VPN problems yearly. He is currently a network engineer supporting WAN, LAN, MAN, and remote access for Latin America and the Central and Southeast United States. Additionally, he routinely performs VPN troubleshooting training for fellow Cisco employees. Zack is the principal author of Chapter 22, Remote Access VPN Troubleshooting Scenarios. James Michael Thompson (CCNP, CCDA) made a move from the music industry to the networking industry in the late 1980s. Before working with the Cisco Remote Access team, Jim worked as a WAN engineer and as a CNE at a network integration company. Jim passed the CCIE qualifying exam and is scheduled to take the lab exam in the near future. He lives in Sonora, California, with hobbies such as photography, hiking, mountain biking, kayaking, and still enjoys making music. Jim helped with the technical review of this book at its nal phase. Lainie van Doornewaard has been with Cisco Systems, Inc. for approx. ve and a half years after leaving a career in law enforcement. She worked as the team lead for support for the engineering community, then joined the Network Operations Team, which is responsible for Ciscos corporate LAN, WAN, and MAN infrastructure. She transferred to the Remote Access team in July of 2000 and has been the backup engineer for VPN and lead engineer for xDSL for almost two years. She is currently a team lead for the Remote Access Engineering team in San Jose. Lainie helped with the technical review of this book at its nal phase. Id like to acknowledge the contributions of some of the founders of the Remote Access environment at Cisco: Yinpo Wong, BS, BA, MBA, currently Engineering Manager at Cisco Systems, Inc., John B Cornell III, currently Member of Technical Staff (IT) at Cisco Systems, Inc., and Craig Huegen, CCIE #2100, who is currently Chief Network Architect for Cisco Systems . Finally, this book enjoyed the encouragement of many people, and Id like to thank Dave Holloway, Kristine Smith, Lanny Ripple, Julie Martinez, Jeff Galisky, Terrance Blackman, Lilyan Gonzalez, Albert Soeherman, Diana Perez, Sidney Thompson, Damian Morris, Al Roethlisberger, Jawahar Sivasankaran (CCIE 8870), Doug Gober, Kathleen OLooney, and many others.
5259.book Page ix Thursday, October 10, 2002 5:39 PM
ix
Contents at a Glance
Foreword xxiii xxv Introduction Part I Chapter 1 Chapter 2 Chapter 3 Chapter 4 Part II Chapter 5 Chapter 6 Chapter 7 Chapter 8 Part III Chapter 9 Chapter 10 Chapter 11 Chapter 12 Chapter 13 Part IV Chapter 14 Chapter 15 Chapter 16 Chapter 17 Chapter 18 Remote Access Fundamentals 3 Remote Access Overview 5 Telecommunication Basics 37 The Cloud 69 Troubleshooting Approaches, Models, and Tools 95 Dial 123 Dial Technology Background 125 Dial Design and Configuration Solutions 141 Dial Troubleshooting 181 Dial Troubleshooting Scenarios 219 ISDN 231 ISDN Technology Background 233 ISDN Design Solutions 257 Cisco ISDN Configuration Solutions 289 ISDN BRI Troubleshooting 313 Troubleshooting Scenarios for ISDN BRI 359 Frame Relay 411 Frame Relay Technology Background 413 Frame Relay Design Solutions 433 Basic and Advanced Frame Relay Configurations 457 Frame Relay Troubleshooting 491 Frame Relay Troubleshooting Scenarios 547
5259.book Page x Thursday, October 10, 2002 5:39 PM
Part V Chapter 19 Chapter 20 Chapter 21 Chapter 22 Appendix A Index 835
VPN 589 VPN Technology Background 591 Remote Access VPN Design and Configuration Solutions 633 Remote Access VPN Troubleshooting 675 Remote Access VPN Troubleshooting Scenarios 765 Answers to Review Questions 807
5259.book Page xi Thursday, October 10, 2002 5:39 PM
xi
Contents
Foreword xxiii xxv 3 Introduction Part I Chapter 1 Remote Access Fundamentals Remote Access Overview 5
Management Considerations 6 Cost 6 Availability 7 Support 7 In-Sourcing Versus Outsourcing 7 Billing and Charge Backs 7 User-Managed Versus Corporate-Managed Security 8 Applications 8 Home Access Versus Mobility 8 Defining the Remote Access User Population Remote Access Service Options 9 Analog Dialup Services 12 ISDN Services 14 Frame Relay Services 17 VPN Services 18 VPN Service Vehicles 20 Cable Modem Services 20 xDSL Services 22 Wireless Broadband Services Satellite Services 28 9
25 30
Provisioning of Enterprise Remote Access Services Summary 35 35 37 38
Review Questions Chapter 2
Telecommunication Basics Shannons Capacity Theorem
Modulation and Line-Coding Techniques in Wired Networks Amplitude, Frequency, and Phase Modulations 40 Quadrature Amplitude Modulation 41 xDSL Coding Techniques 42
39
5259.book Page xii Thursday, October 10, 2002 5:39 PM
xii
Modulation and Line-Coding Techniques in Wireless LANs 44 Infrared 45 Ultra-High Frequency Narrowband Technologies and WLAN Synthesized Radio Technology 46 Multiple Frequency Operation 46 Ultra Wideband and WLANs 47 WLAN Modulations and Coding Techniques 48 Modulation and Line-Coding Techniques in Hybrid Networks Clocking, Line Coding, and Framing in Carrier Systems 54 Clocking 55 Pseudo-Ternary and Two Binary One Quaternary Signaling T1 Digital Coding and Framing 59 T1 and T3 Framing 62 PRI1.544-Mbps Interface 64 PRI2.048-Mbps Interface 65 End Notes Summary 66 66 66 53
46
55
Review Questions Chapter 3 The Cloud 69
Carriers, Service Providers, and How Traffic Is Carried FDM 71
69
Digitalization of the Signal and Pulse Code Modulation TDM 73 75
72
T-Carriers 75 T1/E1 and Primary Rate Interfaces, T1s, and DS T1s and DS and TDM Hierarchy 77 E1 77 Network Signaling Systems and SS7 78
SONET, Synchronous Transport Signal, and Synchronous Digital Hierarchy The Optical Fiber Hierarchy of Circuits 80 Carriers Facilities and Switching Systems 80 First-Tier Exchange Carriers 80 Inside the CO 81 Second Layer Exchange CarriersIXC 81 Switches and Tandems 82 LEC/IXC Operations 82 Tandem Office and Tool Office 83
79
5259.book Page xiii Thursday, October 10, 2002 5:39 PM
xiii
ISPs and ASPs
85 87
Data Centers and Internet Hosting Services The Future of Service Providers 89 Service Offering 90 The Last-Mile Problem 90 The 3G Wireless Alternative 91 End Note Summary 92 92 92
Troubleshooting Approaches, Models, and Tools Interconnection Models 96 Department of Defense Model Seven-Layer OSI Model 98 97 101
95
Troubleshooting Models and the Baseline Troubleshooting Models 101 The Baseline 103
Common and Cisco-Specific Tools 109 Ping and Privileged (Extended) Ping Commands 110 The Traceroute and Privileged (Extended) Traceroute Commands The Netcat Utility 115 Service Assurance Agent 117 The IOS Commands show and debug 118 End Notes Summary 119 119 119
114
Review Questions Part II Chapter 5 Dial 123
Dial Technology Background Overview of Modems 125
125
Telco Issues 128 Digital Pad 129 Line Code Errors 130 Authentication Options 132
5259.book Page xiv Thursday, October 10, 2002 5:39 PM
xiv
PPP 134 Link Dead (Physical Layer Not Ready) 135 Link Establishment Phase 135 Authentication Phase 136 Network Layer Protocol Phase 136 Link Termination Phase 137 PPP Troubleshooting Considerations 137 End Notes Summary 138 138 138 141
Dial Design and Configuration Solutions Dial Design Solutions 142 Text Dial-In Network 143 PPP Dial-In Network 143 Text Dial-Out Network 144 PPP Dial-Out Network 145 Large-Scale Dial-Out Network 146 Dial-On-Demand Backup Network 147
Dial Configuration Solutions 149 Text Dial-In Configuration 150 PPP Dial-In Configuration 151 Large-Scale Dial-In Configuration 159 Text Dial-Out Configuration 164 PPP Dial-Out Configuration 168 Large-Scale Dial-Out Configuration 171 Dial-On-Demand Backup Configuration 173 Summary 177 177 181
Dial Troubleshooting
Troubleshooting NAS WAN Links 181 Troubleshooting T1 Circuits 181 Troubleshooting PRI Circuits 188 Troubleshooting Dial-In Service 190 Step One: Verify that the Modem Is Ready to Accept Calls Step Two: Verify Type of Incoming Connection 192 Step Three: Verify PPP Negotiation 194 191
5259.book Page xv Thursday, October 10, 2002 5:39 PM
xv
Troubleshooting Dial-Out Service
200
AS5x00 Specific Commands and Debugs 205 AS5200 Specific Commands and Debugs 207 AS5300 Specific Commands and Debugs 209 AS5400 Specific Commands and Debugs 214 Summary 215 215 219 219 221 221
Dial Troubleshooting Scenarios
Scenario 1: Authentication Time OutsPart I Scenario 2: Authentication Time OutsPart II Scenario 3: Frequent Retrains and Disconnects Scenario 4: Dirty Phone Line Scenario 5: Bad Modem 225 226 223
Frequently Asked Questions and Answers Summary Part III Chapter 9 ISDN 228
231 233
ISDN Technology Background ISDN Standards 233 E-Series 233 I-Series 234 Q-Series 234 ISDN Channels 234
ISDN Planes: ISDN Layer Architecture 236 Layer 1: BRI 237 The Layer 2 D Channel: LAPD 242 Layer 3 in the D Channel: Q.931 and Message Format ISDN Switch Types Summary 253 253 252
248
Review Questions
5259.book Page xvi Thursday, October 10, 2002 5:39 PM
xvi
Chapter 10
ISDN Design Solutions
257
Enterprise and ISP Designs 258 Setting the ISDN Switch Type 259 Setting SPIDs and LDNs 260 IP Pool Design 262
NAT and PAT 265 PAT 266 NAT 267 Per-User (Per Function) Configuration Virtual Interface Templates 272 Virtual Profiles 273 MLP 273 272
MMP 278 MMP Configuration 281 MMP Sample Implementation Verifying MMP 284 Summary 285 286
282
Cisco ISDN Configuration Solutions
289
Cisco ISDN Cost-Effective Solutions 289 Spoofing 290 Snapshot Routing and OSPF Demand Circuits DDR 293 PPP Callback for ISDN 303 ISDN Security 305 306
290
Configuring the POTS (Telephone) Interfaces Creating Dial Peers 307 Advanced Telephone Features 308 Summary 310 310 313 314 319 324
ISDN BRI Troubleshooting
Troubleshooting the Physical Layer Troubleshooting the Data Link Layer Troubleshooting the Network Layer
5259.book Page xvii Thursday, October 10, 2002 5:39 PM
xvii
Troubleshooting PPP 335 Troubleshooting PPP LCP 335 Troubleshooting PPP Authentication 340 Troubleshooting PPP Network Control Protocols PPP: Termination of the Connection 352 Troubleshooting Telephone Interfaces End Notes Summary 356 356 356 359 353
341
Troubleshooting Scenarios for ISDN BRI
Recommendations for Practical Troubleshooting of ISDN Remote Services Using #show isdn status to View Service Layers 360 Preconfiguring the Routers on Both Ends 364 Accessing the Remote Users Router 365 Scenario 1: New Install Problems Scenario 2: Dial-Out Problems 369
359
372
Scenario 3: ISDN Performance Problems 376 Short-Term Routing Issues 377 Line Problems 377 Configuration Setting Problems 382 LEC Switch Problems 382 Scenario 4: End-to-End Communication Problems 386 The LECs ISDN Switch Settings 387 LCP Problems and the Magic 22 Seconds 387 Authentication Problems 396 End-to-End Routing Problems 399 Scenario 5: Windows 2000 DDR Issue 399 Step 1: Implement the Manufacturers Recommendations and Determine if They Are Effective 400 Step 2: Monitor and Sniff All Traffic and Try to Find Patterns and Characteristics of the Traffic 402 Step 3: Use a Cisco Knowledge Base to Remedy any Identified Problems 406 Step 4: Select a Solution and Test It 407 Summary 408
5259.book Page xviii Thursday, October 10, 2002 5:39 PM
xviii
Part IV Chapter 14
Frame Relay
411
Frame Relay Technology Background 413 Frame Relay Standards 415 417
Frame Relay Service Architecture Frame Relay Protocols LAPF 419 End Notes Summary 429 429 429 419
Frame Relay Design Solutions 433 Design Parameters 434 CIR Options 435 UNI 438 NNI 438 Voice over Frame Relay 440 Frame Relay Multicast 440 Frame Relay Topologies and Congestion Control 441 Partial-Mesh and Full-Mesh Frame Relay Designs 441 User and Frame Relay Switch Operations Under Congestion Congestion and Windowing 443 Frame Relay Performance Criteria 444 Frame Relay and Upper-Layer Protocols 445 Encapsulating IP, Q.933, and SNAP 447 Encapsulating Other Protocols over Frame Relay Frame Relay Fragmentation 448 LMI 449 Consortium (Cisco) LMI Type 451 Annex D (ANSI) LMI Type 451 ITU-T Q.933 Annex A LMI Type 453 Address Resolution: ARP, Reverse ARP, and Inverse ARP ARP 453 Reverse ARP 454 Inverse ARP 454 End Notes Summary 454 455 455 453
441
448
Review Questions
5259.book Page xix Thursday, October 10, 2002 5:39 PM
xix
Chapter 16
Basic and Advanced Frame Relay Configurations Basic Frame Relay Configurations 458 Point-to-Multipoint Configurations 458 Point-to-Point Configurations 461 Maximum Number of DLCIs Per Interface 466 Routing Protocols and Frame Relay Configurations Frame Relay Broadcast Queue 468 Advanced Frame Relay Configurations 469 Configuring IP Unnumbered Frame Relay 469 Frame Switching 469 Frame Relay and ISDN Backup Configuration 471 Frame Relay and Bridging 474 Frame Relay Compression 476 Frame Relay and IP Multicast Configuration 482 Frame Relay and Traffic Shaping 483 Summary 488 489 491
457
467
Frame Relay Troubleshooting
Beginning the Frame Relay Troubleshooting Process
492
Physical Layer Troubleshooting 493 Line and Clocking Problems 493 Serial Interface 0 and Line Protocol Is Down 498 Performance Issues Related to the Physical Layer 501 Data Link Layer Troubleshooting 506 PVC Configuration Issues 507 LMI Issues 513 Performance Problems 526 Flapping Links 526 End-to-End Problems 528 Frame Relay Shaping Problems 534 Troubleshooting Compression Over Frame Relay End Notes Summary 544 544 544
537
Review Questions
5259.book Page xx Thursday, October 10, 2002 5:39 PM
xx
Chapter 18
Frame Relay Troubleshooting Scenarios Scenario 1: New Install Issues 548 556
547
Scenario 2: Mismatched DLCI Settings
Scenario 3: Performance Issues from Flapping Lines and Traffic Shaping Issues Flapping Lines 563 Traffic Shaping Issues 566 Scenario 4: IP Multicast Issues in Frame Relay Scenario 5: Frame Relay Host Migration Working with Your Vendor 580 Preparing the Host 581 Routing Options 583 Endpoint Migration 584 Summary Part V Chapter 19 VPN 589 591 591 585 580 573
562
VPN Technology Background
Service Provider, Dedicated, and Access VPNs Enterprise VPNs Overview 593
Enterprise VPN Categories 595 Functional VPN Categories 595 Technology Category 598 Network Layer (Layer 3) VPNs 604 Layer 3 Tunneling 605 Security Associations and Security Policy for IKE and IPSec 605 Negotiations of ISAKMP and IPSec Phases and Modes 607 Mutable and Immutable Fields and the ICV 608 Fragmentation, Path MTU Discovery, and ICMP Processing 610 IPSec Modes 612 IPSec Protocols 613 Authentication in VPN 619 End Notes Summary 628 629 629
Review Questions
5259.book Page xxi Thursday, October 10, 2002 5:39 PM
xxi
Chapter 20
Remote Access VPN Design and Configuration Solutions
633
Remote Access VPN Design Solutions 633 Remote Access VPN Design Objectives 634 Remote Access VPN Management 635 Remote Access VPN Security Considerations 636 Remote Access VPN Termination Equipment Design Considerations VPN Configuration Considerations 648 Configuration of the VPN 3000 Concentrator Cisco Remote Access VPN Clients 662 End Notes Summary 671 672 672 675 676 648
641
Remote Access VPN Troubleshooting
Troubleshooting Cisco Remote Access VPN Clients Cisco VPN Unity SW Client 676 Cisco 3002 HW Client Troubleshooting 706 Cisco Easy VPN Client 713 Cisco PIX VPN Client 721
Internet Technologies and Remote Access VPNs 732 VPN and ADSL 732 VPN and Internet Access Through a Cable TV Infrastructure 740 VPN and Internet Access over Satellite and Wireless Systems 745 LAN and General Networking Issues Affecting Remote Access VPNs 753 Multiple VPN Clients Behind a NAT Device 753 MTUA Critical Factor for Troubleshooting Internet IPSec Connectivity Slow or Inaccessible Login to Kerberos Active Directory 760 End Notes Summary 761 761 762
754
Remote Access VPN Troubleshooting Scenarios 765 Warming Up with Preliminary Troubleshooting Steps 766 Step 1: Determine if There Is an Internet Connection 767 Step 2: Ensure that the VPN Client Is Properly Installed 771 Step 3: Check or Create Your Profiles 772
5259.book Page xxii Thursday, October 10, 2002 5:39 PM
xxii
Scenario 1: Cannot Authenticate 773 Case 1: Bad Group Name or Group Password 774 Case 2: Prompted Multiple Times for Username and Password Case 3: Firewall Software 777 Case 4: MTU Set High 779 Case 5: MTU Set Low 784 Scenario 2: Can Authenticate but Problems Passing Data 784 Case 1: Cannot Pass Traffic and Using NAT Connection Entry Case 2: MTU Causing Packet Loss 786 Case 3: Connection Keeps Dropping 786 Case 4: Cannot Browse the Internal Domain 787 Scenario 3: PPPoE Software/Hardware Problems Case 1: PPPoE Software Issues 791 Case 2: IOS-Based PPPoE Issues 793 790
775
785
Scenario 4: 3002 Connection Problems 795 Check the Interfaces Status on the 3002 797 Confirm the Group Name and Password Are Correct Problems with User Authentication 800 Scenario 5: Extranet Issues 801 Protocol 50ESP 801 UDP 500ISAKMP 801 UDP 10,000 (Allow IPSec Through NAT) Tunnel Keepalives 802 Dead Peer Detection 803 Summary Appendix A Index 835 805 807
800
802
Answers to Review Questions
5259.book Page xxiii Thursday, October 10, 2002 5:39 PM
xxiii
Foreword
Cisco Systems Inc. is built on the philosophy of changing the way we work, live, play, and learn. The ability to telecommute and work remotely from any location is a large part of this change. Telecommuting is not a new concept; employees have been able to work remotely for decades. Signicant benets are associated with this practice. Today, the ability to be productive while working remotely can occur only when required ofce applications and tools are accessed and used as if you were physically present in the ofce. The early days of dialup networking are replaced with high-speed access to the home at prices that are more cost effective. The requirement to telecommute and to access the corporate network while on business travel has played a signicant role in creating an entire industry around remote access. Future trends include more prevalent broadband connectivity available from hotels, airports, and other public locations. Over the last ve years, the Information Technology organization of Cisco Systems created and maintained a dedicated Remote Access Services (RAS) department to provide support to Cisco employees in the U.S. The team, which was based at the San Jose campus in California, grew in responsibility for design, engineering, and support of remote access solutions in the Americas. The IT organizations outside of the Americas provided local remote access support to employees within their regions. The remote and corporate organizations work jointly together to develop global standards strategies and solutions. Through the years, the team implemented and supported services that consisted of analog dial, ISDN, Frame Relay, xDSL, and VPN. In total, through a combination of in-sourced and outsourced services, the team supported 30,000 dialup users and over 16,000 users with highspeed access to their homes. This RAS team of 15 engineers, provisioners, analysts, and project managers supported more users and services than most medium-sized Internet service providers (ISPs) in the U.S. A separate helpdesk organization provided all rst-level support for users globally. I had the privilege of leading the Remote Access Services team for a 20-month period during 2000 and 2001. They are the most professional, hard-working group of individuals I have ever worked with. Providing remote access support can be thankless and frustrating when dealing with end users who believe their individual remote connectivity should have high level of support with a four-hour mean time to repair. Furthermore, supporting an engineering user base further complicates matters because home networking requirements become more complex to accommodate. Unlike most enterprises, RAS responsibilities for Cisco also included testing and implementing new Cisco products to showcase their use within our own networks. One could say most of our network was a living lab and, although we were making frequent changes to the infrastructure, the RAS team consistently maintained greater than 99.925 percent availability each quarter. The team contributed to making product improvements and enhanced the testing of new hardware
5259.book Page xxiv Thursday, October 10, 2002 5:39 PM
xxiv
and software by identifying product bugs that were xed before a customer encountered the problem. The team achieved signicant results during the last scal year that included increasing the number of users who have broadband connectivity at home by 62 percent while decreasing average cost per user by 50 percent. The team also improved support ratios for broadband users from 1000 users per engineer to 1700 users per engineer. A member of the team, Plamen Nedeltchev, also developed a solution to address the problems with the huge number of transactions a Windows 2000 network generates, especially for an ISDN usage-based environment. His solution signicantly reduced the usage costs for ISDN users and the corporation, and was signicantly better than any solution recommended by Microsoft. Plamen is a key contributor to the enhancements implemented in our remote access network, especially to addressing the requirements of development engineers who work full time from home. It was his vision to write this book for Cisco Press to address the gap of available remote access troubleshooting techniques. It is a compilation of the current knowledge and practices of one of the worlds best remote access teams. In August 2001, a reorganization of IT Infrastructure resulted in the restructuring of remote access within Cisco. Although the centralized RAS team is now disbanded, this book is a testament to their achievements and a legacy to the knowledge they possess for developing and running leading-edge remote access networks. I am proud to be associated with remote access services, and the experience I gained in my former position within Cisco will always be one of the highlights of my career.
Felicia Brych Manager Cisco Remote Access Services December 1999August 2001
5259.book Page xxv Thursday, October 10, 2002 5:39 PM
xxv
Introduction
In my career, telecommunications came into existence in the beginning of the 1970s. In high school, the army, and later in college, where I had my rst contact with big and mini computers, I made my rst attempts to grasp the technology. The emerging LANs in the 1980s, bridges, decentralized computing, change of computer generations, Token Ring, and, of course, CSMA with all avors and modications, and the emerging IP with its promising end-to-end versus hop-by-hop networking, were among the most intriguing events in my career. The phenomenon of the Internet, the super-media, during the last decade of the 20th century, has without a doubt been one of the principal, not only technical, but also social, events for generations that still stirs my curiosity. The remote access to corporate resources, located far away from your location, always amazed and fascinated me. I remember when, at the beginning of the 1980s, I was able to not only dial in from Plovdiv, but to read my inbox located on a server in Soa...I was the happiest man in the world.
NOTE
Soa is the capital of Bulgaria. Plovdiv is the second biggest city in Bulgaria. The distance between the two cities is about 150 km.
I always wanted to write this book. Years and years of looking at computer screens always wondering if it is possible to put together a concise description of all these numbers, abbreviations, and symbols. Meanwhile, I was always collecting pieces here and there, writing short manuals for myself. Working in the remote access environment at Cisco, I nally had the chance to write this book, which started from an article about ISDN troubleshooting one night in November 2000. (The article was published in the Cisco Packet Magazine in Q2 2001.) Brett Bartows proposal for writing a book about remote access troubleshooting came just in time. Remote access is about buckets of technologies. Remote access is about how to reach the remote LAN. The uniqueness of working on remote access is the opportunity to enhance your knowledge and to design, implement, congure, and support the variety of technologies used for remote access solutions today. Your troubleshooting ability changes based on your position or location in the classical trio of remote accesswhether you are a remote user, a service provider site, or at the corporate site. As a troubleshooting engineer, maybe the best position you can choose is the last one. The uniqueness of the enterprise remote access is that you have limited visibility into the cloud, but you can see both ends of the remote access service and you control the headend side. Of course, troubleshooting is maybe more about hunches, about rightand-wrong, and about experience, but knowledge denitely helps. Combined with passion, it can make troubleshooting a genuine craft. One of the main challenges of this book was to provide the reader with the minimum technology background sufcient to understand the technology basics. This challenge came
5259.book Page xxvi Thursday, October 10, 2002 5:39 PM
xxvi
from the fact that numerous studies and books published in the last 20 to 30 years have produced an abundance of information, which is almost impossible to synthesize in a limited number of pages for each technology in this book. Combining this information with troubleshooting techniques and recommendations was another challenge that this book needed to meet. This book was written with appreciation of generations of scientists and engineers, constantly developing standards, coding and signaling schemes, hardware/software designs, and congurations to provide remote users with full access to their resources, sometimes thousands of miles away. This book was certainly written with an appreciation to Ciscos contribution to the technology over the last decade. This book is written with appreciation to remote access solutions, where wired networks made possible the most common design solutions today. Thats why Part I concentrates on the fundamentals, whereas Parts II, III, and IV deal with commonly available technologies, such as dial, ISDN, and Frame Relay. However, we are about to witness and participate in a signicant change in the existing remote access solutions. Panta rheias every technology continuously changes its features, the remote access environment is no different. Todays VPN (in all avors) is only the rst wave of moving away from legacy remote access, which is primarily based on permanent circuits. Thats why Part V, VPN, is a bridge to the futuretowards using locally available Internet services to access the corporate resources remotely. The evolving mobility adds a new dimension to remote access technologies. Overcoming the tyranny of cables will transform remote access into ubiquitous access sooner rather than later.
Objectives of This Book

The main objective of this book is to offer a concise version of troubleshooting remote access networks. Whether you are an enterprise network manager or administrator, network or consulting engineer, or a remote access help-desk consultant, you will have access to both sides of the connection. If you are troubleshooting both end-user and core-environment issues, you will nd the book useful because it provides you with the maximum reasonable descriptions, explanations, and examples possible. Secondly, this books focus is on the remote end of the connection instead of on the corporate side. In my imagination, I always see a user, whose remote access servicehis lifeline to the corporationis down and he is desperately trying to restore it to meet his deadline. Ive been there. I know what thats like. Thats why, even if you are an end user working with your local service provider or ISP, this book will enhance your knowledge and troubleshooting skills.
5259.book Page xxvii Thursday, October 10, 2002 5:39 PM
xxvii
Who Should Read This Book?

This book is not about the big picture, but about engineers whose day-to-day operations require remote troubleshooting. This book is for those who, sitting behind non-working routers, are trying to gure out where to start and how to approach a problem. This book is intended for any engineer who is contemplating changing his qualication to become a network engineer. This book is for network engineers who already have a certain level of qualication and experience and are trying to enhance their knowledge in remote access technologies. Finally, this book provides helpful remote access troubleshooting information for engineers working toward CCNP and CCIE certications. This book is written assuming the reader has a level of networking experience equivalent to that of a CCNA.
The Organization of This Book

This book is based on the premise that if you really want to troubleshoot, you need to go through some preliminary phases rst. You need to start with the technology basics, progress through design and conguration solutions, and nally get to the troubleshooting methodologies, techniques, and tools. Every chapter of this book is organized according to this concept, and every chapter includes review questions. Finally, the examples and the scenarios in Parts II, III, IV, and V are live-based and represent the best proven practices from more than tens of thousands of cases handled by the Cisco Remote Access team.
Part I: Remote Access Fundamentals

Part I, which describes the fundamentals of remote access networks, is the technological foundation of this book. This part includes management considerations and remote access service options. It provides relatively extensive information about telecommunications basics, modulations, and coding techniques in wired, wireless, and hybrid environments. An integral part of this discussion is the clocking, line coding, and framing in carrier systems, including the most common T1s and PRIs. An important section of Part I is the discussion about the cloud, and how the carriers and service providers handle the trafc. The information about the future of the service and the last-mile initiative of Cisco is provided as well. Although the rst three chapters are about the remote access environment, the last chapter in Part I is about remote access inter-network layered models, methodology, and tools. In this chapter, the layer-by-layer model of troubleshooting is introduced as one systematic approach to troubleshooting issues.
Part II: Dial

Part II is devoted to one of the most traditional remote access technologies: dial networking. The initial technology information is designated to underline some of the fundamentals and specics of dial, in addition to the information provided in Part I. The detailed description of
5259.book Page xxviii Thursday, October 10, 2002 5:39 PM
xxviii
modems and the overview of possible provider issues, as well as the detailed description of Point-to-Point Protocol (PPP), is among the main topics covered. The design chapter includes information about text dialin network, PPP dialin network, text dial-out network, PPP dial-out network, large scale dial-out network, and dial-on-demand backup network, all of which are well-known design solutions in the industry today. The same set of design solutions is also presented from a conguration point of view, with the necessary explanations, tips, and notes. The dial troubleshooting section includes information on troubleshooting T1 and PRI circuits, dialin service, dial-out service, and important access server (AS5x00) specic commands and debugs. The troubleshooting scenario chapter focuses on authentication problems, frequent retrains and disconnects, and dirty phone lines and bad modems.
Part III: ISDN

Part III is about Integrated Services Digital Network (ISDN)especially ISDN BRI. This part provides concise ISDN technology background information about standards, channels, and ISDN architecture. The necessary troubleshooting information about reference points, interfaces, and initializing of layers one, two, and three is provided here, as is information about ISDN switch types. The common ISDN design solutions are focused on NAT/PAT congurations and virtual proles and interfaces. Separate sections are designated to provide detailed discussion about Multilink Point-to-Point Protocol (MP) and Multi-Chassis Multilink Point-to-Point Protocol (MMP) designs. The conguration chapter focuses on ISDN costeffective solutions, such as spoong, snapshot routing, and dial-on-demand routing (DDR). The ISDN troubleshooting chapter illustrates the layer-by-layer approach and includes detailed discussion about each and every layer, as well as extended information about troubleshooting MP, MMP, and telephone interfaces. The troubleshooting scenarios include new install problems, dial-out problems, performance issues, end-to-end problems, and Windows 2000 and Cisco DDR controversy.
Part IV: Frame Relay

The main focus of Part IV is Frame Relay. More information is provided about the end users side of the design than about the corporate side. The Frame Relay standards, protocols, and service architecture are the main foundation topics. The Frame Relay design provides detailed information about User-Network Interface (UNI) and Network-to-Network Interface (NNI). Frame Relay performance criteria, fragmentations, Inverse ARP, upper-layer protocols, and Local Management Interface (LMI) are among the design objectives of Part IV. The Frame Relay conguration provides some common conguration solutions and explanations. The advanced conguration section includes IP unnumbered solution, frame switching, Frame Relay backup, compression, multicast, and trafc shaping. The Frame Relay troubleshooting chapter applies the layer-by-layer approach and discusses Layer 1 and 2 problems, performance, end-to-end issues, compression, and trafc-shaping problems.
5259.book Page xxix Thursday, October 10, 2002 5:39 PM
xxix
The Frame Relay troubleshooting scenarios in Chapter 18 focus on new installs, wrong DLCI, LMI settings, and performance and multicast issues. Rehosting of Frame Relay service is included as well.
Part V: VPN
Virtual Private Network (VPN) is about running private data over public networks. Part V provides the minimum initial background for all versions of VPN, but focuses on remote access solutions. PPTP, L2TP, IPSec, and key agreements are discussed in detail. The common design solutions, the termination points, software and hardware VPN clients, EzVPN, and PIX-based solutions are explained concisely. All available remote access VPN solutions and their congurations are another important part here. They include Cisco VPN 3000 Series Concentrator conguration and Cisco VPN client conguration (including Cisco Unity VPN Client, Cisco VPN 3002 HW Client, Cisco Easy VPN IOS, and Cisco PIX 501 and 506 Client). The VPN troubleshooting chapter includes extensive and detailed explanations, divided into three main groups: Cisco VPN client issues, VPN and Internet technologies issues, and VPN and LAN issues affecting remote access VPN. The scenarios in Chapter 22 include VPN over PPPOE, authentication problems and cannot pass data issues, hardware VPN client issues, and extranet issues.
Command Syntax Conventions

The command syntax in this book conforms to the following conventions: Commands, keywords, and actual values for arguments are bold. Arguments (which need to be supplied with an actual value) are italic. Optional keywords and arguments are in brackets []. A choice of mandatory keywords and arguments is in braces {}.
These conventions are for syntax only.
References and Additional Reading

You might nd the following list of resources helpful in your further study of remote access technologies: Abe, George. Residential Broadband, Second Edition. Cisco Press, 2000. Adams, Michael. OpenCable Architecture. Cisco Press, 2000. Alwayn, Vivek. Advanced MPLS Design and Implementation. Cisco Press, 2001. American National Standards Institute. ANSI T1.601.1994. ISDN Basic Access Interface for Use on Metallic Loops for Applications on the Network Side of the NT.
5259.book Page xxx Thursday, October 10, 2002 5:39 PM
xxx
Bingham, John A. C. ADSL, VDSL, and Multicarrier Modulation. John Wiley and Sons Inc., 2000. Birkner, Matthew H. Cisco Internetwork Design. Cisco Press, 2000. Black, Ulysses D. Frame Relay Networks: Specications and Implementations. McGraw Hill, 1998. . ISDN and SS7: Architecture for Digital Signaling Networks. Prentice Hall, 1997. Boyles, Tim and David Hucaby. CCNP Switching Exam Certication Guide. Cisco Press, 2000. Buckwalter, Jeff T. Frame Relay: Technology and Practice. Addison-Wesley Longman Inc., 1999. Chappel, Laura. Advanced Cisco Router Conguration. Cisco Press, 1999. Chappel, Laura and Dan Farkas. Cisco Internetwork Troubleshooting. Cisco Press, 1999. Cisco Systems, Inc. Cisco IOS 12.0: Wide-Area Networking Solutions. Cisco Press, 1999. . Dictionary of Internetworking Terms and Acronyms. Cisco Press, 2001. . Internetworking Technologies Handbook, Third Edition. Cisco Press, 2000. . Network Design and Case Studies (CCIE Fundamentals), Second Edition. Cisco Press, 2000. . Cisco 700 Series Command Reference. 1996-1997. . Cisco 700 Series Installation and Conguration Guide. 1997. Conover, J. 80211a: Making Space for Speed. Network Computing, January 2001. Cooperman, G., E. Jessen, and G. Michler (eds.). Workshop on Wide-Area Networks and High Performance Computing. Springer, 1999. Coutinho, S. C. The Mathematics of Ciphers: Number Theory and RSA Cryptography. A K Peters, Ltd., 1999. Flanagan, William A. ISDN: A Practical Guide to Getting Up and Running. CMP Books, 2000. Frame Relay Forum, FRF.1.1. User-to-Network Interface (UNI) Implementation Agreement. January 1996. Goralski, Walter. Frame Relay for High-Speed Networks. John Wiley and Sons Inc., 1999. Gough, Clare. CCNP Routing Exam Certication Guide. Cisco Press, 2001. Held, Gilbert. Frame Relay Networking. John Wiley and Sons Inc., 1999. Jones, Burton W. Modular Arithmetic. Blaisdell Publishing Company, 1964. Kessler, Gary, and Peter Southwick. ISDN Concepts, Facilities, and Services, Third Edition. McGraw Hill, 1996.
5259.book Page xxxi Thursday, October 10, 2002 5:39 PM
xxxi
Khan, Ahmed S. The Telecommunications Fact Book and Illustrated Dictionary. Delma Publishers Inc, 1992. Knuth, Donald E. Art of Computer Programming, Volume III: Sorting and Searching (Second Edition). Addison-Wesley Longman, 1998. McClain, Gary R. Handbook of Networking and Connectivity. AP Professional Academic Press, 1994. Mervana, Sanjeev and Chris Le. Design and Implementation of DSL-Based Access Solutions. Cisco Press, 2002. Miller, Mark. Analyzing Broadband Networks: ISDN, Frame Relay, SMDS, and ATM. John Wiley and Sons, Inc., 1996. Morgan, Brian and Craig Dennis. CCNP Remote Access Exam Certication Guide. Cisco Press, 2000. Oppenheimer, Priscilla. Top-Down Network Design. Cisco Press, 1999. Pecar, Joseph A. and David A. Garbin. The New McGraw-Hill Telecom Factbook, Second Edition. McGraw-Hill Professional Publishing, 2000. Pepelnjak, Ivan and Jim Guichard. MPLS and VPN Architectures. Cisco Press, 2000. Nedeltchev, Plamen. Troubleshooting ISDN. Cisco Packet Magazine, Q2 2001. . Wireless LAN Ready for Prime Time. Cisco Packet Magazine, Q3 2001. Nedeltchev, Plamen and Radoslav Ratchkov. IPSec and Related Algorithms. Cisco Packet Magazine, Q2 2002. Ranjbar, Amir S. CCNP Support Exam Certication Guide. Cisco Press, 2000. Retana, A. Slice, D., and White, R. Advanced IP Network Design (CCIE Professional Development). Cisco Press, 1999. RFC 1191. Path MTU Discovery. RFC 1918. Address Allocation for Private Internets. RFC 2401. Security Architecture for the Internet Protocol. RFC 2402. IP Authentication Header. RFC 2403. The Use of HMAC-MD5-96 Within ESP and AH. RFC 2404. The Use of HMAC-SHA-1-96 Within ESP and AH. RFC 2405. The ESP DES-CBC Cipher Algorithm with Explicit IV. RFC 2406. IP Encapsulating Security Payload (ESP). RFC 2407. The Internet IP Security Domain of Interpretation for ISAKMP.
5259.book Page xxxii Thursday, October 10, 2002 5:39 PM
xxxii
RFC 2408. Internet Security Association and Key Management Protocol (ISAKMP). RFC 2409. The Internet Key Exchange (IKE). RFC 2410. The NULL Encryption Algorithm and Its Use with IPSec. RFC 2411. IP Security Document Roadmap. RFC 2412. The OAKLEY Key Determination Protocol. RFC 2637. Point-to-Point Tunneling Protocol. RFC 2661. Layer Two Tunneling Protocol L2TP. RFC 3078. Microsoft Point-To-Point Encryption (MPPE) Protocol. Sapien, Mike, and Greg Piedmo. Mastering ISDN. Sybex, 1997. Schneier, Bruc. Applied Cryptography: Protocols, Algorithms, and Source Code in C, Second Edition. John Wiley and Sons Inc., 1996. Srisuresh, P. and M. Holdrege. IP Network Address Translator (NAT) Terminology and Considerations. RFC 2663, August 1999. Stallings, W. Data and Computer Communications, Fifth Edition. Prentice Hall, 1997. Stallings, William. ISDN and Broadband ISDN with Frame Relay and ATM. Prentice Hall, 1999. Tittel, Ed, and Steve James. ISDN Networking Essentials. AP Professional Academic Press, 1996. Williamson, Beau. Developing IP Multicast Networks, Volume I. Cisco Press, 2000. Wright, Robert. IP Routing Primer. Cisco Press, 1998. www.itu.int/ITU-T/ Wynston, Michael. Cisco Enterprise Management Solutions, Volume I. Cisco Press, 2001.
5259.book Page xxxiii Thursday, October 10, 2002 5:39 PM
5259.book Page 2 Thursday, October 10, 2002 5:39 PM
PART
Remote Access Fundamentals

Chapter 1 Remote Access Overview Chapter 2 Telecommunication Basics Chapter 3 The Cloud Chapter 4 Troubleshooting Approaches, Models, and Tools
CHAPTER
Remote Access Overview

Remote access is a term that pertains to communication with a data processing facility from a remote location or facility through a data link. This chapter introduces remote access environment specics and provides brief descriptions of remote access options in the following aspects:
Management considerations and the pros and cons of remote access solutions Dening the remote access population Legacy remote access solutions Virtual Private Networks (VPNs) over some of the most popular technologies, such as cable modems, xDSL, wireless, and satellite services Provisioning of the corporate circuits
As a network administrator or network engineer, you need to identify the specics of the environment and know the specics of the solution that you are troubleshooting to set up your expectations accordingly. Remote access networks are often described as the most difcult type of network to support. In corporate local-area networks (LANs) and wide-area networks (WANs), data centers and network operations centers safeguard the networking infrastructure. However, remote access to an employees home or from locations while an employee is traveling or working from a customers premises introduces many components not under a corporations control. Within a users home, there can be wiring problems or limited copper pairs, which can complicate the installation and troubleshooting process. Users can power off their home routers or modems, referred to as customer premises equipment (CPE), at any time. This makes proactive monitoring extremely difcult, if not impossible. Users can install any hardware and software on their home network or computer that might interfere with, or not integrate with, the remote access solution. It is difcult to control the security aspects of a users home network. Finally, a user might be technically procient enough to modify the CPE conguration, which can result in additional problems. While an employee is working on the road from either a hotel or a customer premises, additional complications exist, and sometimes getting answers to specic troubleshooting questions can be impossible. The phone system in a hotel often contributes to dialup connectivity problems. A broadband service offering in a hotel or a customers rewall can
Chapter 1: Remote Access Overview
block IPSec trafc for VPN users who are trying to reach their destination point through the Internet. Some services that the remote user is accustomed to in the corporate environment might be unavailable, not permissible, or have a degradation of quality because of bandwidth, latency, or policy limitations from remote locations. Some of these circumstances might require special setups to meet users expectations. For all these reasons, troubleshooting remote access problems can be a difcult and timeconsuming process. The purpose of this book is to provide networking professionals with a collection of proven and current troubleshooting techniques for Cisco Systems remote access products and for most remote access service options. Technologies addressed in this book include analog dial, ISDN, Frame Relay, and VPN.
Management Considerations
As a network manager, deciding on the type of remote access services to provide to your organization depends on numerous factors. For each of them, there might be an easy answer based on general knowledge of the organization, or you might be required to obtain specic business requirements that limit service options. For many large enterprises, there is no one-size-ts-all service that meets all user requirements. The categories described in this section are the most common ones that an organization should consider when making remote access service decisions. (They are listed in no particular order.)
Cost
The budget for remote access can limit the options available. The organization must determine what base of users will be granted access, what capacity and growth estimates are required, and how the costs will be allocated internally. To form the basis for a remote access budget and funding approach, answer the following questions:
Who will cover the initial capital and installation costs? What costs are required to deploy the solution? Are there any training costs? How will any monthly circuit costs for the back-end environment be funded? Should a users organization be charged for the users monthly access fees and any usage-based services? Is an approval process required for users to request remote access? Will the organization set a maximum limit on the monthly amount that a user can expense, and the user personally covers any additional costs? Should an internal fee be charged to fund the on-going operational support? Should the fee differ depending on the service or the level of support required?
Management Considerations
Availability
An organization must dene the geographic area (local, regional, national, or global) to which service must be supplied and determine the availability of network options within that area. Besides rural areas, many metropolitan areas do not have options for high-speed access to the home that include ISDN, Frame Relay, xDSL, cable, wireless, and satellite. The demise of many of the competitive local exchange carriers (CLECs) in the U.S., and an economic downturn during 2000 and 2001, has further impacted the build out of highspeed network access to residential neighborhoods. You must understand what options and technologies are available and whether or not you must restrict the options to one or more providers/carriers based on availability.
Support
Support options can weigh heavily on the remote access option you choose. You must dene the service level for supporting the back end infrastructure and for supporting the end user. Different proles of users can require different levels of support. Plan to set user expectations up front. The decision to in-source versus outsource must also be considered. The organization must have the available resources with the right skill sets to support the selected service. Training might be required for support staff. Local language and incountry support can be important. Determine if you need consultants to help ll the skill or resource gap. Assess whether the existing helpdesk organization can assume part of the support requirement. As part of your deployment plan, ensure that you include the time required to develop support processes and to train support personnel.
In-Sourcing Versus Outsourcing

The decision to in-source versus outsource depends on the core competency of your IT organization. Besides support considerations, the time and effort to develop and deploy a solution is a factor in the outsourcing decision. Determine if the organization has the available resources with the right skill sets to develop, deploy, provision, and support the selected service. Are resources available in the deployment locations or will team members be required to travel? Will security policies restrict the components that can be supported internally versus externally? What contracting process do you need to follow and how long will this take (that is, do you need to conduct a Request for Information or a Request for Proposal)? You need to solicit several bids from potential vendors and prepare a service and cost comparison of the internal versus external vendor options as part of the decisionmaking process.
Billing and Charge Backs

The decision or ability to charge back expenses to a users organization was mentioned in the preceding section, Cost. If you decide to charge back for user services rather than
funding centrally, you must ensure that the necessary processes and systems are in place to handle the nancial transactions. Is there a process currently available for remote access purposes? Will the vendor provide the billing information in the required format or medium? Should the corporation centrally manage the bills or should they be sent to the user who submits an expense report to cover the charge? Should there be a maximum limit set on the amount to be expensed? How will exceptions and anomalies be dealt with? What reports are necessary and who must receive them? Be prepared to handle the administrative overhead to manage the billing function.
User-Managed Versus Corporate-Managed

As part of the service offering, the organization must determine if it wants to restrict users to a limited number of vendors or open it up to any vendor and let the end user choose the provider. This concept has been used to implement VPN services where a user can select any Internet service provider (ISP) available in the local area, and choose the provider based on the criteria that are important to the user. When the user rather than the corporation orders high-speed access, the user becomes responsible for dealing with the vendor when the service is down or experiencing problems. The user also receives the monthly bill and is expected to submit an expense report up to an approved amount.
Security
The security policies of an organization are a signicant factor in determining the solution. Based on the sensitivity of the information managed by the corporation, policies surrounding authentication, encryption, architecture, and outsourcing vary. Ensure that the security organization is included in the initial planning of the remote access service.
Applications
The applications that must be accessed remotely might restrict the technology alternatives or might affect the network architecture. Some applications can be useless if latency is too great or if the available bandwidth is insufcient. Other applications might not function properly if accessed through a VPN connection. Ensure that you work with the functional areas of the business to identify and test all the core applications that are required to be accessed remotely and to set user expectations on performance.
Home Access Versus Mobility

The nal criterion to be considered is the need to access the corporate network from home, and from on the road while in a hotel, convention center, airport, or a customer/business partner premises. Depending on the organizations remote access requirement, a mobile
Remote Access Service Options
solution might be a necessary part of the overall remote access service offering. The Cisco Mobile Ofce initiative addresses the solutions and considerations that differ based on the need to work on the road, at home, or at work (see www.cisco.com/warp/public/779/smbiz/ mobility/). The next generation of at home solutions will include voice and video over IP, and improved conferencing and collaboration solutions.
Dening the Remote Access User Population

Several proles of users typically require different solutions for remote connectivity. For each of these proles, a different solution and possibly a different level of support might be required to meet their remote access needs:
Full-time telecommuters usually are supported with enough IP addresses to meet their requirements. For them, /32 with NAT, /30, or even /29 address space can be assigned. Day extenders use their home environment as an extension to the existing ofce environment. They are connected an average of two to four hours to the corporate network, usually exchanging e-mails, downloading or uploading les from the server, or browsing the Internet. Road warriors typically spend most of their workday out of the ofce traveling to multiple locations. They require a mobile or wireless solution to access their applications on the network. Engineers might extend their ofce/lab environment at home. If this is the case, they can require up to a /28 IP address space to accommodate their requirements.
Another possible classication here is based on the users job instead of whether they are full-time or part-time telecommuters. A full-time telecommuter doing HR or marketing work probably will not need ve IP addresses, and a part-time engineer might still need a /29, /28, or maybe a NAT private network.

Building remote access networks is not only related to management, but also to some fundamental technical choices that include last mile decisions, WAN technologies, and subscribed services. These choices can be made based on capacity planning analysis, expected functionality, baselines, and simulative models. The viable service options offered by practically all service providers include dial-in, ISDN, and Frame Relay. During the last several years in the U.S. market, new technologies, such as xDSL, cable modems, and wireless broadband services, have emerged. Literally all available narrowband and broadband services can be used for future remote access designs. A wireline and wireless classication of the offered services is another possible way of reviewing remote access offerings.
10
NOTE
Narrowband, or baseband, service offerings refer to subvoice channels that can carry data starting from 64 kbps, fractions of T1, and T1. The term is used for legacy plain old telephone systems (POTS) and non-video-capable systems. Broadband refers to systems that are capable of carrying a wide range of frequencies and services. The cable systems are a classic example.
Figure 1-1 depicts several Cisco remote access services. The scope of enterprise remote access can be broad. The lower portion of Figure 1-1 shows traditional solutions, and the upper portion of Figure 1-1 shows the available VPN options. (In Figure 1-1, the reason that there are two separate dial designs is not technical, but cost-based.)
Figure 1-1 Cisco Remote Access Services
Cisco SW VPN Client or IOS-Based VPN Modem or Cisco 806 & Satellite Modem Cisco SW VPN Client or IOS-Based VPN Cisco 827x or Cisco 806 & Modem
Cisco SW VPN Client or IOS-Based VPN
e
Cisco 827x or Cisco 806 & DSL Modem xDSL Modem & PIX Based VPN or xDSL Modem & HW VPN Client
e
Cisco 827x Service Provider of xDSL over ATM
ISPover xDSL Cisco 720x
Cable Modem or Cisco UBR900 Series, or Cisco 806 & Cable Modem or Cable Modem & PIX-Based VPN or Cable Modem & HW VPN Client
ISP over Cable and PSTN
Wireless ISP Satellite ISP
MMDS, LMDS, DSS or 3G Tower
Small Antenna or Parabolic Reflector ISP Phone PSTN Cloud
Cable Router UBR7200 Cisco 720x VPN Concentrators VPN Cluster VPN Concentrators
Cisco Access Server 5x00

Outside of this Line Is the Scope of Enterprise Remote Access
Intranet
Primary and Secondary TACACS Servers Gateway Switches Primary and Secondary RADIUS Servers
Cisco Secure Cisco Secure Policy Manager Cisco Secure Intrusion Detection System ISDN 36xx ISDN ISDN 720x Frame Relay 36xx, 720x Cisco Access Servers 5x00
ISDN Clouds
Local Loop
Frame Relay Cloud
PSTN Cloud 800 Toll-Free
PSTN Cloud Local Service for High-Density Areas
ISDN Cisco 804, 77x, 1604
Local Loop
ISDN Cisco 804, 77x, 1604
Local Loop
Frame Relay Cisco 1602
A more recent approach to remote access is the VPN, which is making signicant progress in the market by replacing the permanent circuit offering typical of all legacy technologies. In a sense, the VPN offering (VPNs are covered in Part V of this book) became a super
11
vehicle, and the service now includes VPN over ISDN, VPN over dial-in, and so on, where enterprises are not necessarily ordering permanent circuits, but instead are taking advantage of the existing baseband or broadband services of remote users to build VPN tunnels to corporate intranets. VPN is an evolving technology, and some analysts predict it will become a $10 billion market by 2005. Although today, most legacy and some new services compose the bulk of the service providers offering to the enterprise market. Table 1-1 provides a summary of each remote access technology option.
Table 1-1 Remote Access Options Transmission Medium 1 pair copper Standard phone line ISDN 1 pair copper Standard phone line Frame Relay 2 pair copper Standard phone line Bandwidth 56 kbps down 33.6 kbps up 56/64 or 112/128 kbps both directions 56/64 kbps or fractional T1 up to 1.5 Mbps both directions Several miles with repeaters Several miles with repeaters for 56 kbps T1 limitation requires repeater every mile Symmetric <18,000 feet from CO 1.5 to 8 Mbps down 16 to 800 kbps up 1 pair copper 768 kbps Asymmetric <18,000 feet from CO Symmetric Limitations Available everywhere
Remote Access Option Analog
xDSL family
ISDN DSL (IDSL)
1 pair copper Standard phone line
144 kbps
Asymmetric DSL (ADSL) Single-line DSL (SDSL) (symmetric) Rate adaptive DSL (RADSL) Consumer DSL (CDSL) High-data-rate DSL (HDSL) High-data-rate DSL2 (HDSL2) Very-high-data-rate DSL (VDSL)
1 pair copper
1 pair copper
1.5 to 8 Mbps down 16 to 800 kbps up
Adaptive to the line parameters Does not need remote equipment Symmetric Symmetric <4500 feet over twisted pair >4500 feet over ber continues
1 pair copper
Up to 1 Mbps down 16 to 640 kbps up
2 pairs copper 1 pair copper Fiber feeder and ATM
1.544 Mbps 2.048 Mbps 13 to 52 Mbps down 1.5 to 6 Mbps up
12
Table 1-1
Remote Access Options (Continued) Transmission Medium Coax Bandwidth 384 kbps to 4 Mbps down 128 kbps to 4 Mbps up Limitations Requires TV cable Speed varies signicantly with the subscriber load Requires line of site and antenna Requires antenna Requires dish antenna
Remote Access Option Cable modem
Multichannel Multi-point Distribution System (MMDS) Local Multipoint Distribution Service (LMDS) (on the horizon) Satellite
Wireless
500 to 600 kbps down 128 kbps up
Wireless Wireless
0.5 to 4 Mbps both directions 400 kbps to 1 Mbps down 64 to 128 kbps up
For more information, see ADSL and DSL Technologies, by Walter Goralski.
Analog Dialup Services

The analog modem dialup service gained popularity because of constant increases in speed and support from modem manufacturers. The initial offering started with speeds from 300 to 2400 bps, then to 9600 bps, 14.4 kbps, and so on. The term modem is an abbreviation for modulatordemodulator. Because the modem operates in the 4-kHz bandwidth, it requires analog to digital and digital to analog conversion on both ends. Part of this technology uses extended code correction and compression, which allows the speed to increase up to a factor of 4. A signicant event of the modem offering was in 1968, when the Federal Communications Commission (FCC) regulations permitted CPE to be connected to the Public Switched Telephone Network (PSTN). Another major event in the history of network communications was a paper written in 1948 by Claude Shannon, which established the theoretical limits of the speed that the modem can operate. The equation (see Chapter 2, Telecommunication Basics) is called Shannons limit, or Shannons Law, and denes the upper theoretical limit of the data rate if proper technology is used. The rst attempt for standardization occurred in 1968, where the Comit Consultatif International Tlphonique et Tlgraphique (CCITT), which is today called the International Telecommunication Union Telecommunication Standardization Sector (ITU-T), established a recommendation known as V.21, which denes the 200 (300 bps) modem speed. V.21 is still in use today as part of the V.34 and V.8 handshake that establishes basic modem compatibility. In 1984, the V.32 standard dened echo-cancellation and trellis coding. These standards provide some degree of forward error correction (FEC) techniques, and V.32b denes data rates of up to 14.4 kbps. The V.34 standard supports data rates of 24,
ch01.fm Page 13 Friday, October 11, 2002 11:08 AM
13
28.8, and 33.6 kbps, and coding 10 bits in one sinusoid (10 bits/Hz), which approaches the theoretical limit of Shannons Law. The announcement of 56 k modems by US Robotics, based on using T-carriers for dial-in service, was a major breakthrough. Analog modems operate over non-conditional circuits; not all 256 levels of pulse code modulation (PCM) coding are recognizable. The modems use 7 instead of 8 bits, which yields 128 levels of PCM and consequently 7 bits 8000 = 56 kbps. Without any special requirements, this service requires a T1 or ISDN digital trunk on one end that supports 56/64 kbps, and a regular analog line on the other end. Both ends of the connection are usually asymmetric. From the modem side, the downstream connection has a fairly good chance to achieve 56 kbps most of the time because quantizing digital to analog is not susceptible to noise and interference on the line (see the section, PCM in Chapter 2). Nevertheless, such things as local loop issues, bridge taps, crosstalk, and so on usually decrease the data rate to a more common 48 to 50+ kbps. The upstream direction is different. Analog to digital transformation is susceptible to different types of interference. Regardless of the connection speed reported by the dial management applications, the upstream speed is usually 28.8 or 33.6 kbps. This fact is not visible to the end user because the Internet is more of a downstream than upstream service. A remote access implementation is usually based on access servers, or remote access servers, from which the remote user connects to the corporate network access server (NAS) by using a designated phone number(s). (See more about access servers at www.cisco.com/ warp/public/44/jump/access_servers.shtml.) Some telecommunication companies that provide global dialup service from all over the world use global dialer software, where the user chooses the country and the available phone numbers within the country to connect to the corporate network. The dial numbers are predened and populated in a dial manager application that is standard on a users laptop or PC. In the U.S., an option for dial services is to use 800 toll-free numbers, where the enterprise owns the toll-free number, and pays a xed per-minute usage fee. The 800 numbers eliminate the need for a more expensive and cumbersome calling card option to connect from long distance locations. Be aware that many hotels now charge a usage fee for 800 calls made from the room, which can signicantly increase the dialup cost. Another analog dial option is to use any ISP to connect to the Internet and use VPN-based solutions to connect to the corporate network. This solution is the most cost-effective and all signs in the dial market show that VPN will be the preferable dial solution in the near future. One signicant feature of using a dedicated concentrator for VPN over dial is the option to use compression (LZS, STAC), so that the overhead of VPN packets can be overcome and yield better performance. Also, todays VPN client software is built right into many popular operating systems. You learn more about dialup technologies in Part II, Dial.
14
Benets of Analog Dialup Services

Today, the dialup solution is the most common solution for remote users, road warriors traveling on business, and home teleworkers. Dialup technology does not require any changes to the CPE side, even if the remote user is using a 56-kbps modem. Plenty of tools exist, including web tools, which are offered by manufacturers to measure the maximum connection speed in any particular location. Another feature of the technology is that when the maximum speed cannot be achieved, the 56-kbps ex modem can use its backward compatibility. If, for any reason, the maximum speed is not achievable, the 56 k technology can decrease the speed and perform V.34 data connections of 33.6 kbps, which is achievable from many locations around the world. One of the most successful aspects of this technology is that many users have some experience with modems, which signicantly decreases enterprise support costs. The high availability for minimum cost is the main advantage so far.
Limitations of Analog Dialup Services

When considering the drawbacks of the technology, the data rate needs to be mentioned rst. At this point in technology development, connection speeds under 100 kbps seem outdated and can be ineffective with some types of applications. At the same time, competing technologies, such as 3Coms X2 and 56 k ex that is supported by Lucent Technologies, Motorola, and Rockwell, result in a lack of unied standards and interoperability problems. The dialup modem technology has reached its theoretical maximum. There was an attempt to unify the X2 and K-ex technologies under V.90, and now there is V.92. In todays market, however, V.90 is much more common for high-speed dialup than X2 or K-ex, especially because a lot of those were software ash upgradable to the V.90 standard when it was released.
ISDN Services
ISDN is considered to be the rst advancement from analog dialup service. The ISDN standard is well developed and there are a variety of solutions that make ISDN the most commonly available service offering from telecommunication companies. The T sector of the ITU-T is responsible for issuing protocols for the E-Series, I-Series, and Q-Series, and for components of the X-series that are related to ISDN, broadband ISDN (B-ISDN), and Signaling System 7 (SS7). E-Series protocols cover the standardization of the recommended telephone network for ISDN. ITU-T recommendation E.164 (I.331), for example, denes the formats of ISDN addresses. I-Series protocols cover the standardization of concepts, terminology, and general methods. I.431, for example, denes the Primary Rate Interface (PRI), and I.432
15
denes the Basic Rate Interface (BRI). Q-Series protocols deal with the standardization of switching and signaling schemes and techniques. The Q.921 protocol describes the ISDN data-link processes of LAPD, which functions like Layer-2 processes in the International Organization for Standardization/Open System Interconnection (ISO/OSI) reference model. Q.931 species ISO/OSI reference model Layer-3 functions. Because of the level of standardization in ISDN, the technology has a signicant presence in the U.S., Canada, Japan, Europe, and all over the world. The fast setup of calls, sometimes referred to as fast-dial, has a call setup phase of less than one second. Some ISDN switches were developed before the standards and there are a variety of ISDN switches in different parts of the world. This diversity requires special attention in the design, conguration, and operational phases of remote access solutions. From an enterprise perspective, the technology is fully suited for most remote access objectives, offering BRI services (2B+D channels) for end users, with an overall bandwidth of 112/128 kbps for user data. Service providers usually offer ISDN service with two data/voice channels for the end user. You learn more about ISDN in Part III, ISDN.
Benets of ISDN Services

Some older Cisco routers do not have voice capable ports, such as the 1000 series routers. Also, the 770 and 800 series routers provide analog phone ports and the 1600s provide an S-bus port for ISDN phones but not analog phones. Also, video conferencing is an embedded function because ISDN is designed for voice, data, and video. The technology is dened as a viable alternative when the end user requires more bandwidth than dial-in, a variety of data and voice services, and administrative functions such as exchanging data, sending e-mails, and surng the Internet. The technology supports corporate connectivity for a small ofce, home ofce (SOHO) environment, or a remote ofce, branch ofce (ROBO) environment. Ciscos ISDN solutions are cost effective because of the scalable nature of ISDN that allows you to scale in increments of 64 kbps, or incremental B channels. The most common design solutions include the following:
Dial-on-demand routing (DDR) Snapshot routing ISDN backup solution Multilink Point-to-Point Protocol (PPP) and multichasis PPP Callback solutions
The head end or back end of the enterprise ISDN service is usually developed by using PRIs, or channelized T1/PRIs. Ciscos IOS capability offers more advanced features including the following:
16
Non-Facility Associated Signaling (NFAS) with a D channel backup feature ISDN NFAS allows a single D channel to control multiple PRI interfaces. A backup D channel can be congured for use when the primary NFAS D channel fails. Bandwidth Allocation Control Protocol (BACP)The BACP provides multilink PPP peers with the ability to govern link use. The Bandwidth Allocation Protocol (BAP), a subset of BACP, provides a set of rules that govern dynamic bandwidth allocation through call control. It also denes a method for adding and removing links from a multilink bundle for multilink PPP.
In the U.S., the local providers that offer ISDN include both local ISDN and Centrex services. A at rate is offered only in some areas. Typically, the providers charge a per minute rate, at least for data usage. The Centrex solution is possible and preferred when the service is local or an inter-local access and transport area (LATA), as dened in Chapter 3, The Cloud. Centrex is preferred in a remote access environment because of the signicant reduction in cost from a usage-based service. If the inter-exchange carrier (IXC) is involved, the better solution is to subscribe for local ISDN service for Internet access, and VPN to connect to the corporate network. In this scenario, only the voice portion of the bill can cause high usage, not the data part. To date, no drawbacks or problems are identied for ISDN with IPSec VPN solutions. ISDN is also well suited for multicasting, voice over IP (VoIP), compression, and if the LEC and IXC can commit a rate, a quality of service (QoS) solution can also be implemented.
Limitations of ISDN Services

One of the concerns of ISDN is related to standards. Besides the differences in ISDN switch type, there are interface compatibility limitations. The U-interface, which is available in the U.S. and Canada where the end terminator (NT1) is part of the CPE, is not available in other parts of the world where the S and T reference points, or S/T interface, is the termination solution and the NT1 devices are governed by the local carriers. This difference requires two types of routers to be produced, one suitable for each particular market, or two interfaces in Ciscos 77x ISDN routers (see the Cisco 804/1604 and the Cisco 803/1603 at www.cisco.com). Another limitation is cost. Initially conceived with huge enthusiasm, the technology has proven to be expensive because of the dialup nature of ISDN. It is usually based on a usage rate; the carriers use metrics on which to base the rate. Usually, the metrics are based on the number of outgoing calls and their duration. When the IXC portion is included in the design, the ratio bandwidth/price can be unfavorable for this solution.
17
Frame Relay Services

Frame Relay technology is considered to be a derivative of ISDN. It is a connectionless service, however, which means that the frames traveling the network do not require the initial phase of establishing the connection, because the frames carry the address information. This solution is referred to as a permanent virtual circuit (PVC). Frame switching is the other alternative, where the call setup phase of the connection is necessary, and consequently the technology is based on switched virtual circuits (SVCs). However, the vast majority of existing service offerings are PVC-based. The requirement for higher connection speeds is one of the reasons for developing Frame Relay technology. The data transmission shift from mainly text exchanges to graphics is one of the driving factors, because graphics and video require peak bandwidth availability and lower response time. The requirement for dynamic bandwidth is another factor in Frame Relay development. The demand for more reliability and less overhead from existing digital facilities, and the requirement for handling bursty trafc are other factors that inuenced the creation of the new technology at the end of the 1980s. You learn more about Frame Relay in Part IV, Frame Relay.
Frame Relay Standards

A specic feature of Frame Relay technology is the ability to use packet sizes that are greater than 1500 bytes, which are common in LAN environments. Some estimates show that the packet size can be up to 16 kilobytes, remembering that the embedded frame check sequence (FCS) can handle up to 4-kilobyte packets. (See Part IV for more information.) Frame Relay combines the statistical multiplexing and port sharing of X.25 with the highspeed and low-delay characteristics of time-division multiplexing (TDM) circuit switching. X.25 is considered the predecessor of Frame Relay, but unlike X.25, Frame Relay eliminates the Layer-3 protocols of X.25 and concentrates the addressing and multiplexing in Layer 2. The architecture model is more compliant with the OSI model, where the second layer deals with frames but not with packets. And of course whats really going on to improve efciency is removing the store and forward/error correction out of the picture (Layer 2), something that modern network technology has allowed. As a result, Frame Relay achieves 45 Mbps and it is available even in 155 Mbps service.
NOTE
Frame Relay and ISDN have common roots. Other derivatives of ISDN are Switched Multimegabit Digital Service (SMDS) with typical speeds of 155 Mbps, and Asynchronous Transfer Mode (ATM) with target rates of 622 Mbps. All fall under the category of B-ISDN services. Today, 10 Gbps (9953 Mbps) and 2.5 Gbps ATM links are available, and soon there will be a 40 Gbps capable interface.
18
Only a few Layer-2 functions, the so-called core aspects, are used in the most common PVC-based networks. These functions include checking for valid error-free frames, but not requesting retransmission if any error is found. Thus, many high-level protocol functions, such as sequencing, windowing, acknowledgments, and supervisory frames are not duplicated within a Frame Relay network. The omission of these functions dramatically increases the throughput because each frame requires much less processing time.
Benets of Frame Relay

Enterprise remote access solutions are composed of a variety of components, including technology, hardware, software, standards, and architecture to provide Frame Relay services within the enterprise environment. Examples of these components include data, voice over Frame Relay, Frame Relay multicast, IP multicast, and compression. Frame Relay technology poses fewer issues when covering longer distances for the remote user who is far from the central ofce (CO). The technology is fully compatible with T1/ T3 carrier systems; however, existing distance limitations apply. The ability to provision services from 56 kbps, or fractions of a T1 starting from 64 kbps, gives a sense of exibility to the network designers. Although the ability to order 256-kbps and 384-kbps circuits is possible, the user requirements must be justied to warrant the additional cost because Frame Relay pricing depends on distance. The number of PVCs, the committed information rate (CIR), and port rate all factor into that nal cost.
Limitations of Frame Relay

The pricing of Frame Relay services can range from $250 to over $1000 per month, and in many circumstances this does not justify the cost for providing such services to remote access users. When run over T1 circuits, it inherits the limitations of T1s because of repeaters placed in every mile.
VPN Services
VPN is not a new term in the computer and communication world. However, the new phase of VPN is due to new IP-based solutions and a set of protocols, such as L2TP, Point-to-Point Tunneling Protocol (PPTP), and IPSec. The new VPN technology can be thought of as a wire in the cloud, which changes the way enterprises approach remote access challenges. Generally speaking, the most common challenges are as follows:
A fast growing number of mobile computing devices, demanding ubiquitous access A growing demand for home and branch ofce connectivity An emerging requirement to deploy extranets that support unpredictable relationships between enterprises and their business partners
19
VPN offers solutions for these dilemmas by providing immediate remote access to the corporate Intranet, and by taking advantage of the services provided by ISPs, application service providers (ASPs), and others. You learn more about VPNs in Part V, VPN.
Benets of VPNs
In general, VPN solutions follow two basic models: service-provider dependant and service-provider independent. From a remote access perspective, both models are available, and of course, ISPs and telecommunication companies actively promote the rst model. As for which model the enterprise should choose, the following considerations must be analyzed rst:
Expected (committed) performance Security requirements Network management and access control solutions Customer support and service-level agreements (SLAs) Billing requirements Cost
The expected cost reduction of migrating users from legacy remote access services such as ISDN, Frame Relay, and dialup to VPN can be at least 20 to 50 percent. Another driving factor here is unprecedented mobilitythe user with VPN software can establish a tunnel to corporate from many different locations. The demand for VPN solutions is what drives the industry toward more and faster last-mile solutions, such as faster xDSL and more exible wireless solutions.
Limitations of VPNs
From a desktop perspective, several software products can interfere with the proper functioning of a VPN client solution. Software distribution and management becomes more critical for VPN client solutions than any other remote access medium. Hardware-based and IOS-based VPN clients are less susceptible to incompatibilities with other network applications, but they pose different sets of limitations. (See Part V for more details about this topic.)
20
VPN Service Vehicles

NOTE
The following sections should be considered only in the context of using these technologies as a vehicle for VPN solutions, but not as an alternative to legacy solutions, unless the solution is based on a provider-dependent VPNs. Based on this premise, the following discussion is fairly limited.
Cable Modem Services

Cable modem technology has been in the market for a long time, but the Internet generation has imposed new features on it. The technology uses cable, which has been used by cable TV operators to deliver TV services. The cable modem converts the digital signals over the cable into analog signals, and it also carries data packets on radio frequencies (RFs), which enables it to carry video streams. When the network includes a ber segment, the systems are called hybrid systems. When the network consists of ber and coaxial cable, it is called a hybrid ber-coaxial (HFC) network. Cable networks use bandwidth much greater than 4kHz narrowband and most systems operate at 1 GHz (broadband). These systems can perform full-duplex communications and add analog voice to the spectrum of services. To deliver data services over a cable network, one television channel (of about 6 MHz) in the 50 to 750 MHz band is allocated for downstream trafc to remote users, and another channel (of about 6 MHz) in the 5 to 42 MHz band carries upstream signals to the host routers. A single downstream channel of 6 MHz can support up to 27 Mbps by using 64 quadrature amplitude modulation (QAM) transmission technology. Upstream channels can deliver 500 kbps to 10 Mbps from homes by using 16 QAM or quadrature phase-shift keying (QPSK) modulation technique.
Benets of Cable Modem Services

The most signicant benet of cable is the enormous bandwidth that can be shared between many users. Active subscribers that are connected to a given cable network segment typically include 500 to 2000 homes on a modern HFC network. An individual cable subscriber can easily use bandwidth up to 10 Mbps downstream. FCC regulations have restricted the bandwidth to between 5 to 50 MHz for interactive services only. Another advantage of cable modems that are based on coax cable is that most traditional copper-based network problems are eliminated. These problems include analog loops and coils, trunking capacity, and switching resources. The coax cable from a users home is aggregated in remote ber units, and from there they can be terminated directly to the Internet routers in the cable TV headend equipment. If voice services are provided concurrently, only the voice trafc is directed to the PSTN networks. The best alternative
21
is when the cable provider is also a LEC, and the voice switch is next to the cable router in the CO. Another benet is that the analog nature of the signals provide one type of signaling for all data, voice, and video services, which creates fewer signal transformations from type A-D and D-A, and improves the quality. The cable can connect to the users LAN environment by using a standard 10Base-T Ethernet card, a Universal Serial Bus (USB) connection, or a transparent combination of them. Internal standard PCI modems are also available in the market. The integration of PC and TV in services such as Internet TV and PC-TV provide the convergence of voice, video, and data. The relatively inexpensive RF devices and the ability of service providers to easily transform the type of services they deliver is another advantage of cable. Manufacturers can provide a wide range of services, available at the headend, which are based on modularity and service compatibility. The Cisco ubr7200 Series routers (wwwsearch.cisco.com/pcgi-bin/search/public.pl?q=cable&searchselector=0&num=10) support cable telephony, streaming video, data services, VPN, telecommuting, and multiple dwelling units (high-speed integrated data, voice, and video services within apartment buildings and business complexes). Supported standards include all major standards such as Data-over-Cable Service Interface Specications (DOCSIS) 1.0, EuroDOCSIS, and the upcoming DOCSIS 1.1 standard. Cable operators can choose the appropriate services and devices to optimize their capital investment with a single platform. A variety of radio frequency modem cards provide multiple downstream and upstream port densities over hybrid ber-coaxial networks, and the xed wireless card uses next-generation wireless technology to deliver the highest available data rates over obstructed links. Cable technology for enterprise remote access using a fully outsourced model is possible but rarely used. Cable providers typically focus on the consumer market. The headend routers atypically are at the Internet providers premises.
Limitations of Cable Modem Services

On the CPE side, most home-owned splitters and drop cables need to be re-installed because of the ingress noise that can cause serious performance degradations. The 5 to 42 or 5 to 50 MHz band is susceptible to interference from appliances such as refrigerators, vacuums, or other home devices that create concentrated radiation in this bandwidth, making it unusable. To address this situation, cable providers prefer to use lters, or normal PSTN modems to provide upstream communication. In turn, the latter solution creates problems when using a VPN over cable service. Maybe the most serious drawback for cable technology is the lack of a committed rate and contention. Depending on the subscription and usage in a particular area, an overabundance of concurrent users who are using the same upstream direction creates congestion and overuse concerns. For enterprises, this creates a next to impossible situation for capacity
22
planning, where consequently all planning and management of the available bandwidth cannot be handled successfully. Cable technologies raise another concern about security. In a shared-media environment, the security design requires extra attention because transmissions can be intercepted within the neighborhood. However, VPN solutions are changing this situation by enabling the remote user to securely connect to the corporate network over VPN (refer to Figure 1-1). Instruct users to clearly understand the terms and conditions of their ISP contract because many providers are now restricting the use of IPSec-based solutions over their consumer grade services, which requires the user to upgrade to business-class service.
xDSL Services
Historically, the vast majority of residential copper lines were installed with the presumption of only carrying narrowband (4 kHz) voice signals. The access network consists of the local loops and associated equipment that connects the users location to the CO. This network typically consists of cable bundles that carry thousands of twisted wire pairs to Feeder Distribution Interfaces (FDIs). FDIs are points where dedicated cable is extended out to the individual users neighborhood. Some homes are located a long way from the CO and require a long local loop, which creates attenuation problems with the signals that must be corrected. LECs have three primary ways to deal with long loops:
Use loading coils to modify the electrical characteristics of the local loop, which allows better quality voice frequency transmission over extended distances (typically greater than 18,000 feet). In this extended distance scenario, loading coils are placed every 6000 feet on the line. Set up remote termination points where the signals can be terminated at an intermediate point, and aggregated and backhauled to the CO where the switching equipment is located. Build a serving wire center (SWC) that does not have switching equipment, but does have the transmission equipment that connects to other central ofces. The backhaul to the CO or SWC through T1/E1 circuits can be based on copper or ber-based technologies.
Ironically, the same techniques later prevented high-speed features over the same copper circuits. Re-inspection of long loops is based on a technique called local loop qualication, which was created to signicantly increase the bandwidth of available copper loops. The techniques that conduct loop qualication include the following:
Accurately testing the length of the loop is important. Even if the loop does not contain shorts, opens, and bridged taps, the wire itself has loss. The longer the loop, the more loss, which affects the transmission rates. The transmission rate is in inverse relationship to the length of the loop, so it is imperative to know the length of the
23
subscriber loop. The techniques are single-ended capacitive or resistance measurement (based on Ohms law). Because the latter technique requires a short on the CPE, the preferred option is the tone measurement.
Determining if loading coils are present is essential. Loading coils are in-line inductors, which are used as a low bandwidth lter to balance voice transmission. They are installed in all local loops longer than 18,000 feet. In many cases, they still exist and are DSL-killers because by balancing the line, they also reduce the available bandwidth. Detecting the presence of bridged taps is necessary. They are lengths of open wire that are connected in parallel with the loop. They can exist anywhere and can be part of unused pairs, loose pairs, or they can exist between the CO and the CPE. Testing for crosstalk is necessary. Long cables, power cables, or cables running side by side with other cabling systems are susceptible to crosstalk. This is because crosstalk-induced signals combine with signals that are intended for transmission over the copper wire loop. The result is a slightly different shaped waveform than was originally transmitted. Crosstalk can be categorized in one of two forms. Near-end crosstalk (NEXT) is the most signicant because the high-energy signal from an adjacent system can induce relatively signicant crosstalk into the primary signal. Far-end crosstalk (FEXT) is typically less of an issue because the far-end interfering signal is attenuated as it traverses the loop.
A standard device for evaluating the subscriber line is called a time domain reectometer (TDR), which can detect short and open circuits, loading coils, and bridged taps. The best way to visually analyze the quality of the loop is to use a spectrum analyzer, which provides a clear picture of the feasibility of using a particular loop for xDSL service. These measures ensure that the typical local loop, which is well designed for low voice bands, can achieve a broader spectrum at 1000 kHz and higher. ADSL uses frequencydivision multiplexing (FDM) or echo-cancellation techniques to divide the available bandwidth. In the case of FDM, if the band is 1000-kHz wide, it is divided into three bands: The lower end (0 to 20 kHz) is designated for POTS, the 25 to 200-kHz band is used for upstream transmission, and the last portion is used for downstream transmissions. Two guard bands at 5 kHz and 50 kHz separate them. In the case of echo cancellation, the 25 to 1000 kHz-band is designated for data communications and the upstream direction is part of the downstream band. Both techniques have advantages and disadvantages, but it is important to know that ADSL provides a range up to 5.5 km (18,000 feet), depending on the cable quality. The following are brief descriptions of the established xDSL technologies, where one of the differentiators is symmetric (the same speed in both directions) and asymmetric (refer to Table 1-1).
24
IDSL
IDSL technology is the rst DSL technology, based on the 2B1Q coding scheme (see Chapter 2), to bundle two 64-k channels and to use the D channel for data transfer, which yields 144 kbps. It runs over one pair of copper wires up to a maximum of 18,000 feet.
ADSL
This is an asymmetric type of broadband service, which usually uses different coding schemes to reach 18,000 feet. The Cisco 827 series ADSL router, for example, uses the following coding schemes:

SDSL
ANSI-DMTANSI full rate mode AutoAuto detect mode ITU-DMTITU full rate mode SplitterlessG.lite mode
SDSL is the best opportunity to reuse the existing one pair analog lines. The line is typically provisioned for 768 kbps. It is expected to be replaced by SHDSL.
RADSL
RADSL contains adaptive features. When lines are tested but do not behave in an expected way, the Discrete Multi-Tone (DMT)-based technology of RADSL is preferred.
CDSL
CDSL is a relative of RADSL and ADSL. It is more modest in terms of data rates, especially in the upstream direction. It is a no-splitter type of DSL, where the splitters and the extra wiring are not necessary. This differs from ADSL and RADSL, where splitters split the frequency bands and prevent interference between different frequency bands, which ultimately protects the standard 4-kHz voice frequency band from interference.
HDSL/HDSL2
HDSL is deployed over T1 in the U.S., and E1 in Europe. A combination with DMT is also available. The HDSL technology runs over 2 copper pairs, and HDSL2 runs over 1 copper pair. Both provide service if the users home is closer than 15,000 feet from the CO.
25
VDSL
VDSL is the fastest of all DSL technologies, but has distance limitations of 4500 feet using copper pairs, and requires ATM over ber for distances greater than 4500 feet.
Benets of xDSL Services

From a remote access perspective, xDSL offers great data rates, a variety of services, and future integration with all available carriers in the market, including Frame Relay and ATM networks, T1/E1, and T3/E3-carriers.
Limitations of xDSL Services

The availability of xDSL, even in the U.S. market, is limited and the ability of ILECs to deliver xDSL service remains to be proven. Loop limitations are preventing existing copper pairs from running higher frequency data transmissions and, according to some sources, more than 700 to 800 thousand U.S. households experience these limitations with their DSL service. Some estimates show that, in any given LATA, more than 20 percent of local loops need to be reinspected. (See www.dsl.com.)
Wireless Broadband Services

Fixed wireless technologies are emerging wireless alternatives that offer high-speed broadband access for data services. The decision to deploy broadband wireless services, whether the choice includes Local Multipoint Distribution Service (LMDS), Multichannel Multipoint Distribution System (MMDS), or unlicensed spectrum systems, also depends on the availability of other broadband access solutions and the suitability of these solutions to customer bandwidth and service requirements. Broadband wireless offers a high-speed alternative for bridging the critical last mile between high-speed IP backbones and customers of high-speed data services.
MMDS
MMDS includes various services and bandwidths. Deployed in a point-to-multipoint topology, MMDS generally provides a maximum of 10 Mbps speeds per customer. MMDS signals generally carry 30 to 35 miles from the transmitter with single cell coverage of 2800 to 3800 square miles. The service comprises 33 channels, which are broken down in a way to provide different types of services. Twenty out of 33 channels are used for a component, called Instructional Television Fixed Service (ITFS), where the service provider maps the channels to the subscribers CPE by transparent switching. In turn, the subscriber must be eligible for the service, and subscribe for a certain amount of hours of service.
26
The next 11 channels are assigned to MMDS and the remaining 2 channels to Multipoint Distribution System (MDS). The U.S. market primarily uses this technology, combined with cable, which is referred to as wireless cable. As for the international market, the demand is greater and growing faster for pure MMDS. Coax cable is the most expensive way of delivering TV signals. MMDS offers an alternative by delivering a complete package of services in the 2.5 to 2.7 GHz frequency range. It is important to install the antennas at the highest peaks in the area, to ensure maximum coverage. At the receiver side, the remote user uses a small antenna or parabolic reector. The transformation of UHF and VHF signals to microwave and vice versa occurs on both the sender and receiver side. Across the U.S., only a handful of operators have started to provide broadband services over a MMDS infrastructure. Recently, carriers such as Sprint, Verizon, and SBC have invested in these solutions and, as a result, the market and variety of services are expected to grow. The Cisco uBR7246 Universal Broadband Router combines the functionality of the Cisco 7200 router and a headend wireless modem in one integrated platform. An end-to-end wireless architecture is also constructed to support residential locations. Cisco Aironet 350 Series wireless local-area products can be combined with a MMDS broadband wireless local loop to provide an end-to-end wireless architecture that supports high-speed Internet access for the consumer located in multidwelling units. Using this architecture, Cisco Aironet wireless products connect to broadband wireless enabled routers. Cisco solutions also include a wireless line card (uBR-MCW-MDA), which ts in a 7223 or 7246 uBR or VXR router, and a MMDS transverter (SX11127A) with duplexor. CPE gear includes either a 2600 or 3600 family router for MxU, or a 950 family router for smaller SMB prospects. Wireless technology gives service providers an alternative lastmile access solution that complements more traditional broadband access technology offerings such as DSL and cable. Cisco MMDS-based solutions are part of the Architecture for Voice, Video and Integrated data (AVVID).
LMDS
On the horizon is LMDS, a multi-cell, point-to-multipoint wireless distribution system, which operates initially in the 27.5 to 29.5 GHz frequency band in the U.S., and the 24 to 40 GHz band overseas. Using a higher than MMDS frequency band, LMDS covers areas only 3 to 6 miles in diameter and can be deployed in asymmetric and symmetric congurations. Compared with two-way communications, LMDS has smaller coverage area, but it can provide faster data rates. LMDS provides bandwidth in the OC-1 to OC-12 range, which is considerably greater than other wireless services. It is designed to provide the last mile from a carrier of data services to a large building or complex, where it is less costly to set up LMDS transceivers on rooftops than to dig up the ground to install optical ber. Cells cover the area, and the technology can be considered cellular cable TV. The cell structure overcomes some of the
27
line-of-sight issues of MMDS. Passive and active repeaters and passive reectors cover the shadow areas. The adjacent cells use the same frequencies but with different polarization. LDMS uses frequency modulation (FM), not the standard amplitude modulation (AM) that is typical for cable systems. FM provides higher quality, and combined with the cell structure, requires only a small six-inch square antenna for signal exchange.
Benets of Wireless Broadband Services

From a remote access point of view, it is important to consider these technologies as a viable alternative to the existing environment. It is clear that the future belongs to wireless technologies. The current MMDS and LMDS solutions provide data rates of 40 to 54 Mbps downstream. If MMDS and LMDS are the future technologies for wireless, what future advancements should you expect? The price and innovation of these technologies are expected to play a major role in dening future remote access solutions.
Limitations of Wireless Broadband Services

Both technologies are focused in urban areas where population concentrations are high. They also inherit the limitations of line-of-sight technologies, which results in limited availability. Scalability of this service is not easy. It depends on the density of the population in the area and their willingness to subscribe to a new technology that traditionally offers one-way (downstream) data delivery, with a voice option still not available. Using VPN over MMDS and LMDS should not create any issues because the technologies do not have any impact on the third-layer protocols and they create a transparent environment for IPSec-based solutions. (See www.sprintbroadbanddirect.com/.) However, the increased latency (many times more than in a wired network) creates some issues when used for time-sensitive applications, including interactive, terminal-based designs, Voice over IP, and multicast. Also, security and QoS/contention issues associated with cable are also present with wireless.
Unlicensed Frequencies
Based on wireless LAN equipment, unlicensed point-to-point radios capable of 100 Mbps throughputs currently exist. At these speeds, however, distance limitations are great. Twenty-mile links are currently possible with unlicensed spectrum radios on a point-topoint basis. Time and cost savings, in the absence of licensing, favor the use of these frequencies. However, the possibility of signal interference and various technical limitations make these systems less appealing. Unlicensed spectrum radios have been deployed (approximately 200 deployments) by ISPs in the US in rural areas, where broadband service might be otherwise unavailable. The Cisco WT-2750 system operates
28
not only at MMDS, but Unlicensed National Information Infrastructure (U-NII) bands as well. The Cisco WT-2710 system operates in the U-NII band only. U-NII provides both point-to-point (up to 20 miles) and point-to-multipoint solutions (up to 7 miles), and operates in the 5.7 GHz band.
Satellite Services
Direct Broadband Satellite (DBS) is a typical service for satellite communications. The system is capable of delivering downstream data at a rate of 23 Mbps by using one-way communication. All solutions are based on MPEG I Layer II audio encoding and use extensive compression methods. The upstream directions in early deployment for data were based on PSTN-wired modems, which was not a successful solution, especially combined with VPN technology. The most common speed offering is 400 kbps to 1 Mbps for a single user (www.directpc.com), or 400 kbps to 1 Mbps downstream and 64 to 128 kbps upstream (www.starband.com). The satellites are in geosynchronous earth orbit (GEO) and evidently for remote access purposes, there are latency issues. From measurements taken of the latter providers service, a latency of 0.7 seconds for one-way is typical. Reliability and latency are factors that concern most satellite providers. Most of todays satellite systems are reliable; however, satellite links also suffer a 1 to 2 percent packet loss. (See www.internettrafcreport.com/.) The satellite round-trip time (RTT) is 540 ms and the terrestrial side is about 150 ms; thus, the total RTT for the TCP connection is about 700 ms.
NOTE
My measurements show that the error level is a bit higher. Here is a Pchar output from a satellite connection, showing about 6 to 8 percent reliability (depending on if it is day or night), and about 0.8s one way RTT:
... XXX.78.249.254 (misc-XXX-78-249-254.pool.starband.net) Partial loss: 12 / 138 (8%) Partial char: rtt = 813.546203 ms, (b = 0.189682 ms/B), r2 = 0.149781 stddev rtt = 99.374317, stddev b = 0.070578 Partial queueing: avg = 0.369341 ms (133278 bytes) Hop char: rtt = 739.066865 ms, bw = 42.346064 kbps Hop queueing: avg = 0.362248 ms (1917 bytes)
Measurements show that regardless of the latency and reliability factors, the service can achieve speeds in the range of 500 kbps to 1 Mbps download, and approximately 128 kbps upload. The solution, implemented by StarBand, is based on an upper-layer solution called Internet Page Accelerator (IPA). In terms of the client/server technology, the Remote Page Accelerator (RPA) client is installed on the computer and connects to the satellite modem. The server side is located in the Network Operations Center (NOC), and is called the Host Page Accelerator (HPA). Together, these two individual units make up the IPA (see Figure 1-2). (See www.starband.com.)
29
A possible solution for acceleration of the performance characteristics is based on Flash Networks proprietary protocol, called Boosted Session Transport (BST) and its product line NettGain. NettGain products are implemented by organizations such as StarBand, VSAT, NASA, and SAT-TEL.
Figure 1-2 Remote and Host Page Accelerators (RPAs and HPAs) create the Internet Page Acceleration (IPA) of StarBand
HPA
Satellite
Network Operations Center
RPA
Your Browser or Other Supported Application IPA = Internet Page Accelerator HPA = Host Page Accelerator RPA = Remote Page Accelerator
Remote Page Accelerator
The BST protocol is a TCP-like reliable protocol that replaces TCP over the path where performance optimization is needed. TCP packets from a source location are transformed from TCP to BST and sent to the destination. There they are transformed back into TCP and sent to the originally intended target. NettGain manages both BST and TCP ow control and data queues to allow a full protocol conversion. Another possible solution is the Cisco Content Engine 500 Series. Different techniques are combined in Cisco Application and Content Networking Software, which offer more complex solutions and allow certain content to be boosted and achieve better throughput times in high-latency networks. (See www.cisco.com/univercd/cc/td/doc/product/ webscale/content/ce500/index.htm.) The accelerators are not always compatible with IPSec-based VPNs because the Integrity Check Value (ICV) is calculated based on the immutable elds of the TCP/IP stack. A satisfactory resolution is not available so far and research continues. Satellite-based solutions with IPSsec VPN have proven to be a good solution for applications such as web browsing, e-mails, and data transfer. If used for time-sensitive applications, such as VoIP or interactive client/server applications, they are not the best
30
remote access solution. Cost is another concern when this solution is chosen for remote access services because of higher hardware cost. The next generation of low earth orbit satellites (LEO), driven by companies such as Hughes Communications, CyberStar and Motorola, are designed to reduce latency issues, but not to replace the GEO satellites. Another alternative satellite solution is described in Chapter 2 in the section, Modulation and Line-Coding Techniques in Hybrid Networks.
Provisioning of Enterprise Remote Access Services

A key function of IT planning and design includes provisioning of remote access services for employees. Remote work is dened as work conducted away from corporate facilities. The provisioning activities described in this section support remote workers in a home ofce (telecommuting), as opposed to another type of virtual ofce (for example, a satellite or hotel ofce), instead of commuting to a corporate facility. Ciscos internal remote access offering has changed over the last couple of years; however, the following information describes the processes that Cisco used to provision services for Frame Relay, ISDN, DSL, and VPN.
NOTE
Up to 80 percent of Cisco employees currently work remotely at least one day of their regular workweek.
All successful remote work arrangements meet the needs of the business while enabling employees to maximize productivity in an advantageous work environment. Working remotely can positively impact job satisfaction, maximize the use of on-site workspace, decrease facilities costs, reduce trafc congestion and enhance air quality, attract and retain key employees, expand the pool of potential candidates, and provide opportunities to showcase Ciscos technology. Ciscos internal remote access services are categorized as Cisco-managed, vendormanaged, and user-managed. The Cisco-managed services account for the Frame Relay, ISDN, and dialup services, where an internal Cisco IT team provided support for the endto-end solution. The vendor-managed solution was an outsourced private DSL network where all support services were provided by the vendor. The user-managed solution was created for the internal VPN deployment, and it was a hybrid solution where end users managed the home connection with their selected ISP, and Cisco IT support managed the headend VPN concentrators. For Cisco-managed services, the provisioning IT analysts provide dual functions of administration and provisioning, which include installation, deactivation, and move location of services. Within Cisco, the provisioning of all remote access services requires the approval of the employees manager. An automated approval process was used to manage this process.
31
Over the course of time, the policies and procedures have changed from a totally manual process to a semi-automated process. The type of technologies offered, and the employees to whom the services are offered changed as the business climate grew in size and authority. In general, the provisioning process includes the following:
Installation procedures (sometimes called new installs) Automated disconnect procedures Billing procedures
Frame Relay circuits were usually provisioned for full-time telecommuters, who have no ofce space and work entirely from home. The full-time usage could usually justify the high monthly service charge, and was more cost effective than a usage based solution. In some cases, the employees unique business requirements limited the remote access solution to a Frame Relay connection. A single vendor provides service and the charge is based on linear distance from the employee home to a vendor point of presence (POP). These circuits are piped directly into Cisco from that POP, providing speeds starting from 56 kbps and including fractional T1. Part-time telecommuters, those needing higher bandwidth than dialup, could be authorized for an ISDN service to be installed in their home. ISDN is mostly usage based and depending on the employees usage requirements, would be more cost effective than Frame Relay. This service usually is provided by the ILEC for the region, offering speeds of 128 kbps and providing two analog phones for analog telephone calls, negating the need for an additional wire pair to make business calls. The necessary steps for provisioning Frame Relay and ISDN circuits for enterprise remote access needs are shown in Figure 1-3. Figure 1-3 shows the provisioning process for Frame Relay and ISDN. Some of the descriptions are based on an automated system for provisioning, used by Cisco. Figure 1-3 is a graphic overview of the manual provisioning order process for the installation of Frame Relay and ISDN. A client requests a remote access service through an internal web-based application. After posting the required information to a template, the request is forwarded to management for approval. After it is approved, a case is opened in a case management tool and the request is sent to the provisioning team. The provisioning team member takes action in several areas:
Case management tool actionUpdates the case with the appropriate language to document the process and timelines needed to track the installation of the order, and to set realistic expectations for the client. Provisioning page actionReviews the order template for accuracy and sends to the appropriate vendor. Administrative page actionUpdates the database with the referenced case number.
32
Figure 1-3
The Provisioning Process for Frame Relay and ISDN

Request Submitted to Employees Management for Approval
Employee Requests Remote Access Service ISDN / Frame Relay
Database Record Created
Request Approved
AutoOpen Case Within Management Tool. Case Placed Into Remote Access-Provisioning Queue Provisioner Opens Provisioning Page and Clicks New Request
Provisioner Opens Administration Page
Provisioner Yanks or Accepts Case and Changes Classification Fields
Provisioner Enters User ID in Search Field and Clicks Search
Provisioner Post Note to the Case or E-mail from the Case Signifying Action Taken to Place ISDN Order With Either ILEC or Third-Party Vendor
Provisioner Chooses Applicable Record and Clicks on User ID to Open
Provisioner Highlights Appropriate ID and Clicks Show Button
Provisioner Chooses Place Order
Provisioner Enters Case Number into Case # Box and Clicks Update
Provisioner Changes Status Block to Read In Progress
Provisioner Verifies Information on Outgoing E-mail and clicks Submit
Provisioner Moves Case to Appropriate WIP Bin
E-mail Order Submitted to the Vendor and an Order Verificition Notice Sent to the Requesting Employee
Provisioner Saves Changes and Clicks Done
Case Management Tool Action
Provisioning Page Action
Administrative Page Action
Manual-Provisioning Order Process-Installation
As availability for xDSL services expanded, DSL became a vendor-managed remote access option with xed rates and lower cost than either ISDN or Frame Relay. It was preferred to have a contractual relationship with a single vendor to provide a low cost, xed rate private DSL network. Bandwidth varied from 128 k to 512 k depending on the distance from the residence to the providers DSLAM in the ILEC CO. IDSL and ADSL services were
33
available, and with ADSL bandwidths in excess of 384 k, a Cisco IP telephone could be used effectively from home. This option is shown in Figure 1-1, where the xDSL service is hosted to the corporate-managed router (upper half). Apart from the vendor-managed private solution, xDSL should be considered in the VPN context as a transport medium. This option is shown in Figure 1-1 in the upper half, where an ISP hosts the xDSL service, but the tunnel to the corporate network is terminated on the VPN concentrator. This type of solution is expected to be the pre-dominant remote access solution of the future. With new technologies driving down the price of Internet access, Ciscos user-managed VPN solution provides the necessary set of options for VPN over technologies. The solution is technology independent and works with any ISP that provides access to the Internet through cable, xDSL, ISDN, satellite, or wireless technologies. Through the manual process, a provisioning IT analyst received an e-mail or telephone request, and assessed the need for a remote access service (refer to Figure 1-3). After the type of service need was determined, an order was placed with the ILEC or with a third-party vendor who, in turn, placed the order with an ILEC. In heavily Cisco populated areas, agreements were made with the ILEC to accept these orders. In rural or sparsely Cisco populated areas, an agreement went to a third-party vendor to act on Ciscos behalf to place those orders.
NOTE
The following text provides some Cisco specics, which denitely can be addressed differently as necessary. This section concerns how Cisco is dealing with provisioning. Cisco IT uses an internally developed semi-automated, fully integrated online management system that assists with the provisioning of ISDN/FR services for employees. This allowed for the following:
Automates the provisioning process Automates vendor/order communication Provides a central, uniform repository for ISDN and Frame Relay related data Improves asset-tracking measures Labor cost savings Improved delivery timeframes Improved data accuracy/integrity Improved vendor tracking measures Improved asset management
The implementation of this system provided the following:
34
Automated order e-mail templates were created to meet the processing demands of each ILEC and the requirements of Cisco:
The service orders were standard for Frame Relay at 56 k and 128 k. The circuit was directed into Ciscos Intranet, using Cisco as the employees ISP. The service orders were standard for ISDN, the speed was 128 k with 256 k B channels. The second channel was given voice priority over data when an analog phone was used in conjunction with the Cisco router. Long distance for ISDN was standard in accordance with a Cisco-vendor contract. The circuit was directed into Ciscos Intranet, using Cisco as the employees ISP. The service orders were standard for the vendor-managed DSL. After management approval of a DSL service request, the vendor processed the order and the vendor communicated directly with the Cisco employee. Cisco provisioning analysts only provided follow-up and expediting when deemed necessary. The service orders for DSL are standard, providing the maximum bandwidth available to the employee, based on the employee distance to the ILEC DSLAM. The circuit is directed into Ciscos Intranet, using Cisco as the employees ISP.
NOTE
Installation of any of these services would normally take 46 weeks from the date the order was placed.
After order verication was received from the ILEC for ISDN/Frame Relay, the remote access engineers could congure a Cisco router designed for the intended service and ship it to the user. DSL routers are congured and shipped by the contracted vendor. Routing for Frame Relay services would be over a dedicated service provider-based private network into Cisco (see more in Chapter 3, and Chapter 18, Frame Relay Troubleshooting Scenarios). Routing for ISDN would be one of several different ways: local Centrex for employees living in the immediate vicinity to the Cisco campus in San Jose or RTP, local long distance for other intra-LATA employees, or local long distance for local inter-LATA employees. All others would be routed on a Cisco contracted 800 number service into a Cisco campus. The routing and distance would determine monthly and usage service rates. At the time of writing this book, Frame Relay and ISDN are no longer offered as a standard Cisco provided service. The provisioning mechanisms are still available, but not activated for employee access, although special cases are handled as needed. The standard remote access offering is the user-managed service that uses VPN to gain access to the Cisco Intranet.
Review Questions
35
Summary
In this chapter, you learned the specics of the remote access environment, and the management considerations when different remote access designs are considered. The denition of the remote access population here is based on a legacy criteria. As previously stated, different approaches also can be applied, based on the job functions of the employee. This chapter provided a brief description of remote access options in the following aspects: management considerations and the pros and cons of remote access solutions; dening the remote access population; legacy remote access solutions, and VPNs over some of the most popular technologies, such as cable modems, xDSL, wireless, and satellite services. Finally, the chapter explained one possible approach to the provisioning of corporate circuits which, without any doubt, will affect your troubleshooting efforts, especially in new-install cases, as explained in the following chapters.
Review Questions
Answers to the review questions can be found in Appendix A, Answers to Review Questions.
1 Why are remote access networks considered the most difcult type of network to
support?
2 What are the main categories that the management should consider when making
remote access service decisions?

3 Give an example for narrowband, baseband, and broadband services. 4 Explain what MMDS and LMDS stand for. 5 Name two benets of dial-in modem technology for remote access. 6 Name two limitations of dial-in modem technology for remote access. 7 Name two benets of ISDN for remote access. 8 Name two limitations of ISDN technology for remote access. 9 Name two benets of Frame Relay for remote access. 10 Name two limitations of Frame Relay technology for remote access. 11 Name two benets of VPN for remote access. 12 Name two benets of cable modems for remote access. 13 Name two benets of xDSL for remote access. 14 Name two limitations of wireless and satellite for remote access.
CHAPTER
Telecommunication Basics
The discussion in this chapter covers modulations, line-coding schemes, and techniques for wired, hybrid, wireless, and emerging media. Emerging wireless local-area network (LAN) coding techniques require special attention, and they are covered in detail. The importance of this chapter is to provide you with the fundamental information required for troubleshooting different technical solutions. Information needs to be transformed into signals to be exchanged over the telecommunication media. When troubleshooting in an enterprise environment, it is important to have a relatively broad understanding of how the information is transformed from one form to another and how the information is carried over the providers network. This chapter focuses on representing the following:
Legacy modulations, line-coding schemes, and techniques for the wired media with special attention to the evolving xDSL techniques. Extended discussion about some of the emerging wireless modulations and coding schemes because of the expected growth of end-to-end wireless solutions and hybrid solutions. Detailed information about clocking, line coding, and framing in the carriers system, and discussion about T1/Primary Rate Interfaces (PRIs).
In telecommunications, the transfer of information from one point to another is based on signals that can be classied as continuous and discrete, or analog and digital. Analog signals are continuous and carry distinguishable states, called constellations, that can be interpreted as different from each other, such as positive and negative components of the sinusoid, or analog waves with a different amplitude, frequency, or phase. The Public Switched Telephone Network (PSTN), which was developed in the early 1960s, is primarily an analog network. Analog signals are characterized by amplitude, phase, and frequency. The analog transmission can degenerate from changes in the electrical characteristics of the wire that are caused by thunderstorms, snow, rain, and electrical charges. Discrete, or digital, signals carry the information in dened discrete moments or discrete states. In digital systems, the terminology is based on the base 2 numerical system (1 and 0), where the digital signal has at least two distinguishable states, which are interpreted as
38
Chapter 2: Telecommunication Basics
1 or 0. Although the analog transmissions quality can degrade because of interference with other sources, the digital transmission is generally more reliable because error-correcting codes can be applied. Every correction code adds extra bits to the user transmission, and the general rule is that the bigger the correction code, the greater its ability to nd and recover from the error. The trade-off is that less user data can be transmitted. The optimum balance must be determined.
Shannons Capacity Theorem

Error-correcting codes can alleviate some errors, but cannot alleviate all the errors introduced by the channel in a digital communications system. Shannons Capacity Theorem states that error-free transmission is possible as long as the transmitter does not exceed the channels capacity. N bits constitute a block of information bits that have K bits of error correction tacked on. In terms of the bit error probability (p), the probability of an error can reach 0 as N becomes larger if the following is true:
The ratio N / (N + K) = R, the rate (R) is kept constant. R is less than the channels capacity (C). C = 1 + plog2p + (1 - p)log2(1 - p).
Thus, if a repetition code has a rate of 1/3, and if you used more data bits and repeated them twice, you could transmit them through a channel error-free, if the error probability is less than 2(1-R). The capacity sets a limit on your ability to transmit digital information through a channel. The converse to the Capacity Theorem states that if R > C, the probability of a word error approaches 1 as N becomes greater. The Capacity theorem can also be stated in terms of transmission rates, by dividing the coding rate (and the capacity) by the duration of the bit interval. Shannon showed that the capacity of an additive white Gaussian noise channel is given by the following: C = BW log2 (1 + S / N) CChannel capacity in kbps BWBandwidth of transmission medium SPower of signal at the transmitting device NPower of noise received at the destination Therefore, the telephone channel with BW = 3 kHz and S / N = 1000, yields a capacity of about 30,000 bits per second (bps). The bandwidth of a twisted pair is 4 kHz, which covers the frequency spectrum for voice. Assuming a signal-to-noise ratio (SNR) of (P0/Pn) equals 1000, (30 dB), the Shannon channel capacity is as follows: C = 4000 Log 2 (1 + 1000) = 40 kbps
Modulation and Line-Coding Techniques in Wired Networks
39
The following sections are based on the assumption that the modulation techniques in wired, wireless, and hybrid media differ from each other. This classication is symbolic and is not precisely correct. The sole purpose of this classication is to represent the most common technical solutions for each media.

Modulation and demodulation are processes of converting the analog signals to digital signals and vice versa. The signal transformation from analog form to digital form is based on analog signal-to-discrete signal converters, which are known as analog-to-digital converters (ADCs), digital-to-analog converters (DACs), coder-decoders (codecs), and data service unit/channel service units (DSU/CSUs). The analog systems can still carry voice, data, and video, but are mostly designed for voice communications. The most used technique for voice digitalization is pulse code modulation (PCM). In PCM, at least 8000 analog samples of voice are required to characterize the human voice. The previous suggestion is based on the following two theorems: First, Nyquists Theorem denes the following law: C = 2 BW CTransmission speed (bps) of the channel or channel capacity BWBandwidth (bps) of the noiseless channel Second, Nyquists sampling theorem requires the following: fs 2fa faSampling frequency fsHighest frequency of the analog signal
NOTE
A source for Nyquists sampling theorem is The Telecommunications Fact Book and Illustrated Dictionary by Khan S. Ahmed (Delma Publishers Inc., 1992).
Nyquists sampling theorem states that digital sampling must take place at twice the highest frequency to reconstruct the analog signal accurately. As a result, the sampling theorem requires that, given fa = 4-kHz frequency band, fs 4000 2 = 8000 Hz. To convert analog to digital, a binary code needs to be assigned to every analog sample. An 8-bit code provides 256 levels, and enables the quality of the recovered voice to be comparable with the analog voice. The 8000 samples/second times 8 bits per sample, yields the 64 kbps necessary for a single voice channel. Good voice reproduction can be achieved using a 7-bit code per sample, and the resulting overall voice channel is 8000 samples/
40
second times 7 bits per sample, yielding 56 kbps. Regeneration of the signal is primarily based on the use of repeaters that are necessary because of attenuation of the signal.
Amplitude, Frequency, and Phase Modulations

In general, modulation and demodulation are always related to one of the three characteristics of the signalamplitude, frequency, and phaseor a combination of all or some of these characteristics. Modulation, or shifting, of any of these characteristics creates a recognizable, adequate (or sometimes called constellation) state of the signal, interprets these states as 1 or 0, and digitalizes them. In amplitude-shift keying (ASK), the 1 and 0 are represented by two different amplitudes, as shown in Figure 2-1. In some cases, instead of using two amplitudes it is more acceptable to use an amplitude and no signal, in which case the timing is crucial. ASK can be used to code more than one bit. In cases when two recognizable amplitudes are generated, the technique can code-decode 2 bits with 4 stable states: 00, 01, 10, and 11. In copper lines this technique is considered inefcient because amplitude changes (power, attenuation, interference) can generate errors. In ber media, where the attenuation of the signal is less of a consideration, 1 can be represented as a shot pulse of light, or high-amplitude light, and 0 can be low-amplitude light or the absence of light.
Figure 2-1 Amplitude-Shift Keying (ASK) Scheme
Vd(t) Vc(t) VASK(t)
Signal Power
fc=3fo fc=fo fc fc+fo fc+3fo
Frequency Spectrum Frequency
Frequency-shift keying (FSK) uses at least two different frequencies to represent 1 and 0, as shown in Figure 2-2. The scheme is less susceptible to errors than ASK and it is used for low-speed data transmissions. In phase-shift keying (PSK), 1 and 0 are coded using different phases of the signal, as shown in Figure 2-3. The signal burst of the same phase represents 0, and the signal burst of the opposite phase represents 1. This technique is more resistant to errors than ASK and FSK, but it can still be used for low-rate data transmissions.
41
Figure 2-2
Frequency-Shift Keying (FSK) Scheme
Data Signal Carrier 1 Carrier 2
vd(t) v1(t) v2(t) vFSK(t)
Signal Power
Frequency Spectrum
f1
Figure 2-3 Phase-Shift Keying (PSK) Scheme
Data Signal Carrier
f2
Frequency
vc(t) vc(t)
Phase v (t) Coherent PSK Differential
vPSK(t)
180=0 0=1 Phase Diagram
Quadrature Amplitude Modulation

Quadrature amplitude modulation (QAM) is a line-coding technique that has been used in modems for over twenty years. This technology can also be referred to as 16QAM or 4/4QAM. QAM takes advantage of the fact that if two signals are shifted to 90 degrees from each other, they can be sent simultaneously over the same frequency band. The two signals are ASK modulated, but on the receiving side they are de-shifted and the original binary codes are obtained. In general, the signal is divided by 2 and the resulting signal S(t) can be represented as the following: S(t) = d1(t)cos wct + d2(t)sin wct In simple terms, QAM modulates the amplitudes of two waves, and instead of using +-1, QAM uses 4 different amplitudes for each of the waves. As a result, there are four instead of two amplitude modulations: A1, A2, A3, and A4. The full combination of amplitude modulations and S(t) provides 16 combinations per Hertz, which is otherwise called 4 bps or 4 baud. The 16 established constellations look like 0000, 0001, ... (to 1111).
42
xDSL Coding Techniques

The emergence of digital subscriber line (DSL) technology increased the need for more modulation techniques. Unlike other technologies, DSL uses a set of protocols that are suitable for the different types of DSL technologies. Asymmetric DSL (ADSL), in particular, refers to the family of coding schemes where the emerging Internet technologies usually require higher bandwidth in the downstream direction than in the upstream direction (see the section, xDSL Services in Chapter 1, Remote Access Overview). This fact provides the need to divide the available bandwidth asymmetrically and to provide different data rates for each direction. In terms of Cisco IOS, Cisco ADSL solutions support the following DSL operating modes: ansi-dmt, auto detect mode, itu-dmt, and splitterless (G.lite) mode.
Discrete Multi-Tone
Discrete Multi-Tone (DMT) uses multiple carrier signals at different frequencies, sending some bits on each channel. The term DMT comes from the fact that each discrete bin is at a specic frequency or tone. The available transmission band is divided into several baseband carriers, sometimes called subchannels. Upon the initialization phase, the DMT modulator sends out a test signal on each subchannel to determine the signalto-noise ratio. The modulator then assigns more bits to channels with better signal transmission quality and less to the channels with poorer quality. DMT modulation is actually a form of frequency-division multiplexing (FDM). The input data stream is split into 256 channels that have the same bandwidth, but a different center frequency, otherwise called the channel number. Cisco uses the following standard DMT modulations in its productsITU-DMT(G.992.1 TU G.DMT), ITU-T G.992.2 (G.lite), ANSI-DMT(ANSI Standard T1.413) and autorecognition ADSL mode. Example 2-1 shows a sample of Ciscos ADSL 827 router showing the content of the bins.
Example 2-1 A Sample of Ciscos ADSL 827 Router Showing the Content of the Bins
pnedeltc-dsl#sh controllers atm 0 <output omitted> DMT Bits Per Bin 00: 0 0 0 0 0 0 0 10: 6 6 6 6 6 5 6 20: 0 0 0 0 0 0 4 30: 8 7 8 8 8 8 8 40: 9 9 9 9 9 9 9 50: A A A A A A 2
5 5 5 8 9 A
4 6 5 8 9 A
5 6 6 8 9 A
5 5 6 8 9 A
5 6 6 8 9 A
6 5 7 8 A A
6 6 7 8 A A
6 6 7 8 A A
6 0 8 8 A A
43
Example 2-1 A Sample of Ciscos ADSL 827 Router Showing the Content of the Bins (Continued)
60: 9 A 70: 9 9 80: 9 9 90: 8 8 A0: 8 8 B0: 7 7 C0: 7 7 D0: 7 7 E0: 6 6 F0: 6 6 <output 9 9 9 9 9 9 9 9 9 9 9 9 8 8 9 8 8 8 8 8 8 8 8 8 8 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 6 6 6 6 6 5 5 5 4 4 omitted> 9 9 9 8 8 7 7 7 6 2 9 9 8 8 8 7 7 7 6 2 9 9 8 8 8 7 7 7 6 0 9 9 8 8 8 7 7 7 6 0 9 9 8 8 8 7 7 7 6 0 9 9 8 8 7 5 7 7 6 0 9 9 8 8 7 7 7 7 6 0 9 9 8 8 7 7 7 6 6 0 9 9 8 8 7 7 7 6 6 0
Every row has 16 (10h) columns (bins), where the rst seven 0s are the voice (POTS) and guard channels. The following 24 non-zero bins, which results in about a 103-MHz band, are the upstream channels, followed by 6 bins of guard channels. The last group of 224 bins represent 224 downstream channels. Every bin is QAM modulated, and every value is calculated, based on the following formula: #bits/sub_symbol#k = Round [ log2 (3 * SNR(k)/Q-1(BER)2 + 1)] SNRSignal-to-noise ratio kDMT tone index QError function (erf function) BERBit error rate Using multiple narrowband (baseband) channels results in the following advantages:
All channels become independent regardless of line characteristics. Thus channels can be individually decoded. The optimum decoder for each channel uses less memory and it is easy to implement. Theoretical channel capacity, as calculated by Shannons information theory, can be approached by this line code with reasonable complexity.
The ANSI ADSL system uses 256 frequency channels or bins. Data is separately modulated into each bin based on how much data each bin can hold. The amount of data each bin can hold is a function of loop characteristics and frequency. All channels have a bandwidth of 4.3125 kHz and the frequency difference between two successive channels is also 4.3125 kHz. This technology uses frequency bands above the POTS spectrum to pass ADSL data both upstream and downstream. The upstream band is from approximately 25 kHz to about 138 kHz, and the downstream band starts at 142 kHz (25 kHz if echo cancellation is used) and extends to 1.1 MHz. Each of these bands is further subdivided into 4.3125-kHz bins. Data is separately modulated into each bin based on how much data each bin can hold. The amount of data each bin can hold is a function of loop characteristics and frequency. A new batch of data is sent in each bin 4000 times a second. At the next layer up in the protocol stack, a Super Frame (SF) structure is dened. The SF structure denes how the payload data and overhead data is assembled. Additionally, it denes how the data in the SF is
44
allocated to the binshere, Cisco denes interleave mode and fast mode, where interleave mode performs Reed-Solomon error correction. DMT is generally accepted to be better at rate adaptation (changing speed because of line conditions), varying loop conditions (bridge taps, mixed gauges), noise and crosstalk handling, and it is better for voice purposes.
Carrierless Amplitude/Phase Modulation

Carrierless amplitude/phase modulation (CAP) (also referred to as ATR-R) enables simple echo cancellation (although many CAP products use FDM), provides less delay (only 25 percent compared to DMT), and provides simplicity and maturity (because it is based on QAM). CAP can be referred to as an improved or suppressed QAM because, unlike QAM, CAP does not send a carrier over the line because the carrier does not carry any information. Generally speaking, if you add a rotation to the receiver side and suppress the carrier from the sender, you can get CAP from QAM. The technology is based on phase shifting (see the beginning of this chapter), but the phase of the wave changes under certain angles and it is measured from the current phase of the carrier, and not from some absolute reference phase. Because it is not absolute phase shifting, it is differential. In the simplest scenario with two phases, 1 is shifting (rotating) the phase to 180 degrees, and 0 is shifting to 0 degrees, or vice versa. This can be improved if you add two more established constellations. Because of quadrature phase-shift keying (QPSK), the signal is already sent as a combination of sine waves and cosine waves at carrier frequency, and they are already shifted by 90 degrees. QPSK as a coding technique takes its name from the term perpendicular, or quadrature. However, there is no phase shifting because the two waves are already shifted (phased, rotated), and CAP simply modulates the two amplitudes. Recently, CAP has been driven primarily by ANSI and is considered an option to DMT.
Modulation and Line-Coding Techniques in Wireless LANs

The emerging wireless LAN (WLAN) technologies offer a wide range of modulations, coding schemes, and technologies.1 WLANs hold the promise of ubiquitous access to network resources without the physical limitations of the wired network. In WLANs, (otherwise popularly known as wi- [wireless-delity]) users can move freely about their ofces or access network resources from conference rooms, lobbies, cafeterias, and campus buildings. WLANs use radio frequency (RF) waves instead of a cable infrastructure, and ensure mobile, cost-effective solutions that signicantly reduce the network installation cost per user.
45
Infrared
Infrared (IR) radio-channel falls under the visible band of radiation that exists at the lower end of the visible spectrum. It is most effective when a clear line-of-sight can be achieved between the transmitter and the receiver. The technology has two available solutions: diffused-beam and direct-beam (or line-of-sight). Currently, direct-beam WLANs offer a faster data rate than diffused-beam networks, but direct-beam is more directional because diffused-beam technology uses reected rays to transmit/receive a data signal. IR achieves lower data rates in the 1- to 2-Mbps range. IR optical signals are often used in remote control device applications.
Photonic Wireless Transmission

The only implementation of photonic WLANs use IR light transmission at the 850 to 950 Nm band of IR light with a peak power of 2 watts. The physical layer supports 1- to 2-Mbps data rates. Although photonic wireless systems potentially offer higher transmission rates than RF-based systems, they also have some distinct limitations:
IR light is restricted to line-of-sight operations; however, the use of diffuse propagation can reduce this restriction by allowing the beam to bounce off passive reective surfaces. The power output (2 watts) is low to reduce damage to the human eye; however, it limits transmissions to about 25 meters. Sensors (receivers) need to be laid out accurately otherwise the signal might not be picked up.
Photonic-based WLANs are inherently secure and are immune (as are optical ber networks) from electromagnetic interference, which can interfere with cable and RF-based systems.
Diffused IR
Diffused IR communications are described as both indirect and non-line-of-sight. The diffused IR signal, which is emitted from the transmitter, lls an enclosed area like light and does not require line-of-sight transmission. You can point the IR adapters at the ceiling or at an angle and the signal bounces off the walls and ceiling. Changing the location of the receiver does not disrupt the signal. Many diffused IR products also offer roaming capabilities, which enables you to connect several access points to the network, and connect your mobile computer to any of these access points or move between them without losing your network connection. Usually diffused IR provides a radius of 25 to 35 feet and a speed of 1 to 2 Mbps.
46
IR Summary
Overall, the advantages of IR include no government regulations controlling use and its immunity to electromagnetic interference (EMI) and RF interference. Disadvantages of IR include that it is generally a short-range technology (30-50 ft radius under ideal conditions), signals cannot penetrate solid objects, and signals can be affected by light, snow, ice, fog, and dirt. Because of its signicant limitations, IR is not a commonly used technology for WLANs.
Ultra-High Frequency Narrowband Technologies and WLAN

The term narrowband describes a technology in which the RF signal is sent in a narrow bandwidth, typically 12.5 kHz or 25 kHz. Power levels range from 1 to 2 watts for narrowband RF data systems. This narrow bandwidth combined with high power results in larger transmission distances than are available from 900-MHz or 2.4-GHz spread spectrum (SS) systems, which have lower power levels and wider bandwidths. UHF wireless data communication systems have been available since the early 1980s. These systems normally transmit in the 430- to 470-MHz frequency range, with rare systems using segments of the 800-MHz range. The lower portion of this band, 430 to 450 MHz, is often referenced as the unprotected (unlicensed) band and 450 to 470 MHz is referred to as the protected (licensed) band. In the unprotected band, RF licenses are not granted for specic frequencies and anyone is allowed to use any frequency in the band. In the protected band, RF licenses are granted for specic frequencies, which gives customers some assurance that they will have complete use of that frequency. Other terms for UHF include narrowband and 400 MHz RF. Because independent narrowband RF systems cannot coexist on the same frequency, government agencies allocate specic radio frequencies to users through RF site licenses. A limited amount of the unlicensed spectrum is also available in some countries. To have many frequencies that can be allocated to users, the bandwidth given to a specic user is small.
Synthesized Radio Technology

The term synthesized radio technology refers to the crystal-controlled products in legacy UHF products, which require factory installation of unique crystals for each possible channel frequency. Synthesized technology uses a single, standard crystal frequency. The required channel frequency is calculated by either dividing or multiplying the standard crystal frequency. Synthesized UHF-based solutions provide the ability to install standard equipment without replacing the hardware, which provides less complexity and the ability to tune each device.
Multiple Frequency Operation

Modern UHF systems allow access points to be individually congured for operation on one of several pre-programmed frequencies. Wireless stations can be programmed with a
47
list of all the frequencies used in the installed access points, which allows them to change frequencies when roaming. To increase throughput, access points can be installed with overlapping coverage but using different frequencies. Advantages include a longer range, and it is considered a low cost solution for large sites with low to medium data throughput requirements. The disadvantages include low throughput, no interoperability, and a higher potential for interference. License requirements for protected bands and larger radio and antennas that increase wireless client size are also limiting factors.
Ultra Wideband and WLANs

The origin of ultra wideband (UWB) technology stems from work in time-domain electromagnetics that started in 1962 as a simple concept. Instead of characterizing a linear time-invariant (LTI) system by the more conventional means of a swept frequency response (which is amplitude and phase measurements versus frequency), an LTI system is alternatively characterized by its impulse response. The FCC approved the technology in February 2002, and this could have a signicant impact on the WLAN industry. It could transform the industry from mainly limited radar or global positioning systems (GPSs) to more business communications. Wireless technologies, such as the 802.11 family and short-range BlueTooth radios, might be replaced by a UWB technology that has a throughput tens of thousands of times greater than the 802.11b standard. UWB energy pulses operate in the same frequency spectrum as electronic noise that is typical of printers, chips, and widespread personal electronic equipment. The implications are signicant:
The UWB does not use a carrier and consequently does not require a designated band from any of the overcrowded spectrums. It is less expensive and easier to build such devices. The electromagnetic noise requires little power (in the order of milliwatts, which is thousands of times less than cellular phones). There is less power, radiation, and distance, but there are available techniques to increase the range. A high level of security exists because it is almost impossible to lter pulse signals from the regular noise. Concerns among academics and the industry about devices operating under the 2.4GHz band. These pulses can interfere with existing broadcasts such as GPS and public safety nets. A high dependence on the way transmitters are tuned, timed, and powered.
Disadvantages of UWB that should be considered include the following:
48
UWB is an RF wireless technology, and as such is still subject to the same laws of physics as every other RF technology. Obvious tradeoffs can be made in signal-to-noise ratio versus bandwidth, and in range versus peak, depending on power levels.
WLAN Modulations and Coding Techniques

WLANs are signicantly driving the industry. The short-range BlueTooth and HiperLAN/ 2 are among the key contributors. The standards dened by the IEEE 802.11 Task Force are making the most signicant impact. At the physical layer, IEEE 802.11 denes three physical techniques for WLANs:
Diffused IR Frequency hopping spread spectrum (FH or FHSS) Direct sequence spread spectrum (DS or DSSS)
Although the IR technique operates at the baseband, the other two radio-based techniques operate at the 2.4-GHz band. They can operate WLAN devices without the need for enduser licenses. For wireless devices to be interoperable, they must conform to the same physical layer standard. All three techniques specify support for 1-Mbps and 2-Mbps data rates.
Spread Spectrum RF Transmissions

Spread Spectrum (SS) RF systems are true WLANs, which use radio frequency (RF wireless) transmission as the physical layer medium. Two major subsystems exist: FHSS and DSSS. DSSS is primarily an inter-building technology, and FHSS is primarily an intrabuilding technology. The actual technique of SS transmission was developed by the military in an attempt to reduce jamming and eavesdropping. SS transmission takes a digital signal and expands, or spreads, it so as to make it appear more similar to random background noise rather than a data signal transmission. Coding takes place either by using FSK or PSK. Both methods increase the size of the data signal and the bandwidth. Although the signal appears louder (more bandwidth) and easier to detect, the signal is unintelligible and appears as background noise unless the receiver is tuned to the correct parameters.
FHSS
FHSS is analogous to FM radio transmission as the data signal is superimposed on, or carried by, a narrowband carrier that can change frequency. The IEEE 802.11 standard provides 22 hop patterns, or frequency shifts, to choose from in the 2.4-GHz ISM band. Each channel is 1 MHz and the signal must shift frequency, or hop, at a xed hop rate (U.S. minimum is 2.5 hops/sec). This technology modulates a radio signal by shifting it from frequency to frequency at near-random intervals. This modulation protects the signal from
49
interference that concentrates around one frequency. To decode the signal, the receiver must know the rate and the sequence of the frequency shifts, thereby providing added security and encryption. FHSS products can send signals as quickly as 1.2 to 2 Mbps and as far as 620 miles. Increasing the bandwidth (up to 24 Mbps) can be achieved by installing multiple access points on the network. In FS, the 2.4-GHz band is divided into 75 1-MHz subchannels. To minimize the probability that two senders are going to use the same subchannel simultaneously, frequency hopping provides a different hopping pattern for every data exchange. The sender and receiver agree on a hopping pattern, and data is sent over a sequence of subchannels according to the pattern. FCC regulations require bandwidth up to 1 MHz for every subchannel that forces the FHSS technique to spread the patterns across the entire 2.4-GHz band, which results in more hops and a high amount of overhead. FHSS is considered an economic solution because it provides lower cost ratios, is half the cost of a DSSS system per-node, and can scale above 10 Mbps by adding more access points. Another good point regarding FHSS is its ability to overcome noisy environments, such as metro areas. Because of hopping, it can deal with interference better.
DSSS
SS was rst developed by the military as a secure wireless technology. It modulates (changes) a radio signal pseudo-randomly so it is difcult to decode. This modulation provides some security; however, because the signal can be sent great distances, you do risk interception. To provide complete security, most SS products include encryption. DSSS works by taking a data stream of 0s and 1s and modulating it with a second pattern, the chipping sequence. The sequence is also known as the Barker code, which is an 11-bit sequence (10110111000). The chipping, or spreading, code generates a redundant bit pattern to be transmitted, and the resulting signal appears as wideband noise to the unintended receiver. One of the advantages of using spreading codes is that even if one or more of the bits in the chip are lost during transmission, statistical techniques embedded in the radio can recover the original data without the need for retransmission. The ratio between the data and width of the spreading code is called processing gain. It is 16 times the width of the spreading code and increases the number of possible patterns to 216 (64 k), which reduces the chance of cracking the transmission. The DSSS signaling technique divides the 2.4-GHz band into 14 22-MHz channels, of which 11 adjacent channels overlap partially and the remaining three do not overlap. Data is sent across one of these 22-MHz channels without hopping to other channels, which causes noise on the given channel. To reduce the number of retransmissions and noise, chipping converts each bit of user data into a series of redundant bit patterns called chips. The inherent redundancy of each chip, combined with spreading the signal across the 22MHz channel, provides error checking and correction functionality to recover the data.
50
SS products are often interoperable because many are based on the IEEE 802.11 standard for wireless networks. DSSS is primarily an inter-building technology, and FHSS is primarily an intra-building technology. DSSS products can be fast and far reaching. DSSS is best suited for large coverage areas, ensures higher data rates, requires fewer access points, and the total system cost is lower.
IEEE 802.11bThe Next Step

All previously mentioned, coding techniques for 802.11 provide a speed of 1 to 2 Mbps, which is lower than the widespread IEEE 802.3 standard speed of 10 Mbps. The only technique (with regards to FCC rules) that is capable of providing a higher speed is DSSS, which was selected as a standard physical layer technique that supports 1 to 2 Mbps and two new speeds of 5.5 and 11 Mbps. The original 802.11 DSSS standard species the 11-bit chipping, or Barker sequence, to encode all data sent over the air. Each 11-chip sequence represents a single data bit (1 or 0), and is converted to a waveform, called a symbol, that can be sent over the air. These symbols are transmitted at 1 MSps (1 million symbols per second) by using a sophisticated technique called binary phase-shift keying (BPSK). In the case of 2 Mbps, you use the more sophisticated implementation, QPSK, which doubles the data rate available in BPSK with improved efciency in the use of the radio bandwidth. To increase the data rate in the 802.11b standard, in 1998, Lucent Technologies and Harris Semiconductor proposed to IEEE a standard called Complementary Code Keying (CCK). Rather than the two 11-bit Barker code, CCK uses a set of 64 8-bit unique code words, thus up to 6 bits can be represented by any code word (instead of the 1 bit represented by a Barker symbol). As a set, these code words have unique mathematical properties that allow them to be correctly distinguished from one another by a receiver, even in the presence of substantial noise and multi-path interference (such as interference caused by receiving multiple radio reections within a building). The 5.5-Mbps rate uses CCK to encode 4 bits per carrier, and the 11-Mbps rate encodes 8 bits per carrier. Both speeds use QPSK as the modulation technique and signal at 1.375 MSps. QPSK uses four rotations (0, 90, 180 and 270 degrees) to encode 2 bits of information in the same space as BPSK encodes 1. The trade-off is that you must increase power or decrease range to maintain signal quality. Because the FCC regulates the output power of portable radios to 1 watt Effective Isotropic Radiated Power (EIRP), range is the only remaining factor that can change. Thus, for 802.11 devices, as you move away from the
51
radio, the radio adapts and uses a less complex (and slower) encoding mechanism to send data, resulting in the lower data rates. Table 2-1 identies the differences.
Table 2-1 802.11b Standard Options Data Rate 1 Mbps 2 Mbps 5.5 Mbps 11 Mbps Code and Code Length 11 (Barker sequence) 11 (Barker sequence) 8 (CCK) 8 (CCK) Modulation BPSK QPSK QPSK QPSK Symbol Rate 1 MSps 1 MSps 1.375 MSps 1.375 MSps Bits/Symbol 1 2 4 8
802.11a and 802.11gThe New 5-GHz Band

The 802.11b standard for a coding technique is based on DSSS, a technology developed by the military for secure wireless transmission. Unlike 802.11b, 802.11a was designed to operate in the more recently allocated 5-GHz Unlicensed National Information Infrastructure (UNII) band. Unlike the ISM band, which offers about 83 MHz in the 2.4-GHz spectrum, IEEE 802.11a uses almost four times that of the ISM band because the UNII band offers 300 MHz of relatively interference free spectrum. And unlike 802.11b, the 802.11a standard uses a FDM technique, which is expected to be more efcient in inter-building environments. The FCC allocates 300 MHz of spectrum for UNII in the 5-GHz block, 200 MHz of which is at 5150 MHz to 5350 MHz, with the other 100 MHz at 5725 MHz to 5825 MHz, as shown in Figure 2-4.
Figure 2-4 5-GHz Frequency Band
Independent Clear Channels
5,150 MHz
5,180 5,200 MHz MHz
5,220 5,240 MHz MHz
5,260 5,280 5,300 5,320 MHz MHz MHz MHz
5,350 MHz
There are eight independent clear channels in the lower 200 MHz of the 5-GHz spectrum.
The rst advantage of 802.11a over 802.11b is that the standard operates in the 5.4-GHz spectrum, which gives it the performance advantage of the higher frequencies. But frequency, radiated power, and distance together are in an inverse relationship, so moving up the 5-GHz spectrum from 2.4 GHz results in shorter distances and requirements for
52
more power. That is why the 802.11a standard increases the EIRP to the maximum of 50 mW. The 5.4-GHz spectrum is split into three working domains and every domain has restrictions for maximum power. The second advantage relies on the coding technique used by 802.11a.2 802.11a uses an encoding scheme called coded orthogonal FDM (COFDM or OFDM). Each subchannel in the COFDM implementation is about 300-kHz wide. COFDM works by breaking one highspeed data carrier into several lower-speed subcarriers, which are then transmitted in parallel. Each high-speed carrier is 20-MHz wide and is broken up into 52 subchannels, each approximately 300-kHz wide (see Figure 2-5).
Figure 2-5 Orthogonal Frequency Division Multiplexing (OFDM)
Subchannels
52 Carriers per Channel
20-MHz Single Channel Detail Each channel is subdivided into 52 subchannels, each about 300-KHz wide.
COFDM uses 48 of these subchannels for data, while the remaining four are used for error correction. COFDM delivers higher data rates and a high degree of signal recovery, thanks to its encoding scheme and error correction. Each subchannel in the COFDM implementation is about 300-kHz wide. To encode 125 kbps, the well-known BPSK is used, which yields a 6000-kbps data rate. Using QPSK, it is possible to encode up to 250 kbps per channel, which combined achieves a 12-Mbps data rate. By using 16-level QAM encoding 4 bits per hertz, and achieving data rates of 24 Mbps, the standard denes basic speeds of 6.12 and 24 Mbps that every 802.11a-compliant product must support. Data rates of 54 Mbps are achieved by using 64 QAM, which yields 8 to 10 bits per cycle, and a total of up to 1.125 Mbps per 300-kHz channel. With 48 channels, this results in a 54-Mbps data rate; however, the maximum theoretical data rate of COFDM is considered to be 108 Mbps. 802.11a is not backward compatible with 802.11b. As a result, the 802.11a deployment in an already deployed 802.11b environment can be complicated. One possible solution here is the Cisco 1200 product, which supports both standards. 802.11g is an extension of 802.11b, and will broaden 802.11bs data rates to 54 Mbps by using the same OFDM technology as 802.11a within the 2.4-GHz band. Because of backward compatibility, an 802.11b radio card interfaces directly with an 802.11g access point (and vice versa) at 11 Mbps or lower depending on the range. Similar to 802.11b,
NOTE
Modulation and Line-Coding Techniques in Hybrid Networks
53
802.11g operates in the 2.4-GHz band, and the transmitted signal uses approximately 30 MHz, which is one third of the band. This limits the number of non-overlapping 802.11g access points to three, which is the same as 802.11b. This means that the same difculties exist with the 802.11g channel assignment as with the 802.11b when covering a large area with a high density of users. Another big issue here is the considerable RF interference from other 2.4-GHz devices. The 802.11g standard is still under development and the release of 802.11g radio cards and access points can be expected by late 2002 or early 2003.
NOTE
The newly accepted IEEE 802.11e adds multimedia, quality of service (QoS), and enhanced security to the current IEEE 802.11 wireless standard. IEEE 802.11e is a Media Access Control (MAC) level enhancement that works with both 802.11b (2.4 GHz) and 802.11a (5 GHz) physical layers, and with the upcoming IEEE 802.11g physical layer specication. Signicant elements of ShareWaves patented Whitecamp network protocol have been incorporated into the IEEE 802.11e specication. Recently, ShareWave announced, The Bodega Wireless LAN Platform Features Whitecap2 Technology, which Adds Wi-Fi (802.11b) Compliance to Multimedia and QoS Capabilities.
Modulation and Line-Coding Techniques in Hybrid Networks

To prevent confusion, hybrid terminology refers to a combination of wired and wireless technologies. These technologies are available in todays market and offer some unique features. The wireless modem works as an integrated part of the Cisco uBR7200 Series Universal Broadband routers, primarily designed for the cable core router product line. The new product is a hardware adapter and it can be plugged to the existing platform. It creates a combined solution of cable and wireless technology, which creates a hybrid networking solution. Their variety and combinations can vary signicantly from solution to solution, but here is another example of a hybrid solution, based on signaling and protocols, as initially designed for other technologies. It is called Ciscos Firestorm Multichannel Multipoint Distribution System (MMDS. This is a Broadband Fixed Wireless (BBFW) point-tomultiPoint (P2MP) headend (HE) and customer premises equipment (CPE) solution that is suited primarily for residential environments, which is designed to provide licensed broadband wireless access to a market not served by ber or copper, which also will provide geographic coverage not possible with competitive unlicensed BBFW systems. For the HE, Cisco offers a wireless line card (uBR-MCW-MDA) which ts in a 7223 or 7246 uBR or VXR router, and a MMDS transverter (SX11127A) with duplexor. The CPE gear includes either a 951 router for data only or a 952 router for voice enhanced residential use. This BBFW P2MP solution operates at Layer 3, has non line of site (NLOS) capabilities (through the RF component), and can provide voice and differentiated services. Extraordinary co-channel resolution and multi-path signal mitigation is based on signaling
54
protocols QAM 64 downstream with OFDM modulation and 16 QAM upstream modulation schemes, plus optional spatial antenna diversity for NLOS at both the HE or CPE. Also, a co-channel resolution capability is offered with Data-over-Cable Service Interface Specications (DOCSIS) for subscriber management. Another solution involves using the licensed and license-free U-UNI spectrums with a xed wireless solution and terrestrial OC-3 backbone. This alliance was announced by WiFi Metro, Inc. in April 2002. WiFi is a wireless ISP (WISP) that owns a network of over 50 wireless hotspot locations and Gatespeed Broadband, Inc. The wireless HotZone of WiFi Metro, which provides high-speed Internet access to subscribers within a fteen-mile radius of a centralized Wireless Internet Point of Presence (WIPOP), is combined with the xed wireless solution of GateSpeed. The 2.4-GHz licensed spectrum runs the IEEE 802.11 protocol. The 5.2-GHz license-free spectrum is used for U-NII, and these two spectrum bands support nationwide deployment. This solution is fully compatible with existing Cisco Aironet 350 series and Cisco 1200 Series products. Satellite communications can use another approach to provide Internet access, such as the DOCSIS 1.1 standard. It is well known that the primary focus of the DOCSIS standard is cable modem service, but the standard can be used for satellite with a specially designed DOSCIS terminal for emerging Ku-band satellite systems. Another example here is Sprint, who is using hybrid networks that are based on a proprietary cable modem network in the Bay Area. It is basically a cable modem system, which has been frequency shifted to operate over wireless; it has all the same bandwidth sharing issues as cable modems. The list of examples is much wider and includes Frame Relay over wireless, L2TP, Multiprotocol Label Switching (MPLS), GRE-based Virtual Private Network (VPN) in xed wireless networks, Point-to-Point Protocol over Ethernet (PPPoE), and L2TP to MPLS conversions for xed wireless networks. The bottom line is that market conditions in the U.S. have proved that these types of hybrid solutions can be successful, based on the fact that they combine existing with emerging or evolving technologies and require less of an investment, which provides new solutions and covers more user-based demand areas.
Clocking, Line Coding, and Framing in Carrier Systems

In digital transmissions, three major elements need to be considered:
Clocking Line coding (signaling) Framing
They are the differentiators between analog and digital transmission.
55
Clocking
Analog interfaces do not require that specic timing be congured. However, digital T1 interfaces require that not only the timing be set, but also that the origination of the timing source be considered. Line and internal timing (clocking) are the available options to address this requirement. Clocking refers to both timing and synchronization of the T1 and it is an essential part of the proper functioning. The timing is encoded in the frames and provides synchronization for the circuit and for every synchronous transmission. It is preferred to derive the clocking from the service provider, where the local exchange carrier (LEC) clocking serves as the master and the router clocking serves as a slave. When more than one provider is involved in delivering the T1, clock slips can occur. In this case, it is important to have a master clock to provide reliable time-division multiplexing (TDM) synchronization and alignment.
Pseudo-Ternary and Two Binary One Quaternary Signaling

ISDN and Frame Relay use a coding scheme called pseudo-ternary signaling, which is associated with the S/T interface. The two binary one quaternary (2B1Q) coding scheme, which in turn is associated with the U-interface, is specic for U.S. ISDN, ISDN DSL (IDSL), high-data-rate DSL (HDSL), and single-line DSL (SDSL) local-loop specications.
Pseudo-Ternary Line Coding and the S/T Interface

ISDN and the rst layer of Frame Relay use a coding scheme called pseudo-ternary signaling, which is used by the S/T interface. This technique provides DC balance and nonvoltage drifting procedures for signaling by using positive and negative 0s. In pseudosignaling, 0 is represented as a line signal of approximately 750 millivolts that alternates between positive and negative polarity, and the 1 represents the absence of voltage. As you can see from Figure 2-6, synchronization is important because there must be a way to recognize the two consecutive 1s from 0s, where two or more consecutive 0s change the polarity. The synchronization is based on the bipolar violation (BPV), which is two consecutive 0s. In pseudo-ternary signaling, the binary values show a 0 as negative or positive, and 1 as the absence of signal.
Figure 2-6 Pseudo-Ternary Signaling
0 Time
56
The frame structure is organized into blocks of bits. Figure 2-7 shows the short physical layer frame format. From the CPE terminal equipment (TE), the outgoing frames have 2 bits offset from incoming frames. The network timing drives the process. The TE cannot activate the line (activation bit A), as only the NT conrms the activation. Figure 2-7 shows a signicant difference between incoming and outgoing frame formats. Each frame contains 16 bits from every B channel and 4 bits from the D channel.
Figure 2-7 Short and Detailed Frame Formats
Short Frame Format Channel Number of Bits B1 D B2 D B1 D B2 D 8 1 8 1 8 1 8 1
Detailed Frame Format

NT-to-TE Incoming Frames
FLB1B1B1B1B1B1B1B1EDAFaNB2B2B2B2B2B2B2B2EDMB1B1B1B1B1B1B1B1EDSB2B2B2B2B2B2B2B2EDL
OfOf FLB1B1B1B1B1B1B1B1LDLFa LB 2B2B2B2B2B2B2B2L DLB 1B1B1B1B1B1B1B1LDLB 2B2B2B2B2B2B2B2LDL
TE-to-NT Outgoing Frames 48 Bits in 250 Microseconds
The full description of the bits and rules follows:
OfOffset. FFraming bit. Always positive 0 and is based on the BPV, which is used for timing. LDC balancing bit. Independent DC balanced; can be +0,-0, or 1. DD channel bit. +0, -0, or 1 in the rst format; 1,-0 in the second. EEcho D channel bit. Can be +0, -0, or 1; exists only in the rst format. FaAuxiliary framing bit. Only in the rst format. AActivation bit. Can be +0, -0, or 1; only in the rst format. NComplement to Fa. Can be +0, -0, or 1; only in the rst format. B1, B2Data bit within B1 and B2 channels respectively; can be +0, -0, or 1. SReserved. MMultiframing bit. Can be +0, -0, or 1; only in the rst format. I.430 species multiframe, which is a group of 20 I.430 frames. M-bit and Fa are used in the multiframing procedures. The M-bit is set to 1 in the rst 20 frames, which are 48 bits each, and set to 0 in every other frame. The I.430 also species that the rst 0-bit transmitted F and L bits are another BPV.
57
For every 250 ms, 48 bits are transmitted through the channel, yielding a total of 4000 frames per second. 4000 frames 48 bits each results in a total rate of 192 kb. For every 16 B-bits, the channel transmits 4 D-bits. Therefore in a Basic Rate Interface (BRI), if every B channel is 64 kbps, the D channel is 16 kbps. A BRI is also known as 2B+D. This signaling is not contention-free, so a simple contention-resolution mechanism was designed to prevent contentions. It is based on the following trafc considerations:
B channel trafcNo additional functionality is necessary to control access to the two B channels because each channel is dedicated to a given TE at any particular time. Incoming D channel trafcThe D channel is available for use on all member TEs. The Link Access Procedure on the D channel (LAPD) addressing scheme (described later) is sufcient to resolve any unit and its destination, based on the fact that each LAPD frame includes an explicit address of every destination TE. All TEs can read this address and determine whether the frame was sent to them. Outgoing D channel trafcAccess must be regulated, so that only one device transmits frames at a time. When the TE is ready to transmit an LAPD frame, it listens to the stream of incoming D channel echo bits. If it detects a string of 1s of equal length to a threshold value Xi, where i = priority class for this LAPD frame, it can transmit. Otherwise, it waits because another TE is transmitting. If several TEs transmit 0 at the same time, all are using the same polarity. Sending 1 means no signal. The TEs are attached to the bus in parallel. Based on Ohms law, the total voltages are not a sum of all voltages. Therefore, 1 is detected if all TEs apply 1 (no voltage) and 0 is detected if one or more TEs apply a voltage. This process uses the logical AND function. A NT-to-TE frame carries an E-bit, which is an echoed D-bit in the opposite direction. The E-bit performs an important contention mechanism, especially in the p2mp designs. The mechanism ensures that only one TE is transmitting frames in the TE-toNT direction. If more than one TE tries to transmit, a collision can result. To avoid a collision, a transmitting TE monitors the echo bit with the transmitted bit. If the E-bit is different from the last transmitted D-bit by this TE, the TE knows that it does not control the D channel and ceases the transmission. This procedure is called perfect scheduling.
The following is how the contention resolutions works:
Two Binary One Quaternary Coding, the Frame Format, and the U-Interface
ANSI standard T1.601 is used in the U.S. to provide the necessary specications for the Ureference point because the International Telecommunication Union Telecommunication Standardization Sector (ITU-T) does not dene the local loop specications between NT and the LE across U-reference points, or the otherwise called U-interface. The interface and
58
line coding is specic for U.S. ISDN, IDSL, HDSL and SDSL local loop specications. The physical connection over twisted pair provides distances up to 5.5 km (18,000 ft). The U-interface supports serial, synchronous, full-duplex, and point-to-point designs. The signaling technique associated with the U-interface is called two binary one quaternary (2B1Q), as shown in Figure 2-8.
Figure 2-8 Two Binary One Quaternary (2B1Q) Signaling
Binary Values Quats 2.5 V
00 -3
10 +3
11 +1
01 -1
01 -1
11 +1
0.833V - 0.833V
Time
-2.5 V
2B1Q is a four-level, single-symbol code. Every combination of two bits (rst two columns), where the rst bit represents the polarity and the second one the magnitude, has a voltage representation and Q symbol representation called a quat. The frame format in the U-access point (often called the U-interface) is different, as shown in Figure 2-9.
Figure 2-9 2B1Q Frame Format
Synchronization Word 9 Quats, 18 Bits 12 Groups of (2B+D) Each 108 Quats, 216 Bits Overhead (M Channel) 3 Quats, 6 Bits
The Synchronization Word (SW) is a self-explanatory term, which is used for physical layer synchronization and frame alignment. B and D channel information is formed into 12 groups that contain data and control information as follows: B1 (8 bits), B2 (8 bits), and D (2 bits). Therefore, 18 (8 + 8 + 2) multiplied by 12 yields 216 bits, representing 108 quats. The overhead eld is used for channel maintenance, limited bit error detection, and power status indication. Using two different interfaces, S/T and U, requires signal transformation that is performed by the device known as the network termination type 1 or NT1. The timing for the NT1 in a U-interface (reference point) is still provided by the LE.
59
Unlike a S/T reference point, the U-access point operates at 160 kbps and sends 666.666 frames per second, or one frame every 1.5 ms. Every eight groups of frames is a SF. To indicate the beginning of the SF, the technique uses an inverted SW. The 6 overhead bits of all frames represent a 48-bit (8 frames 6 bits) block, called a M-channel. This block is capable of increased error-detection, signaling maintenance, and power error detection.
T1 Digital Coding and Framing

Analog interfaces do not require a specic line-coding conguration. Digital interfaces do require that the alternate mark inversion (AMI), bipolar 8-zero substitution (B8ZS), B3ZS, B6ZS, or high density binary 3 (HDB3) be congured. These values must match the values of the private branch exchange (PBX) or central ofce (CO) that connects to the Digital T1/ T3 Packet Voice Trunk Module. A large variety of coding schemes can be used that are based on well-established research and standards. The following are a few of these coding schemes:
Unipolar non-return to zero (NRZ) Unipolar return to zero Polar NRZ Polar NRZ inverted (NRZI) Bipolar return to zero B3ZS B6ZS Manchester code
Some of these are included in Figure 2-10. Choosing one or another scheme is always based on design considerations, such as the following:
Does the line code provide good synchronization? Does the line code allow a DC buildup in transmission? Does the line code provide any error detection capability?
60
Figure 2-10 Line-Coding Schemes

0 +V Unippolar Non-Return-to-Zero 0 1 0 0 0 0 0 0 0 0 1 1 0 1
Unippolar Return-to-Zero
+V 0
+V
Bipolar Return-to-Zero
0 -V
+V
Bipolar Non-Return-to-Zero
0 -V
+V
AMI
-V +V
B8ZS
0
B V
-V +V
HDB3
0
B
V
-V
61
Alternate Mark Inversion

Cisco routers support the following coding schemes:
7200-router(config-controller)#linecode ? ami AMI encoding b8zs B8ZS encoding
One of the most widespread coding techniques for T1 carriers is alternate mark inversion (AMI). By using AMI, pulses correspond to binary 1s and 0s and alternate at 3V (+3/-3V). The presence of a signal is 1, and the absence of a signal is 0. A benet of this encoding is a built-in method of error detection. When consecutive pulses are detected to have the same polarity, the condition is considered to be a BPV. As a result, the carrier and the CPE indicate that the frame is experiencing some type of error. A problem with this coding scheme is the way that 0 is interpreted as a no-signal condition. Therefore, an absence of pulses (all 0s) can force repeaters and network equipment to lose frame synchronization. To prevent this, all T1s are required to meet the 1s density requirement, which states that no more than 15 consecutive 0s can be transmitted to the line. (In the old days, the FCC actually said you could have 15 0s in a row. Now, the FCC says that you can have up to about 40 0s without harming the network. For all practical purposes, 7 consecutive 0s is the maximum today. See Newtons Telecom Dictionary: The Authoritative Resource for Telecommunications, Networking, the Internet, and Information Technology (18th Edition), Harry Newton and Ray Horak.) One solution to this requirement is alternate space inversion (ASI), which reverts the pulses. 1 becomes a no-signal state and the data is inverted for high-level data link control (HDLC) framed packets. However, this isnt commonly used. More often, you nd CPE equipment congured to only use 7 of the 8 bits of each T1 timeslot. This effectively brings your data rate down from 64 k to 56 k per channel.
Zero-Suppression Schemes
The most widespread remedies for the density requirements of T1s are zero-suppression codes. They use certain rules, where if a predened pattern is detected, the network equipment corrects it by inserting another pattern in the data stream to maintain ones density.
B8ZS and T1
B8ZS is one of the most widespread zero-suppression coding techniques. It is implemented to prevent degradation because of long strings of 0s. B8ZS replaces a block of eight consecutive 0s with a code that contains BPVs in the fourth and seventh bits. When eight 0s appear, they are replaced with the B8ZS code before being multiplexed onto the T1 line. At the receiver, detection of the BPV is replaced with eight 0s, which allows the full 64 kbps of the DS0 to be used. This is the most common technique; all major U.S. carriers support it.
62
B3ZS and B6ZS for T3

Other well-known zero suppressing schemes are B3ZS and B6ZS line codes. These coding schemes are typical for T3 (digital service 3 [DS3]) circuits. In B3ZS, each pattern of 000 is replaced by 00V or B0V. The choice depends on whether the number of bipolar pulses between violations (V) is an odd number. In this case, V is positive or negative and chosen to cause a BPV, and B is also positive or negative, and is chosen to meet the bipolar conditions. In B6ZS, each pattern of 000000 is replaced by 0VB0VB. Again, the choice depends on whether the number of bipolar pulses between Vs is an odd number. Here, as in the previous case, V is positive or negative, and is chosen to cause a BPV; and B is positive or negative, and is chosen to meet the bipolar conditions.
T1 and T3 Framing
Analog interfaces do not require that specic framing be congured. Digital T1 interfaces do require that either SF (also called SF or D4 framing) or Extended SF (ESF) be congured. These values must match the values of the PBX or CO that connects to the Digital T1 Packet Voice Trunk Module. Cisco routers support the following frame formats for T1 connections:
7200-router(config-controller)#framing ? esf Extended Superframe sf Superframe
T1 SF Signal Format
The recent D3/Mode 3 D4 format for framing and channelization is, by far, the most popular format. The bit stream is organized into SFs, each consisting of 12 frames. Every frame consists of channel information, where every channel is 8 bits plus framing bits. Framing bits are marked differently. Terminal framing bits (BFt) mark odd frames that produce a sequence of alternating 1s and 0s. Even-numbered signaling frame bits (BFs) produce groups of three 1s, followed by three 0s, repeating. The framing bits, which are every 193rd bit and the last bit in each frame, are inserted between the 24th and 1st channel word. Each channel word consists of 8 bits (B1 through B8) every 0.65 nsec. Channel words represent 8-bit samples, taken at the rate of 8000 samples per second, and correspond to 24 different sources of voice or data information. Signaling information is information that is exchanged between components of a telecommunication system to establish, monitor, or release connections. For voice transmissions, signaling information must be transmitted with the channel voice samples. This is accomplished by sharing the last signicant bit (B8) between voice and signaling. This process is called robbed bit signaling (RBS). The B8 bit carries voice information for ve frames, followed by one frame of signaling information. This pattern of B8 assignment to
63
voice and signaling is repeated during each successful group of six frames. Using this technique, 24 channels (8000 samples/channel/second) (8 bits per frame) + 8000 BFs/ second, yields a total speed of 1.544 Mbps.
T1 ESF Signal Formats

The SF of ESF is extended from 12 to 24 frames with 24 framing bits. Of the 24 framing bits in an ESF, six bits are used for synchronization, six bits for error checking, and the remaining 12 bits are used for a 4-kbps facility data link (FDL), which is a communication link between CSUs and the telephone companys monitoring devices. The framing bits are used for different purposes than in SF. The ESF takes advantage of new more-reliable conduits (just an analogy with X.25 and Frame Relay standards), where not every bit needs to be used for framing and synchronization. To permit error detection, the sending CSU examines all the 4608 data bits within ESF and generates a cyclic redundancy check (CRC). The receiver calculates its own CRC and compares both. If there is a match, there are no errors. CRC is known to report approximately 98 percent of all possible bit errors. This information is stored in counters and considered when there is a trend in speed degradation. This process results in increased availability and uptime for T1s. Some reports show that the expected availability of T1s for most phone companies is greater than 95 percent.
NOTE
The troubleshooting of T1s is covered in Part II, Dial.
M23 Frame Format

The digital signal level 3 (DS-3) (T3) interface operates at 44.736 Mbps over coax cable, which is compliant with Asynchronous Transfer Mode (ATM) Forum UNI specications. Three standards for DS-3 framing exist: M23, C-bit parity, and SYNTRAN. The M23 multiplex scheme provides for the transmission of seven DS-2 channels. A T3 is 28 T1s, and the rst layer multiplexor (M12) serves four T1s. The seven second-layer multiplexors are connected to the end multiplexor (M23). Because each DS-2 channel can contain four DS-1 signals, a total of 28 DS-1 signals (670 DS-0 signals) are transported in a DS-3 facility. The current DS-3 signal format is a result of a multi-step, partially synchronous, partially asynchronous multiplexing sequence. Cisco routers support the following frame formats:
7200-router(config)#contr t3 2/0 7200-router(config-controller)#framing ? auto-detect Application Identification Channel Signal c-bit C-Bit Parity Framing m23 M23 Framing Format
The DS-3 signal is partitioned into M-frames of 4760 bits each. The M-frames are divided into seven M-subframes, each containing 680 bits. Each subframe is further divided into
64
eight blocks of 85 bits each, with the rst bit used for control and the rest for payload. 56 frame overhead bits handle functions such as M-frame alignment, M-subframe alignment, performance monitoring, alarms, and source application channels.
PRI1.544-Mbps Interface
The ITU-T recommendation I.431 denes the physical layer protocol of PRI for both 1.544 and 2.048 Mbps. The electrical characteristics are dened in G.703 and G.704. The primary use of PRIs are as the trunk and trunk groups, and not as the TEs. Usually, LECs have separate service groups for BRIs and PRIs, which is based on the nature of their usage (see Figure 2-11).
Figure 2-11 ITU-T I.431 Recommendation Primary Rate Interface (PRI) 1.544 Mpbs Interface
23B Channels N1,N2,N3,N4... N23 23Bx64 kpbs
D Channel-N24 1Dx64 kbps
Primary Rate Interface (PRI) 2.048 Mbps Interface

15B Channels N1,N2,N3,N4... N15 D Channel-N16 15B Channels N17,N2,N3,N4... N31 30Bx64 kpbs 1Dx64 kbps
The PRI, unlike a BRI does not support p2mp congurations, but only point-to-point. In terms of ISDN, usually it is dened at the T reference point, where a digital PBX or LAN connection device controls multiple ISDN TEs, and provides multiplexing for them. The PRI is based on the DS1 transmission structure and T1 services. The PRI multiplexes 24 channels, 64 kbps each. When it is congured as 23 B+D channels, the D channel is used for signaling, and when it is congured as 24 B channels, another D channel is available to do the signaling.
65
NOTE
Out-of-band signaling uses frequencies outside of the normal frequency band for signaling; this is the core of the Signaling System 7 (SS7). In contrast, in-band signaling relies on using certain bits out of the frame format in the frequency band, and can be referred to as bit robbing signaling.
When the PRI is congured for 24 B channels, the PRI frame contains one framing bit plus a single 8-bit pulse code modulation (PCM) sample from each of the 24 channels. These 193 bits, multiplied by 8000 frames per second, yield a total bit rate of 1.544 Mbps. The 24 frames are grouped together to form a multiframe, as described in the ESF frame format. One multiframe is 24 bits and performs the following functions:
Frame alignment sequence (FAS)FAS ensures the synchronization of frames and is represented by a repeated pattern of 001011.... In case of losing proper synchronization, the receiver needs to listen to ve consecutive SFs and nd the correct sequence to synchronize. Flow Sequence Control (FSC)FSC ensures that no bit errors occurred in the previous multiframe. The sequence detects and reports, but does not correct the errors. Maintenance channel (M)The use of M remains to be determined; it is not currently used in PRIs.
In I.431, one bit of every octet is required to meet the density requirement, resulting in a 56-kbps channel rate. To overcome this drawback, B8ZS is used and all 0 octets are replaced by a combination of 000110011, where the BPV occurs in the fourth and seventh bits. If the last 1 was a positive 1, the replacement looks like 000pn0np, where n and p represent negative and positive polarity. If the previous appearance of 1 was negative, the combination is 000np0pn, and n and p are negative and positive polarities. The new pattern is injected in a way that all V and B are paired, so that the new code is DC-balanced.
NOTE
The troubleshooting of PRIs can be seen in Part II.
PRI2.048-Mbps Interface
Similar to the 1.544-Mbps PRI used in the U.S. and based on the T1 carrier, the 2.048-Mbps PRI is typical for Europe and is based on Computer Emergency Response Team (CERT) 1, or the E1 carrier. E1, in the conguration of 30B+D, is the most common remote access solution for ISDN access services. Thirty B-channels and congurations such as 30B+D are more likely to be used for home remote access solutions. The numeration of the channels differs from the previous design (see Figure 2-11). Channels 1 to 15 are B channels, followed by a D channel (number 16), and another set of 15 B channels. Every frame
66
contains 31 slots, and every slot is a single 8-bit sample. The duration of the frame is still 125 seconds, but 256 bits. So, 8000 frames per second with 256 bits each, plus framing bits, yield 2.048 Mbps with 1.9984 Mbps for the user data rate. Unlike AMI in the previous design, the zero-suppression scheme is called HDB3. HDB3 replaces a string of four consecutive 0s with a pattern of x00V, where V is the violation bit, and x is the bit which can be 1 or 0, depending on the requirement to keep the code DC-balanced. The line-coding and framing techniques described previously include the most common and established ones, but not all of them. The main objective is to provide you with background and details to prepare for the next chapter.
End Notes
1 Plamen Nedeltchev. Wireless LAN Ready for Prime Time. Cisco Packet Magazine. Q3, 2001.
2 Network
Computing. 80211a: Making Space for Speed. J. Conover. January 2001.
Summary
In this chapter, you learned about clocking, line coding, and framing in the carriers system, which is an integral part of your knowledge as a troubleshooting engineer. The wired solutions, wireless solutions, and hybrid solutions are well represented in todays enterprise environments. The importance of this chapter is to give you more information about the variety of existing standards in the industry, to help you to recognize the different techniques and solutions, and to assist you in designing, conguring, and troubleshooting your environment.
Review Questions
1 What does Shannons Law state? 2 What does the Nyquist sampling theorem state? 3 What does DMT stand for? How many subchannels does the standard (ANSI) ADSL
dene?
4 Why is CAP modulation sometimes called suppressed QAM? 5 What is the typical speed in the 802.11b standard? What coding techniques provide
these speeds?
Review Questions
67
6 How wide is the high carrier in 802.11a; how many subchannels does it have, and how
wide is each subchannel?

7 How does the 802.11g standard relate to 802.11a and 802.11b? 8 What is the relation between the terms clocking, timing, and synchronization? 9 What interface uses the pseudo-ternary coding technique? What is the size of the
frame?
10 What does 2B1Q stand for and which interface does it use? What is the size of the
frame?
11 What is perfect scheduling in the physical layer? 12 How do T1 circuits meet the ones density requirements? 13 Explain how the 24 framing bits in ESF are broken down and how they are used.
CHAPTER
The Cloud
In telecommunications, a public or semi-public space on transmission lines (such as T1 or T3) that exists between the endpoints of a transmission is referred to as the cloud or the network cloud. Data that is transmitted across a wide-area network (WAN) enters the network from one endpoint by using a standard protocol suite. The data then enters the network cloud where it shares space with other data transmissions. Within the cloud, the data can be encapsulated, translated, and transported in different ways, but it emerges in the same format as it entered the cloud. A network cloud represents a packet-switched network (PSN), where no two packets necessarily follow the same physical path. Another understanding of this term as a troubleshooting engineer is that you have no visibility of the internal structure and procedures over the cloud, which traditionally belongs and is managed by a carrier or a local service provider. The term carrier is a legacy term that comes from voice technology, where channels are carried over multiplexed systems and dont appear in their natural band of 0.3-3.4 kHz until the signal reaches the receiver. Today, the term carrier includes not only legacy, but additional services, which are explained in more detail in the following pages. Having learned about telecommunication basics, this chapter provides you with fundamental knowledge for when you are dealing with service providers. The focus of this chapter covers the following topics:
Carriers, service providers, and how the trafc is carried T-carriers, E-carriers, Signaling System 7 (SS7), and Synchronous Optical Network (SONET) Carriers facilities and switching system Internet service providers (ISPs) and application service providers (ASPs) Future features to be expected from service providers
Carriers, Service Providers, and How Trafc Is Carried

In telecommunications, transferring information from one point to another is based on transferring signals that by nature can be continuous and discrete, or analog and digital. The typical Public Switched Telephone Network (PSTN) of the early 1960s is primarily an
70
Chapter 3: The Cloud
analog network. Discrete or digital signal terminology is based on the base 2 numerical system (1 and 0), where a digital signal has at least two recognizable states that can be interpreted as 1 and 0. Carriers build networks that differ from each other based on the way that the carrier switches the trafc and reroutes it to the requested destination. The carriers switching systems can be classied as follows:
Circuit switchingThe physical resources of the time, space, and frequency spectrum are dedicated to a single call for the duration of the call. The network handles the resources based on physical availability, thus restricting and blocking the call requests that exceed the physical limitations of the network. Message switchingEach switch can store and delay incoming messages, and rather than block the requests, the switch uses the available bandwidth by using rate adoption algorithms, multiplexing, or both. Packet switching is a special case of message switching, where messages are formalized and length-restricted by using maximum transmission or receive unit (MTU, MRU) conventions, or by using standards-based message exchanges to minimize the content-based calculations. Packet switchingPacket switching is slightly different from message switching. Message switching passes messages from the sender to the receiver through intermediate nodes. Packet switching relies on a large number of trunks attached to the switches and thus balances the trafc load around busy trunks and lines. Cell switchingCell switching is primarily based on Asynchronous Transfer Mode (ATM), where a standard, xed-length 53-byte packet that is called a cell can deliver data, voice, and video in a uniform fashion. Traditional switching methods are dened by the two dimensions of the physical conduit and the subchannel (subinterface). Cell switching uses additional dimensions that dene the physical conduit, virtual path, and virtual channel, where the intermediate dimension of the virtual path is composed of all the virtual channels that are pointing in the same direction.
Cell switching terminology can be a bit confusing because the term asynchronous is part of the name. In asynchronous data communications, the synchronization is not necessary because the synchronization is part of the frame format. Each character (5 or 8 bits long) requires a start and a stop bit and, in some cases, the stop bit can be 1.5 times longer than the start bit. Considered a reliable form of communication, the asynchronous transfer creates high overhead and thus restricts high bandwidth rates. In the case of synchronous data communications, precise synchronization is mandatory.
NOTE
Have you ever heard a technician from the central ofce (CO) say, The line cannot sync? This is the most common reason that the rst layer does not come up and/or the clocking is not available.
FDM
71
Synchronous data transmission offers high-speed rates because instead of start and stop procedures, both customer premises equipment (CPE) and local exchange carrier (LEC) equipment must synchronize their exchange, which is based on special frames or bits that indicate the beginning and end of transmitted user data. ATM is called asynchronous because of the sporadic presence of user data. If user data needs to be sent, it is transformed into cells and sent over the line. If there is no user data, only keepalive cell types are sent and received. The choices that need to be made in analog versus digital communications are related to analog or digital signaling. Historically, the analog versus digital arguments seemed to be a waste of time, because digital technologies are vigorously gaining new market shares. The new technologies of cable, WAN satellite, and wireless LANs (WLANs) are reinventing some of the advantages of analog transmission. The advantages of digital transmission over analog includes better quality of service (QoS), simplied maintenance, synergy with digital switching, powerful digital signal processing, simplied multiplexing, and it is well matched to ber-optic and device technology. The disadvantages of digital transmission include the need for larger bandwidth, accurate network synchronization, and a costly interface with existing analog networks. Carrier systems can be split into analog carrier systems and digital carrier systems. Analog carrier systems use active or passive repeaters to recreate the signal, so any losses or attenuations are corrected while the signal is propagated along the line. Analog systems carry voice, data, and video information, and they exchange supervisory and maintenance information between each other. These carriers are best suited for voice signals; they operate over multi-pair cables, N-carriers, coaxial cables, and L carriers. There are a growing number of radio-channel carriers whose market share is increasing faster than the classic analog carriers. Digital carrier systems are based primarily on the regeneration of signals. Besides regenerators, these systems use multiplexing and demultiplexing techniques to use broadband signals over a single circuit. The two most signicant methods are frequencydivision multiplexing (FDM) and time-division multiplexing (TDM).
FDM
FDM is a technique where all signals are transmitted simultaneously, but over different frequency bands. FDM obeys the rule some bandwidth all of the time, where the broadband is divided into a number of narrowbands, and every subband is called a channel. Special requirements must be met to prevent interference between the subbands (channels) and to reduce the number of erroneous transmissions. Typical implementations of FDM
72
include voice, AM and FM bands, cable TV, and TV tuners. The bandwidth of a FM channel obeys Carsons rule, which is explained through the following equation: BW(FM) = 2(f + fm) If the frequencies are separated from each other and dont overlap or interfere, a number of signals can be carried simultaneously. Separation is achieved through a guard band, which uses the unused portion of the spectrum. In voice channels that require a 0.3 to 3.4-kHz channel, the band is 4-kHz wide, where 3.1 kHz are used for the voice channel and 900 Hz are available for the guard channel. To divide the band, one pair of a multiplexor/ demultiplexor is installed on both ends of the transmission facility. For North America, a standard voice multiplexing scheme is twelve 4-kHz voice channels from 60 to 108 kHz (f1, f2, f3, ... f12). Figure 3-1 shows how the input is transformed from serial to parallel and how the encoding is sent to 12 modulators. The lower part of the gure shows how the bandwidth is used.
Figure 3-1 Frequency-Division Multiplexing (FDM)
Input Data Serial to Parallel Encoder Modulator
+
Modulator
To Line
f1
fn
FDM works best with analog signals. In the U.S., common terminology includes the following terms: A group with 12 analog voice channels is called a N-carrier. A supergroup is composed of ve groups with 12 channels each, totaling 60 channels. Ten supergroups are combined to produce a mastergroup of 600 voice channels, and a jumbogroup is comprised of six mastergroups with 3600 voice channels. The grouping usually is available over coaxial cables and it forms a family that is referred to as the E-carrier.
Digitalization of the Signal and Pulse Code Modulation

In general, the process of digitizing the signal creates an adequate digital model for a nondigital process. The challenge is trying to represent a real-life scenario as an algorithm. In some cases, the task appears to be much easier because of the existence of repeated samples. Human voice transfer requires a 4-kHz frequency band. Based on the Nyquist sampling theorem, digital sampling must take place at least twice the highest frequency to reconstruct
TDM
73
the analog signal accurately. As a result, the sampling theorem requires that, given that fa equals a 4-kHz frequency band, fs is greater or equal to 4000 2 = 8000 Hz. Digitalization of voice as an analog signal includes several steps:
Step 1 Sampling of the analog waves. The process of sampling involves
adequately transforming the analog wave in a way that after recreating the signal from the sample, there is an accurate waveform of the signal. Internationally, the sampling requires 8000 times per second, or 8 kHz.
Step 2 Quantization of the analog waves. The waves need to be quantized by
adequately assigning 1s or 0s to the samples. Each input sample is assigned to a quantization interval that is closest to the amplitude height of the analog wave. A standard of 8 bits per sample is accepted as an international standard.
NOTE
The choice of 8 bits per sample, given the fact that even the existing microprocessors use a 32- and 64-bit architecture, seems outdated.
Step 3 Coding of the bits. The bits must be coded in forms or frames to be
transmitted over the links. All standards must support at least 64 kbps because 8000 samples 8 bits / sample = 64 kbps. A unit called a channel bank can perform sampling, quantization, and coding. A coder-decoder (codec) device performs the rst two functions of pulse code modulation (PCM), and the coding is performed by a data service unit/channel service unit (DSU/ CSU). The process is effective and is much less vulnerable to noise, but it is more expensive. The digitalized voice is called PCM voice.
TDM
Unlike FDM, TDM is based on the time-division of the channel, which performs timesharing rather than frequency-sharing, and obeys the rule all the bandwidth, some of the time. This concept is shown in Figure 3-2, where a digital signal level 1 (DS-1) is subdivided into 24 channels.
74
Figure 3-2
Time-Division Multiplexing (TDM) Technology Where 24 DS0 (64 kbps) Channels Are Time-Sharing a 1.544-Mbps DS-1
125 Microseconds, 193-Bit Frame
CH1 CH2 CH24 CH1 CH2 CH24
BF Channel 1
BF
24 Separate PCM Inputs at 64 kbps Each
Channel 2
Channel 24
Time Division Multiplexer
Total 1.544 kbps
Time
CH1 CH2 CH24 CH1 CH2 CH24
BF
BF
Note: - The BF bit is the framing bit. It is the last (193rd) bit in every frame. - The analog signal is transformed from 24 separate signals with 4 kHz bandwidth each to 24 separate PCM signals. - The sampling interval (125 ms) is calculated on the premise of a sampling rate of 8 kHz. - The speed 1.544 Mbps = (24 separate PCM channels) x (8000 samples per channel per second) x (8 bits per sample) + (8000 BF bits per second).
Each of the PCM samples is interleaved in time sequence into a single high-speed digital signal that begins with a signal that is referred to as channel 1 and ends with a signal that is referred to as channel 24. The process is repeated for 8-bit samples from each channel for 24 8 = 192 bits. The following bit (number 193) is the framing bit; it is used for time synchronization. The frame is a sequence of time slots, with each slot containing a sample from one of the channels. Given an 8-kHz frame rate, the sampling interval is 125 microseconds, and each frame consists of 24 time slots. Therefore, 24 channels multiplied by 64 kbps for each PCM input yields 1.535 Mbps. If you add the BF bit for every sampling interval, the overall rate is 1.544 Mbps. The multiplexor loads the time slots with bits and the de-multiplexor removes them on the receiving side. The recipient of the bits is determined by the position of the bits in the data stream. The exchange of bits in a predened time slot is also known as synchronous TDM,
T-Carriers
75
and refers to the fact that the time slots are xed and preassigned. This scheme requires perfect timing and synchronization between sources. TDM is not limited to digital signals because analog signals can be interleaved too. Unlike synchronous TDM, asynchronous TDM allows time slots to be allocated dynamically. It is possible to combine FDM and TDM in one medium, where the transmission media can be subdivided into a number of channels and every one divided by time for TDM.
T-Carriers
Digitalization of voice is the breaking point of the transition from analog to digital carriers. PCM voice made this possible without a large investment and having to run new cables and trunks to double the available capacity over the same copper pairs.
NOTE
Dont forget: The N-carrier of an analog system runs 12 voice channels over the existing copper pairs, and TDM runs 24 channels.
The initial enormous expense for codecs and DSU/CSUs is now offset by relatively inexpensive facility changes and as a result, an increased trunking capacity of the carriers. As previously mentioned, replacing the N-carriers with T-carriers doubles the capacity over the same two pairs, and 24 simultaneous voice calls can be handled from the CO. The digital trunks led to the production of digital switches, and replaced the analog switchboards with its related personnel and problems. The remaining component of the transition process is the last mile, also referred as a local loop. The twisted copper pairs to local residences and businesses make up the vast majority of the existing wires. Copper pairs prevail over digital, ber, or any other contemporary solution, which creates an opportunity for the emergence of xDSL technologies.
T1/E1 and Primary Rate Interfaces, T1s, and DS

Usage of T1s is still a growing LEC and inter-exchange carrier (IXC) service. The T1 signal can be transmitted one mile before requiring a repeater, which regenerates the signals, recovers the timing, and sends the regenerated version of the coding sequence. A T1 signal is referred to as a DSX-1 interface (digital signal crossconnection point for DS1 signals), which is capable of sending/receiving the T1 signal up to 655 feet. The maximum distance between the CSU and the last network repeater should not exceed 3000 feet. Network repeaters are installed every 6000 feet within the T1 carrier network to compensate for signal loss. The signal loss, called attenuation of the signal, requires that a CSU be set to automatically adjust attenuation values depending on the received transmission level. To adjust power levels, Cisco routers support interface conguration
76
commands called cablelength short and cablelength long, with short-haul being the 655 ft run (max of 1310 ft) and long-haul being the more typical CO to CPE run of 6000 ft (repeated every 3000 ft). T1 carriers support 24 full-duplex voice channels that only use two pairs of unshielded twisted pair (UTP). The control signals are generated within the CPE. T1 circuits can be terminated at the premises in a number of ways including DS3, SONET, or high-data-rate DSL (HDSL), among others. Typically, the local provider installs some type of network interface unit (NIU) or card to deliver the T1 to the CPE. This device could be a smartjack, M13 multiplexor, or HDSL device, and it usually terminates the circuit through a punchdown. The T1s are terminated by using two twisted-pair circuits. CSUs, and possibly DSUs, are required to connect the CPE to the DS1 service. CSU functions include conditioning and equalization, error control, and the ability to test local and loopback circuits. For a phone company, line conditioning and equalization is the spacing and operation of ampliers, so the gain provided by the ampliers for each transmission frequency compensates for the line signal loss at the same frequency. DSUs provide transmit and receive control logic, synchronization, and timing recovery across the T1 and the other digital circuits (when these signals are not implemented in the CPE). A DSU also converts ordinary binary signals that are generated by the CPE to special bipolar signals. These signals are designed specically to facilitate transmission at 1.544-Mbps rates over UTP cable, which was a media originally intended for 3-kHz voice band signals (see Figure 3-3). A typical DSU has a legacy serial interface (such as a RS232, or V.35, and so on) and a T1 interface.
Figure 3-3 How Data Service Unit/Channel Service Unit (DSU/CSU) Works
Binary Data Signals
CPE Channels
Data Service Unit (DSU)
Channel Service Unit (CSU)
4-Wire, Twisted-Pair UTP T1@1.544 DS1 Rate

Fiber Optic Cable FT3 Lightwave 28 DS1 Channels @ 44.736 Mbps
4-Wire, Twisted-Pair UTP T1@1.544 DS1 Rate

CSU/ DSU
CPE
Coded Bipolar Signals
Coded Bipolar Signals
The DSU and CSU may or may not be part of the CPE. On the left and right side of Figure 3-3, you can see the same devices, but on the left side, they are separated. Usually, Cisco routers have DSU/CSU devices built-in and external devices are not necessary. Cisco routers that contain a built-in CSU can attach directly to this termination point through external cabling. If the router does not contain a built-in CSU, an external CSU must be purchased to connect to the carrier network.
T-Carriers
77
T1s and DS and TDM Hierarchy

T1 frames consist of 24 8-bit words plus a framing bit. Each time slot of the frame contains 8 bits of binary information and is called DS0, which is sampled 8000 times per second. Because each DS0 contains 64 kbps (8 k samples/sec 8 bits/sample) of user information and 24 DS0s are in a T1 frame, this 1544-kbps signal is commonly referred to as DS1. (DS1 refers to digital signal level 1, which is a framing specication.) T1 refers to the digital transmission system that happens to operate at DS1 rates. Unlike DS1, T1 specically includes physical transport denitions and line-coding schemes, and as with every other technology, there is a T-carrier hierarchy (see Table 3-1). A T3 carries 28 T1s, yielding 672 channels over one coaxial cable, and can be considered an analog E-carrier.
Table 3-1 TDM Hierarchy Digital Signal Level n DS-1 DS-2 DS-3 DS-4 DS-5 North America 1.544 Mbps24 channels 6.312 Mbps96 channels 44.736 Mbps672 channels 274.176 Mbps4032 channels Not available Japan 1.544 Mbps24 channels 6.312 Mbps96 channels 32.064 Mbps480 channels 97.728 Mbps1440 channels 400.352 Mbps5760 channels Europe 2.048 Mbps30 channels 8.448 Mbps120 channels 34.368 Mbps480 channels 139.264 Mbps1820 channels 560.000 Mbps7680 channels
E1
As you can see from Table 3-1, Europe uses another format at the DS-1 level. This format is in compliance with the European Postal and Telecommunications administration, known as the Computer Emergency Response Team (CERT). In the frame format known as E1, CERT denes 32 time slots that are multiplexed in a way to yield a frame of 256 bits in 125 microseconds. One of the time slots is used for signaling, another one is used for alignment and synchronization, and the remaining 30 time slots are used for data, yielding a user data rate of 1.920 Mbps, and an overall data rate of 2.048 Mbps.
NOTE
A key standard for managing digital access lines is RFC 1406 Denitions of Managed Objects for DS1 and ES1 Interface Types. It denes a set of Management Information Bases (MIBs) and can be used for Transmission Control Protocol/Internet Protocol (TCP/ IP) Simple Network Management Protocol (SNMP). The MIBs track the error conditions, performance defects and parameters, and failure states. When a carrier provides proactive monitoring of circuits for enterprises, they basically implement MIBs for reporting.
78
Network Signaling Systems and SS7

Although totally hidden from the end user, the carriers signaling systems are similar to a central nervous system in the human body. Signaling systems provide essential information between switches to exchange link status, connection control (signaling), and routing information. Robbed bit signaling (RBS), which was typical in the early 1970s, was replaced with out-of-band signaling, which eventually became a de facto standard for the exchange of signaling information.
NOTE
Out-of-band signaling uses frequencies outside of the normal frequency band for signaling, and it is the core of SS7. In contrast, in-band signaling relies on using certain bits out of each frame in the frequency band, which is why it is called RBS.
Common channel signaling (CCS) was another type of signaling that historically dominated the way carriers exchanged supervisory, addressing, and call information. One of the benets of the new system (SS7) was that it reduced the time for call setup from between 15 to 20 seconds, to 1 to 3 seconds. In 1976, the system was called Common Channel Interofce System No. 6, as it was based on signaling system No. 6 (SS6) from the International Telecommunication Union Telecommunication Standardization Sector (ITU-T). It offered a wide range of services for end users, such as callback and 800 (INWATS) capabilities. Because SS6 was not exible enough for the emerging ISDN standards and services of the mid 1970s, a new standard called SS7 was developed. The Q.700 recommendations from ITU-T and ANSIs T1.110-Series standards dene the SS7 specication. The architectural model is composed of four layers. The lower three levels are part of the message transfer part (MTP), and provide reliable connectionless routing for user data through the network. MTP includes the following:
Signaling data link, which corresponds to Open System Interconnection (OSI) Layer 1 Signaling link, which corresponds to OSI Layer 2 Signaling network
MTP does not provide all the functions of the rst three layers of OSI, especially when it comes to connection-oriented services. In 1984, a module called the Signaling Connection Control Part (SCCP) was added and today these four layers are called the Network Service Part (NSP), and perform functions typical of the rst three layers of the OSI model. An important element of the model is the ISDN User Part (ISUP), which was developed to provide control signaling for ISDN and related subscriber lines, calls and functions, and which covers layers from SCCP all the way to the top of the OSI model. The higher layers of the SS7 architecture include the transaction capabilities applications part (TCAP), for transaction-oriented as opposed to connection-oriented applications and functions. Also,
SONET, Synchronous Transport Signal, and Synchronous Digital Hierarchy
79
operations, administration, management, and provisioning (OAM&P) and a set of application service elements (ASEs) dened the remaining layers and dened support for other applications. In SS7, the control messages are routed through the network to perform call management, such as call setup, call maintenance, and call termination. These messages are standardized blocks of data that are routed throughout the network, and consequently the circuitswitched networks are running packet-switched messages, which transform legacy functions to a new set of features. SS7 denes control and information planes of operation, where the control plane is responsible for the call setup and for managing the connection, and the information plane is responsible for phases after the call setup, to route additional control information between communicating parties. The latter deals with local exchanges and transit centers, where the core of the control plane signals elements of the network. From a troubleshooting point of view, the signaling network elements are the most important parts, and include the following:
Signaling point (SP)The remote user connects to the SP, obeying the rules of UserNetwork Interface (UNI) and signaling conventions such as Q.931. SP is capable of handling the control messages. Signal transfer point (STP)A SP connects to one or more STPs. This is an element that is capable of routing signal messages that are received from one signaling link to another signaling link. Signaling linksThis is a data link that connects SPs.
When a connection is requested by a remote user, it occurs over the D channel, uses Q.931 messaging, and is between the user and the LE. For this purpose, the LE acts as a SP. The Q.931 message is converted to SS7 and the user-requested action establishes and maintains the connection. This process can involve one or more signaling points and STPs. After the connection is set up, the information ows from one end to another, under the control of the information plane.
SONET, Synchronous Transport Signal, and Synchronous Digital Hierarchy

SONET is a ber-optic-based network specication that is capable of speeds up to 2 Gbps. SONET is based on using optical media, and as such has numerous advantages in comparison to copper conduits. SONET uses STS Level 1 (STS-1) as a basic building block and, like any standard STS-1, assures interoperability of equipment from multiple vendors.
80
The Optical Fiber Hierarchy of Circuits

The digital hierarchy of SONET is based on Optical Carrier Level 1 (OC-1), which denes transmission rates of 51.84 Mbps. Therefore, the hierarchy starts with data rates of close to T3 speeds of 51.840 Mbps. The transmission rate of 51.840 Mbps is also called STS-1. Every OC-x transmission rate of SONET is the exact multiple of the basic speed, which creates a straightforward way of multiplexing the higher speed formats. The international hierarchy is known as SDH, with starting data rates of OC-3. The optical ber hierarchy is shown in Table 3-2.
Table 3-2 Hierarchy of Optical Transmission Rates OC-Level (Optical) OC-1 OC-3 OC-12 OC-24 OC-48 OC-192 STS Level (Electrical) STS-1 STS-3 STS-12 STS-24 STS-48 STS-192 SDH Equivalent STM-1 STM-4 STM-8 STM-16 STM-64 Line Rate (Mbps) 51.840 155.520 622.080 1244.160 2488.320 9953.280
Carriers Facilities and Switching Systems

This section provides you with more information about LECs, IXCs, their facilities, areas of operation, and their switching systems.
First-Tier Exchange Carriers

Since the Telecommunications Act of 1996 in the U.S., a service provider can be any provider of telecommunications services that is certied by individual states to become a LEC. The newly certied companies acquired the name of competitive LEC (CLEC), and the existing (former) companies are called incumbent LECs (ILECs). There are several other LECs (OLECs) and some other abbreviations, but for simplicity, only rst-layer carriers are referred to as LECs. Recently, more than 1300 LECs were in operation in different parts of the U.S. The country is divided into 240 areas that are called local access and transport areas (LATAs or LATs), which are based on approximately an equal number of calls in each area. A LEC refers to any company that operates in the LATA boundaries, providing Intra-LATA services and functions. LECs can operate in many LATAs, but cant carry trafc between separate LATAs.
81
Inside the CO
Access lines from CPEs and trunks to other switches enter the local exchange, otherwise called central ofce (CO), usually with rare exceptions below ground level. This subbasement is known as a cable vault, and in some metropolitan areas their number can exceed tens of thousands of lines and trunks. The lines and trunks eventually make their way up to the main distribution frame (MDF), which is a facility usually called a wire center. An IXC uses the same term differently, where the MDF is a large, two-dimensional patch panel, and every line or trunk has a unique horizontal and vertical number. The number and variety of switches in the U.S. and other countries is enormous, and it is practically impossible to provide any kind of precise classication. It is important to remember that the purpose of patching is to adequately identify each connection; this identication is required to assign each connection to the port of the switch. The switching in the CO is always port-to-port, bandwidth-to-bandwidth, and is transparent to any of the bits or packets exchanged over the lines and trunks. In general, there are two ways to switch data in the CO:
Leased line Switched
The term nailed-up refers to a situation when the lines are patched in such a way that they always transfer data from port A to port B. This is leased-line terminology, which is typical for Frame Relay solutions using FT1 and T1/E1. The data can be transferred through the PSTN or redirected to equipment called a Digital Crossconnect System (DCS). This facility, which is also known as private line (non-switched) service, bypasses the PSTN switch, and transfers data from the access lines straight to the trunk system. A private line solution ensures privacy of the data exchange and is one of the providerdependant Virtual Private Network (VPN) solutions. DCS is a digital type of equipment that operates over digital access lines, but not over analog local loops. To provide analog local loop conversion to DCS, the signals must rst be converted to digital form. Data that is switched through the CO uses a local switch(s) that is based on the dialup phone number from the call originator. This solution is related to dialup, ISDN, and other services that require an initial call setup phase before proceeding any further. Each circuit that must be switched must rst have a port assigned on the switch. As soon as the originator issues a call, the call is redirected to the requested destination, without adding anything to the content of the user data.
Second Layer Exchange CarriersIXC

In the U.S., segmentation of the telecommunication network is related to the area in which they operate, and is governed by a single carrier (LATA). To distinguish between different areas and services, there is another set of terms related to the interconnection of different
82
carriers and their zone of responsibility. As previously mentioned, the rst layer carriers operate in the LATAs. If calls cross LATA boundaries, they need to be handled by an IXC, sometimes called IECs or long-distance carriers. To provide this long-distance service, IXCs need to maintain a point of presence (POP), or switching ofce within the LATA. Based on FCC issued licenses, more than 700 companies operate as IXCs today. AT&T and Sprint hold the largest market presence in the U.S. Interestingly enough, Sprint still maintains a few LECs in areas such as North Carolina and Nevada, which creates an unusual mix between LEC and IXC. If, in any particular area, the IXC does not have a POP, based on the rules of equal access, the long-distance can be handled by another IXC, which charges back for the service.
Switches and Tandems

From the carriers point of view, every carrier system can be broken down into switching systems, transmission facilities and CPE. The CPE (or station equipment) includes all available equipment on the customer side. The dividing line between provider access services and the CPE is called the network point of termination (POT), network interface (NI), Demarcation Point (D-mark), or minimum point of entry (MPOE). The transmission facilities include loop and interofce. Loop transmission facilities provide clocking, switching, and signaling for the CPE. This part is often called a local loop, subscriber line, subscriber loop, or line. Interofce transmission facilities connect the carriers switching system. In this design, the term trunk refers to the communication path between two switches. The available options are to create full-mesh or partial mesh systems, with either no switching (leased lines), endpoint switching, or central switching, based on CO facilities. It is important to consider the carriers telecommunication network as two segments working together: access services and transport services.
NOTE
When working with carriers, you can often see how they include different groups in the troubleshooting process, depending on the issue. When the local loop is down, you usually deal with technical CO personnel, but when your calls are not going through, the transport personnel must be involved in the troubleshooting process.
LEC/IXC Operations
When the CPE requires service, IXC involvement is not necessary if the problem deals with a LATA local phone call, a local long-distance voice call, data calls through dialup, and ISDN, or if a switched virtual circuit (SVC) is made to the local phone number. This reects the tariffs of the service and the performance characteristics. When the same scenario
83
includes different area codes in the connection (long distance), there is an interaction between carriers that must be considered in the design process. The efciency of interacting with different carriers depends on the way that their networks are structured, and their ability to provide immediate and high quality call transfer. Calls are metered by their number and duration. The fewer switches (hops) in the path of the call, the faster the call. At the same time, it is hard to maintain a full set of trunks from an IXC to every single LEC, creating a fully meshed structure not only within the IXC network, but also outside of it.
Tandem Ofce and Tool Ofce

Trunks are not directly run to another LECs facilities, but to more centrally located LEs that are intermediate points equally convenient for all parties. These LEs are equipped with a secondary switch called a tandem that provides switching trunk-to-trunk, instead of local loop-to-local loop or local loop-to-trunk. It is provisioned for equal access from both parties and for providing services to them. Tandem is a telephony term that means to connect in series. Thus, a tandem switch connects one trunk to another. A tandem switch is an intermediate switch or connection between an originating telephone call or location and the nal destination of the call. The practice of trunk-to-trunk switching received the name of toll ofce, and a call routed through this ofce is called a toll call. Unlike long-distance calls, these calls stay within the LATA and do not cross LATA boundaries. This solution architecturally alleviates the challenges of an IXC, which instead of running trunks from anywhere-to-anywhere now runs trunks from their network to the nearest tandem ofce. From an IXCs perspective, the toll ofce is called a service wire center, which provides services for POPs. Most IXCs maintain more than one center within the LATA, to provide redundancy for their services. LECs cannot provide Inter-LATA calls on their own because LEs are designed to provide service for all carriers within the LATA, and the LEC must route all Inter-LATA calls to trunks that are terminated by the IXCs POP (see Figure 3-4). Of the LECs switches, the last switch pointing to the IXC is called an end ofce (EO), and it must be congured to point to the specic IXC (101010 for AT&T, 333 for Sprint, and so on). The IXC POP has access to more than one EO within the LATA. When the IXCs switch or LECs switch is partitioned and certain trunks are designated for specic users, this is referred to as a VPN. Figure 3-4 shows the LATA boundaries, IXC area of operation, the locations of IXC POPs, network points of termination (POTs), and network points of interface (POIs). In the lower end, LECs provide line-to-trunk connectivity for CPEs; the upper half shows the interaction between LECs and IXCs through tandem (trunk-to-trunk) switches. The book The New McGraw-Hill Telecom Factbook by Joseph A. Pecar and David A. Garbin (McGraw-Hill Professional Publishing, 2000) is an excellent reference for different designs and details, and conveys a complex technical subject in an easy-to-understand manner.
84
Figure 3-4
Design Example of Inter- and Intra-LATA Carriers Interaction

IXC Network
Network Interface
Network Interface
IXC POP Tandem

T r u n k s T r u n k s
Service Management System

T r u n k s
IXC POP Tandem

T r u n k s
POT POI
Switching Network Special Circuits
POT POI
End Office (EO)

T r u n k s T r u n k s T r u n k s
End Office (EO)

T r u n k s
To other IXCs
To Other IXCs

To Other Customers
Lines

Central Office A
T r u n k s
To Other Customers
Lines
Central Office A
T r u n k s
Switching Network
Special Circuits
Switching Network
Special Circuits
Trunks
Trunks
Network Interface
T r u n k s Customer Premises Dsitribution System L i n e s
To Customer Premises Equipment
Network Interface
T r u n k s Customer Premises Dsitribution System L i n e s
To Customer Premises Equipment
LATA A
LATA B
An example of interaction between the LEC and IXC for billing purposes is shown in Figure 3-5.
ISPs and ASPs
85
Figure 3-5
Example Showing an Interconnection Between SBC as a LEC and Sprint as an IXC in the San Jose, California Area (Courtesy of Cisco Provisioning)
Local Access/Toll (Data and Voice) Long Distance (Voice Only) Home Teleworker Local-inside LATA 1 2 bills Gilroy, CA (Example)
Intra-LATA Local/Toll Voice or Voice and Data
Local Access/Toll (Voice Only) Long Distance (Data and Voice) Home Teleworker Local-Outside LATA 1 2 Bills Tracy, CA (Example) Cisco Sytems ISP
National ISDN (Data Only) Local Access/Toll (Voice Only) Long Distance (Voice Only) Home Teleworker National ISDN User 3 Bills Anytown, USA
$.05-$.07 Channel (2)
800 Number National ISDN Backbone
Inter-LATA Long Distance Voice
LATA Boundary
Local Access = Monthly service charge, tax, local & toll charges (voice only or data & voice) Long Distance = Pic to contracted long-distance carrier (voice only or voice & data) National ISDN = 800# ISDN backbone (data only)
ISPs and ASPs

From the standpoint of LECs, the ISP is another service that provides dedicated services through host routers with access to Internet backbone routers. LECs consider these services as point-to-point, bypassing the PSTN-switched facilities. Usually, the analog dialup ISPs require trunks in a 10:1 user to port ratio, to keep the users/monthly charges ratio in the
86
protable range. Adding more trunks does not necessarily mean more bandwidth, but denitely means more charges. These lines are patched in a way to redirect the calls to access servers, which are routers with enough modem capacity. They are sometimes called terminal servers. The other connection from the router usually links to another major ISP, or directly to one of the core Internet routers. This core router is usually called a network access point (NAP). NAPs are common for the larger ISPs but rare for the small ISPs. The link is usually T1, or some other T1 hierarchy line, depending on the technical solution. This part of the network is relatively transparent for the end user. The other part of the ISPs network, such as web servers, mail servers, and news servers are located behind the rewall, and remote user access is restricted based on the contract between the two parties. Over the last several years, there has been a tendency to change the way ISPs operate and to combine the typical LEC and IXC functions with ISP functions. In this case, the ISPs supply the Internet access straight to the local loops and trunks, and then onto leased trunks and lines of the ISPs POP.
NOTE
Can you see the terminology change? Earlier, POP referred to the presence of a longdistance feature, and now POP refers to the presence of Internet access. This is not the rst terminology change, nor the last one. It is common to use legacy terms to explain new features in order to alleviate the complexity of the transformation process.
After 1994 and the World Wide Webs (WWW) technology boom, another service trend was Application Service Provider (ASP) and web hosting. Within an IT organization, there is a function to create, design, maintain, and support the IT infrastructure. In early 1997, some analysts showed that it is expensive to support an IT infrastructure because it is not created as a revenue-generating unit. The estimates demonstrated that most investments, including facilities, support groups, power supply, and even some of the design functions, can be outsourced to reduce the cost to the enterprise, according to some authors, by more than 50 percent. Thus, the choice to outsource IT versus supporting IT in-house became a valid alternative to existing solutions. Two of the main elements of this scenario are as follows:
Availability of specic facilities (data centers) that provide not only ISP, but also ASP features. These services usually require a signicant investment to build and support this infrastructure, which is generally only affordable by large companies such as AT&T and Sprint. Therefore, large web-hosting companies (Yahoo.com, for example) can rent private areas in these facilities and host server farms, and achieve highavailability, security, fast access, and other objectives without excessive spending.
NOTE
In 2001 alone, Sprint was planning to invest over $2 billion in expanding and improving its IP businesses for its 18 new Internet centers that are to be completed by the end of 2002.
Data Centers and Internet Hosting Services
87
Availability of professional services organizations (EDS, IBM, Sprint) able to deliver complex projects for enterprises.
The latter group of services is beyond the scope of this book, but additional information on the services provided by data centers is documented in the next section.
NOTE
History shows that during the early days of computing, there was a tendency for concentrated, centralized computing power. The next generation of computing was driven by decentralized computer power systems. Now, the pendulum has swung back and computing power is once again becoming centralized (data centers, data farms); however, it still has aspects of a decentralized environment (multiple functions and dispersed geographically). The challenge for you is to determine the next trend.
Data Centers and Internet Hosting Services

Data centers usually provide physical facilities, installation and maintenance, environment management equipment (electrical/mechanical/temperature), power management, generators, uninterrupted power supply (UPS), electrical supply, ber access, security, network services, monitoring, and management. The main factors that affect the enterprise in its decision to use outsourced data centers as part of its remote access plans are the following:
National presence of the provider with multiple data center facilities Solid management structure and practices Extensive network management and support expertise Financial stability and experience in supporting businesses of all sizes while demonstrating scal competence Absolute commitment to quality and customer satisfaction Improved response with real-time, load balancingTools dynamically balance the load between the Internet centers and the servers within those centers. Even when a user is in the middle of a session, this technology automatically routes a request to another server when a server experiences either planned or unplanned downtime. The result is improved response and enhanced performance. True site mirroring for enhanced reliability and performanceFor customers desiring geographic redundancy, multiple servers are geographically distributed across server sites. This redundancy translates into a highly reliable, fault tolerant environment that ensures that visitors to the web site experience no disruptions during their session. Robust web interfaceEach customer is provided secure, encrypted, access to the control center through the public Internet or through a provider-based VPN IP network.
The benets to the enterprise for this type of solution include the following:
88
Complete exibility for unique solutionsCustomers can run and manage their own applications on a providers managed hardware. The private application segment also allows customers to connect to their premises for interoperability with legacy systems. Database supportAdditional services for database support is available for varied database management systems.
Unlike legacy LEC/IXC solutions (see Figure 3-4), the main difference of the data center is the existence of an Internet (POP), which is equipped with highly sophisticated hardware. Sprint, for example, offers the following hosting packages for potential customers: enterprise hosting, standard commerce hosting, enterprise commerce hosting, and custom hosting. One possible solution for custom hosting is when Company Y requests hosting services from Sprint (see Figure 3-6).
Figure 3-6 The Web-Hosting Architecture for a Company Y Requesting Service from the Data Center of Sprint in Two Different Geographical Locations
Sprint Link Company Ys Network VPN
West Coast Data Center
East Coast Data Center
GSR Out-of-Band Router 6509
GSR
GSR
GSR
6509
6509
6509
Load-Balancing Equipment
Load-Balancing Equipment Content Engine
6509
6509
6509
6509
Company Ys Environment
Company Ys Environment
Database Application Web Server Server Server Cisco Lightstream Switch Storage Area Networking Equipment
Web Cisco Caching Cisco Caching Engine Server Engine Utility Server
Database Application Web Server Server Server Cisco Lightstream Switch Storage Area Networking Equipment
Web Server
Cisco Caching Cisco Caching Engine Engine Utility Server
Tape Library
Tape Library
Out-of-Band Replication
The Future of Service Providers
89
Figure 3-6 shows the extensive use of Cisco equipment, including Gigabit Switch Routers (GSRs) and Cisco 6509s, Content Engines, and Cisco ber-optic switches in the data center and customer environment. Beyond data-center equipment, the outsourcing company has the freedom to deploy and install any other equipment necessary for its normal operations. The parts of the data center not shown in this gure include private branch exchanges (PBXs), and highly sophisticated UPSs. Part of every enterprise agreement is the network services agreement and service-level agreement (SLA). In the case of Sprint, they are as follows:
Direct connections to Sprints OC-48 Internet backbone with a range of LAN and WAN connectivity optionsSprint is also deploying dense wavelength division multiplexing (DWDM) equipment that provides Sprint with virtual ber by splitting light waves into separate, distinct channels. Sprint deployed 40-channel DWDM equipment that is scalable to 96 channels or 240 Gbps. In 2001, Sprint began deployment of 80-channel DWDM systems with each channel capable of supporting an OC-48 or OC-192 signal. Industry leading SLA guaranteesA quote from one of the Sprint SLAs is as follows:
Leading service level agreementsWith geographically redundant web servers, youre guaranteed 100% web site availability. Sites without geographic redundancy are guaranteed to be available 99.5% of the time. This guarantee applies to Sprint-provided and managed hardware and software. Sprint will credit up to 50% of the monthly recurring charge should the site become unavailable.
(Taken from www.sprintesolutions.com/solutions/infrastructure/managed_hosting/ about.html#Leading.) Because Company Y is using an outsourced data center model, some caveats must be addressed in the early design stage. The considerations include concerns about commitment of the other party and the level of control. Company Y depends on the outsourcer to obtain, integrate, and support the technology from their premises; to link with the companys operations; and to recruit, train and supervise staff in their support centers. Also, it must consider the management of its most precious asset, its customer data, to an outside rm.

Remote access design is usually implemented to meet the business need for a longer rather than shorter period. This decision requires an answer to the question how will service providers change in the future? Emerging technologies will continue to require that enhanced and complex services be supported by providers.
90
Service Offering
One of the main directions in the service offering for remote access is Multiprotocol Label Switching VPN (RA to MPLS VPN). This service enables users to connect to the corporate network and handles remote access connectivity for mobile users, telecommuters, and small ofces through dial, ISDN, DSL, cable, and wireless technologies (see more in Chapter 19). The increase of IP-based transport changes the focus of the transport from TDM to packet-based services. The connection-oriented restrictions of TDM systems will be overcome with connectionless technologies by providing higher versatility and multiservice support features. These technologies include Media Gateway Control Protocol (MGCP), HTML, Voice XML (VXML), session initiation protocol (SIP), and Automatic Speech Recognition (ASR). These technologies enable service offerings that can be tailored to any combination to meet the customers needs.
The Last-Mile Problem

In July 2001, a group called IEEE 802.3ah Ethernet in the First Mile Task Force (http:// grouper.ieee.org/groups/802/3/efm/public/) was established to provide solutions for the socalled last-mile issue. Currently, a wide variety of protocols provide services to the last mile. They include ISDN, DSL, cable modems, satellite, and broadband wireless solutions, which offer speeds under 10 Mbps. However, existing Intranets use technologies such as Fast and Giga-Ethernet with speeds several Gbps and higher. Therefore, to interconnect these two environments, a fairly sophisticated protocol conversion is required. To achieve the conversion goal, the Task Force planned to bring Ethernet to home users. For this purpose, IEEE 803.3ah denes three access layers: home network, access/distribution layer, and a core layer. IEEE also denes three main topologies (the analogy with the Cisco design model is obvious).1 The topologies are based on two main factors for media and for conguration of the access/distribution layer:
Ethernet over a point-to-point copper line is expected to adopt the very-high-data-rate DSL (VDSL) and Media Access Control (MAC) protocol on the top of the VDSL physical specication. This should be able to deliver speeds ranging from 10 Mbps and higher over existing copper cabling. Gigabit Ethernet over point-to-point ber is supposed to deliver speeds up to 1 Gbps for distances up to 10 km (6.25 miles). Point-to-multipoint ber topologyThe multipoint part is an aggregation point, called an access switch, which provides services for up to 16 passive splitters that are connected to optical network terminators. This topology is designed to deliver speeds starting from 30 to 60 Mbps, up to 100 to 200 Mbps for business and residential customers.
Cisco Systems announced the Optical Ethernet to the First Mile (EFM) Cisco Catalyst 4000 Family in December 2001. The Cisco Catalyst 4000 Series includes a 48-Port 1000BASE-
91
LX Gigabit Ethernet Line Card, a 48-Port 100Base-FX Line Card and a Cisco ONT 1000 Gigabit Ethernet. All solutions work with the Cisco Ethernet Subscriber Solution Engine 1105 (Cisco ESSE 1105), which is a hardware-based management system for metro access networks and the Cisco Secure Access Control Server (ACS) Version 3.0 centralized access control.
The 3G Wireless Alternative

A bit of a battle is shaping up inside the industry over 2G, 2.5G, and 2.75G solutions. Verizon and Sprint are backing (code division multiple access) CDMA2000 technology. AT&T Wireless, Cingular Wireless, and VoiceStream are backing the Global System of Mobility/General Packet Radio Service (GSM/GPRS) systems, which provide speeds that range from 15 to 40 kbps. Nextel is backing its iDEN (Motorola proprietary version of TDMA with its unique push-to-talk radio capability). The Wireless 3-th Generation (3G) solution is seen as an evolutionary new path in telecommunications. CDMA2000 1xEV-DO was standardized by the Telecommunications Industry Association (TIA) in October 2000. 1xEV-DO was recognized by the ITU-R WP8F as an IMT-2000 standard. The rst CDMA2000 networks were launched in Korea in October 2000, providing 144kbps data rates to subscribing customers and delivering nearly twice the voice capacity that operators experienced with their cdmaOne (IS-95) systems. The success of the CDMA2000 1X system in Korea has encouraged many operators in the Americas and Asia to follow through with their plans to launch CDMA2000 this year. Although the arguments about true 3G solutions in the U.S. are underway, Verizon Wireless with its Express Networks became the rst carrier to launch 3G wireless in the U.S. in January 2002primarily in the Bay Area, East Coast, and Salt Lake Cityoffering speeds up to 144 kbps, with an average of 40-60 kbps. Meanwhile, Sprint PSC, working with partners such as Samsung and Hitachi, announced its plans and launched nationwide (U.S. market), a 3G solution in August 2002 called PCS Vision. According to the ITU, a 3G link must be able to send data at rates of up to 144 kbps while mobile, at rates of up to 384 kbps at walking speeds, and at rates of up to 2.4 Mbps when stationary. These speeds are expected to be exceeded soon. The available sources show that plans are underway for variations on CDMA2000, which will change 3G systems dramatically. The wider band, commonly referred to as CDMA2000 3X or 3XRTT will be replaced by a two-phase strategy called CDMA2000 1xEV. 1xEV stands for 1X evolution, or evolution using 1.25 MHz, which is typical for todays CDMA2000 1X systems based on a standard 1.25 MHz carrier for delivering high data rates and increased voice capacity peak data rates of 2.4 Mbps. The 1xEV includes two phases, labeled 1xEV-DO (DO-data only) and 1xEV-DV (DV-data and voice). The CDMA2000 1xEV-DO can provide customers with peak data rates of 2.4 Mbps. However, to implement 1xEV-DO, operators will have to install a separate carrier thats dedicated to data-only use at each cell location
92
where high-speed data services are demanded. Still, customers will be able to hand off seamlessly from a 1X to a 1xEV-DO carrier. As long as the demand for high-speed wireless high-speed access grows in the years ahead, all the carriers are expected to upgrade their systems to provide 3G services. E-mail exchange, instant messaging, and Internet browsing are the major forces behind the demand for 3G services.
End Note
1 Birkner,
Matthew H. Cisco Internetwork Design. Cisco Press, 2000.
Summary
As a troubleshooting engineer, you need to interact with your service provider(s) almost on a daily basis. It is important to know how the cloud and remote access design solutions interact between each other; how providers operate, engineer their circuits and services, what their areas of responsibility are, and many other factors. This will help you be more successful in your troubleshooting efforts. Besides, it is always benecial to know the specics of your local or long-distance provider and what services it offers now or will have available in the near future for your organization.
Review Questions
1 Is Asynchronous Transfer Mode (ATM) a synchronous or asynchronous technique?
Explain.
2 Name three of the advantages of digital signaling over analog signaling? 3 What does FDM stand for? What rule does FDM obey? 4 In North America, how many voice channels are in a standard multiplexing scheme
for FDM?
5 Describe the main phases of pulse code modulation (PCM). 6 What does TDM stand for? What rule does the TDM obey? 7 What is the purpose of bit number 193 in TDM? 8 What is a frame in TDM? 9 What do DS1 and DS-1 stand for? What is the difference between DS1 and DS-1?
Review Questions
93
10 What is out-of-band signaling? What is robbed bit signaling? 11 What do CO, LEC, CLEC, and ILEC stand for? What do they have in common? 12 What is the role of tandem switches in carrier networks? 13 What are the main caveats when the enterprise outsources service with the service
provider?
14 What are the three main topologies in Ciscos Ethernet to the First Mile (EFM)? 15 What does CDMA stand for? Name the 3G minimum speed requirements, as dened
by ITU.
CHAPTER
Troubleshooting Approaches, Models, and Tools

This is the nal chapter of Part I, Remote Access Fundamentals. The rest of the book covers material related to troubleshooting dial, ISDN, Frame Relay, and Virtual Private Network (VPN) solutions. Remote access troubleshooting in this book is focused more on the communication subsystem of the Open System Interconnection (OSI) model than on higher levels of the model. Some common models, approaches, and troubleshooting tools are available for the test engineers, which need to be claried before covering troubleshooting specic remote access networks. This chapter covers these models, approaches, and troubleshooting tools so that this material doesnt need to be repeated for each remote access technology covered hereafter. As such, this chapter outlines fundamental troubleshooting information that the remaining chapters will assume that you are familiar with. The main topics covered in this chapter are as follows:
Interconnection modelsThe Department of Defense (DoD)model and the sevenlayer OSI model Troubleshooting modelsThe layer-by-layer approach Common troubleshooting tools and techniques Cisco-specic troubleshooting tools
Troubleshooting is often considered an intuitive activity, where knowledge is sometimes not enough to successfully and effectively perform the task. However, knowledge and hands-on experience plays a decisive role in the troubleshooting process. This books focus is to help the troubleshooting engineer in day-to-day operations. Sometimes, your soft skills are as important as your technical skills, so here are some brief reminders about approaching troubleshooting in general:
Be passionate, but professional. Be ready to go the extra mile for your user, but dont get personally involved. Know the technology. When working with providers, knowledge beyond just your piece of the puzzle might save you a lot of frustration. Be familiar with and use professional terms and acronyms. Understand your providers internal procedures and specics and be supportive. Try to build mutual trust in your relationship with your customer; the customer is in trouble, but you can get in trouble, too. Show that you care for the customers problem. Work with the customer as your partner.
96
Chapter 4: Troubleshooting Approaches, Models, and Tools
Know your options. Be ready to say no if a request goes against rules, procedures, or policies.
Beyond your technical knowledge, all these components dene your professionalism and these soft skills can be decisive in your next troubleshooting case. A troubleshooting engineer needs to have a systematic approach for analyzing issues. Typically, in the case of an enterprise remote access environment where the engineer sees both ends of the connection, it is convenient to reduce the number of focus points to two or three: the remote user, the cloud, and the core router. Depending on your perspective or location, these also can be referred to as the near end of the connection, the far end of the connection, and the cloud in between. Based on this, some authors recognize the following approaches to troubleshooting:
Start from the near end Start from the far end Divide by half and start toward the near end or toward the far end
These approaches seem to be logical and systematic, given the fact that some networks can be complex. When troubleshooting, it is best to focus on one issue rather than jumping randomly from hop to hop, virtually dividing the network to three pseudo-independent segments: remote end, service provider(s), and near end. VPN solutions might seem to be an exception to this rule, but they are not. The remote user (equipment or client), Internet, and enterprise termination point create the same triad of componentsa simplied version of a complex solution. Given the fact that all components of every remote access design conform to one or more industry agreements (standards and protocols), another approach to troubleshooting is feasible. It is based on the industrys accepted layered models. The troubleshooting process can start from any end, but you should follow a layer-by-layer troubleshooting process, starting with layer one. This technology-based approach is used throughout later parts of this book.
NOTE
Of course, you can choose many other troubleshooting approaches. Regardless, its most important that the method be systematic and consistent, and that you are comfortable using it.
Interconnection Models
The goal of every interconnection model is to provide standards to which all computer hardware and software vendors can adhere so that the present multiplicity of interconnection and interface practices is reduced, thus reducing the costs of designing and producing both hardware and software. The existing models are covered in literally hundreds of sources in great detail, but the following section provides a short description
97
of the DoD model and the seven-layer OSI model from a standpoint of understanding the troubleshooting process.
Department of Defense Model

The efforts to create an interface model for internetworking started with the four-layer Department of Defense (DoD) model, which was developed by the Department of Defense in the 1970s for the Defense Advanced Research Projects Agency (DARPA) Internetwork Project (see Figure 4-1). The core Internet protocols adhere to this model, although the OSI model is preferred for new designs.
Figure 4-1 The Four Layers of the Department of Defense (DoD) Model
Process TELNET FTP SMTP Host-to-Host TCP UDP Internet IP Network Access Ethernet ARP FDDI
The four layers of the DoD model, from bottom to top, are as follows:
Network access layerResponsible for delivering data over the hardware media. Different protocols are selected from this layer, depending on the type of physical network. Internet layerResponsible for delivering data across a series of different physical networks that interconnect a source and a destination machine. Routing protocols are most closely associated with this layer, as is the Internet Protocol (IP), which is the Internets fundamental protocol. Host-to-host layerHandles connection rendezvous, ow control, retransmission of lost data, and other generic data ow management. The mutually exclusive Transmission Control Protocol (TCP) and User Datagram Protocol (UDP) are this layers most important members. Process layerContains protocols that implement user-level functions, such as mail delivery, le transfer, and remote login.
98
Seven-Layer OSI Model

In the 1980s, the European-dominated International Standards Organization (ISO) began to develop its OSI networking suite. OSI has two major components: an abstract model of networking (the basic reference model, or seven-layer model), and a set of concrete protocols. This model eventually grew into the Internet, to which the core Internet protocols adhere. This section discusses the layers of the OSI model. The physical layer is concerned with transmitting raw bits over a communication channel. The design issues are related to timing, line coding, and framing. Categories of the physical layer include simplex, half duplex, and full duplex. The layer deals with the physical (electrical and mechanical) aspects of transmitting data (such as voltage levels, pinconnector design, cable lengths, and grounding arrangements). The main activity of the data link layer is to deal with the transmission of data frames over a physical link between network entities, including the incorporation of error-correcting coding into the data frames. It accomplishes this task by having the sender fragment the input data into data frames (typically a few hundred bytes), transmit the frames sequentially, and process the acknowledgment frames that are sent back by the receiver. It is up to the data link layer to create and recognize frame boundaries that can be accomplished by attaching special bit patterns to the beginning and end of the frame. If there is a chance that these bit patterns might occur within the data, special care is taken to avoid confusion. This layer is responsible for error control between adjacent nodes, and consequently, ow regulation and error handling are integrated. The network layer controls the operation of the subnet. The network layer establishes paths for data between a pair of computers, handles any switching among alternative routes between the computers, and also contains denitions of how to break the data segments up into individual packets of data. In this way, packets can be transmitted and reassembled. A key design issue is determining how packets are routed from source to destination. Routes can be static, when the routing does not depend on network conditions, and dynamic, when routes can be dynamically determined based on routing protocol decisions that reect network conditions. An excessive number of packets in the subnet require sophisticated congestion control, which is another function of the network layer. When a packet has to travel from one network to another to get to its destination, many problems can arise. The addressing used by the second network might be different from the rst one. The second one might not accept the packet at all because it is too large, or the protocols might differ, and so on. It is up to the network layer to overcome all routing problems to allow heterogeneous networks to be interconnected. In broadcast designs, the routing problems are simple, and as a result the functions of this layer are reduced. The basic function of the transport layer is to accept data from the session layer, split it up into smaller units if necessary, pass these to the network layer, and ensure that the pieces (segments) all arrive correctly at the other end, performing the mandatory ow control. If the transport connection requires a high throughput, the transport layer might create multiple network connections by dividing the data among the network connections to
99
improve throughput. The transport layer also determines what type of service to provide to the session layer, and ultimately, the users of the network. The most popular type of transport connection is an error-free point-to-point channel that delivers messages in the order in which they were sent, based on connection-oriented service. In terms of the TCP/ IP suite, this function is performed by the TCP protocol. Other kinds of transport protocols transport isolated messages with no guarantee (best-effort type) about the order of delivery or the broadcasting of messages to multiple destinations. This type of connection is connectionless, and in terms of the TCP/IP suite, it is performed by the UDP. The transport header carries information on what message belongs to which process, thus providing multiplexing for the processes. Also, there is a mechanism to regulate information ow, so that a fast host cannot overrun a slow one. Flow control between hosts is distinct from ow control between switches, although similar principles apply to both. The session layer enables users on different machines to establish sessions between them. A session allows a user to log into a remote time-sharing system or to transfer a le between two machines. One of the services of the session layer is dialogue control. Sessions can allow trafc to ow in both directions at the same time, or in only one direction at a time. If trafc can only go one way at a time, the session layer helps to keep track of whose turn it is. A related session service is token management. For some protocols, it is essential that both sides do not attempt the same operation at the same time. To manage these activities, the session layer provides tokens that can be exchanged. Another session service is synchronization, which inserts checkpoints into the data stream and ensures that after excessive data transfer, if the session has been interrupted, only the data after the last checkpoint is repeated. Another example here can be when one application process requests access to another applications process (e.g., Microsoft Word importing a chart from Excel). The presentation layer performs functions to ensure consistent syntax and semantics of the transmitted information. It deals with syntactic representation of data, such as agreement on character code (ASCII, extensions to ASCII, Unicode); .doc, .txt, .gif, and .jpg formats; datacompression and data-encryption methods, and representations of graphics (such as les using the .pic or .bmp formats). The presentation layer is also concerned with other aspects of information representation. For example, data compression can reduce the number of bits to be transmitted, and cryptography is frequently required for privacy and authentication. The application layer deals with data generation and contains a variety of protocols that are commonly needed, such as terminal emulation based on virtual terminal software. Another application layer function is le transfer because different le systems have different naming conventions and ways of representing text lines. Transferring a le between two different systems requires handling these and other incompatibilities. Each layer of the OSI model receives data from the layer beneath it and provides service for the layer above it. The exchange of information between layers is based on protocol data units (PDUs) and the encapsulation of the user data occurs in every layer. Therefore, every layer adds extra information (headers and trailers) to perform its functions.
100
In reality, data is passed from one layer down to the next lower layer at the sending computer, until the physical layer nally transmits it onto the network cable. As the data is passed down to a lower layer, it is encapsulated into a larger unit because additional layer information is added. At the receiving end, the message is passed upwards to the desired layer, and as it passes upwards through each layer, the encapsulation information is stripped off. As an industry standard, OSI is a framework that every new product complies with because it is already accepted and widely adopted. A variety of other specications, including IEEE (www.ieee.org), RFC (www.ietf.org/rfc.html), Asynchronous Transfer Mode (ATM) Forum (www.atmforum.org), DSL Forum (www.dslforum.org), and the Internet Engineering Task Force (www.ietf.org) create sublayers and dene different model structures. It is important to remember the denition of the communication subsystem (see Figure 4-2) that includes up to the rst three OSI layers, because it is the main focus of remote access troubleshooting.
Figure 4-2 The Open System Interconnection (OSI) Model, Including Some of the Related Protocols and the Communications Subsystem
E-Mail User Agent E-Mail Msg Transfer
Application Layer
Routing Protocols IGP
Real-Time Multimedia
IP Addr. Assgn.
Network Mgmt.
Directory Services
Host Session
File Transfer
WWW
Newsgroup Messaging
Routing Protocols EGP
Codec
ASN.1
DNS Text
Text Stream
Binary
WWW Binary
News Binary
Text Binary
Text Binary
Presentation Layer
SDP RTP SIP DHCP
SNMP Msg.
DNS Msg.
ASCII
File Path
File Path
ASCII UUC
ASCII UUC MME
SMTP Msg.
RIP RTSP
RTCP
SNMP
DNS
Telnet
FTP
HTTP
Usenet
POP
SMTP
BGP
Session Layer
Port No.
520
554
5005 5004 5060
67 68 UDP (17)
161 162
53
23
20 21
80
532
109 110
25
179
Transport Layer
(Protocol ID)
UDP TCP (17) (6) OSPF (89)
TCP (6) ICMP (1) IGMP (2) RSVP (46)
Network Layer
(Type in Hex)
ARP [0806]
IP (v4 or v6) [0800]
Link Layer Physical Layer
802.2 802.3...802.15 PPP, SLIP, HDLC, PPoE X.25
Frame Relay
FUNI
AAL5 ATM, PPoA
SONET
ISDN
xDSL
Analog Modem
X.21
T1 DS3
ADSL T1 DS3
T1, DS3 Sonet, MMF
Communication Subsystem
Troubleshooting Models and the Baseline
101

The purpose of every troubleshooting model is to nd a common denominator for all possible issues and to offer a common approach or problem-solving model. The objective is to represent (reduce) a complex problem into a couple or even one point of failure, and then to restore the functionality of the whole system. You are faced with the question: which is better, analysis or synthesis?
Troubleshooting Models
There is more than one Cisco troubleshooting model dened in numerous books and conferences. One such model is dened in the book Cisco Internetwork Troubleshooting (by Laura Chappel and Dan Farkas, Cisco Press, 1999), where an eight-step problem solving model is recommended. Some of the commonly accepted troubleshooting steps and tips, recommended by the Cisco troubleshooting society, are available on Cisco.com. Some of the more relevant practices from these resources follow. The following are basic troubleshooting steps:
1 Identify how it should work. 2 Review your topology. 3 Identify the symptoms. 4 Ask the right questions. 5 Develop a plan of attack. 6 Document your actions.
NOTE
My experience when troubleshooting is, if you understand the design and conguration of the network, gathering the right information is key to nding a resolution. Knowing the baseline performance of the network and asking the right question is 50 percent of the solution.
The following are basic troubleshooting tips:
Dont panic. Understand your network. Develop network baselines. Gather the right information from your users. Work methodically and document all of your actions.
102
Learn how to effectively use tools. Figure out what tools and what options work best for each problem. Use access lists when enabling debug commands.
Based on the sources, many nd common ground in the actions of understanding the baseline and topology, gathering information, asking the right questions, learning tools, implementing solutions, and documenting changes. These are the main steps of the troubleshooting process. Later in the discussion, you learn about some common and some Cisco-specic troubleshooting tools (Cisco IOS-based), which are designed to alleviate the process.
IOS Commands You should assume that all troubleshooting techniques described in this book are Cisco IOS-based. Despite your expertise in IOS, remember that IOS is constantly developing. The syntax of IOS is multioptional and sometimes can be complex. You must continue to study IOS on a regular basis and keep apprised of changes. One of the best sources for information is Cisco IOS Releases: The Complete Reference by Mack Coulibaly (Cisco Press, 2000), and the Cisco software center at www.cisco.com/public/sw-center/.
Short Format (Truncation) of IOS Commands Typing the full version of commands is rare in Cisco-based troubleshooting. For example, most engineers wont type show running-cong. Instead, they simply type show run or even sh run. Using such truncated commands can help you save time. Become familiar with the short form of commands so that you can work quicker and understand when others use them. A review of IOS terminology and commands at www.cisco.com is highly recommended.
Device Abbreviations Used in This Book The abbreviations in this book about the devices and technologies are developed to be selfexplanatory. For example, 5300-Dial means Cisco Access Server 5300 for dial, 804-isdn means Cisco 804 ISDN router for remote user, and 1602-frame means Cisco 1602 router for Frame Relay service.
There is no universal troubleshooting tool. The choice of the right tool depends on your hands-on experience. Every tool provides information for one or more aspects of the
103
network, and it is good practice to use several or a combination of tools in the troubleshooting process. Nevertheless, some tools related to issues such as latency measurement, performance measurement, or reach ability of a certain hop can provide more common results. Some issues, such as how to measure the performance of the network, have more than one answer, and it is recommended to apply a comparative approach whenever possible. If it is possible to use the same tool (i.e., the ping utility), compare the results obtained from different technologies or segments of the network.
The Baseline
The baseline is the expected behavior of the system that you are about to troubleshoot. The baseline is an important factor, but it is hidden in the beginning of the troubleshooting process. In general, the baseline includes performance characteristics, number and type of hops, and expected round-trip times (RTTs). It might include some yes or no questions, such as compression, multicast, Voice over IP (VoIP), quality of service (QoS), and so on. The baseline should be technology and architecture based. You should set expectations before starting the troubleshooting process. One key factor is to have a map of the network topology. The following sections discuss aspects of the network baseline and tools for helping you establishing the baseline.
Network Topology
At a minimum, you need to have a documented network topology. For Internet connections, Internet service providers (ISPs) apply different methods to prevent end users from discovering the topology, assuming that this is one of the rst steps in preventing denial of service (DOS) attacks from hackers. One recommended tool to discover the network topology is to run the Cisco Discovery Protocol (CDP). CDP is a Cisco proprietary protocol that runs on the data link layer (Layer 2) between directly connected and adjacent devices (neighbors), including routers, bridges, switches, access servers, and virtually all Cisco IOS devices. CDP works not only for IOSbased, but non-IOS devices such as IP phones and Aironet access points (APs). CDP is enabled by default on all broadcast interfaces. It is useful for debugging connectivity issues and building topology maps. The high-level data link control (HDLC) protocol type 0x2000 is assigned to CDP. It uses a second layer multicast Media Access Control (MAC) address 01-00-0C-CC-CC to send and receive periodic messages and to collect data. Using a multicast address prevents the routing because Cisco routers and some switches do not forward this trafc unless specically congured. If any information has changed since the last packet was received, the new one is cached, ignoring the Time To Live (TTL) value. In this way, CDP provides a quick state discovery. The recommended commands for topology discovery are as follows:
Router#show cdp neighbors Router#show cdp neighbors detail
104
The output from these commands returns specic details including device type, IP address, active interface (Ethernet, serial), port type, and port number. The rst command provides short output, and the second command provides detailed information about adjacent topology specics, as shown in Example 4-1.
Example 4-1 The show cdp neighbors detail Command Output
Router#show cdp neighbors detail <output omitted> Device ID: access-gateway.cisco.com Entry address(es): IP address: 10.10.0.7 Platform: cisco Catalyst 6000, Capabilities: Router Switch IGMP Interface: FastEthernet0/0, Port ID (outgoing port): FastEthernet3/21 Holdtime : 136 sec Version : Cisco Internetwork Operating System Software IOS (tm) c6sup1_rp Software (c6sup1_rp-JK2SV-M), Version 12.1(8b)E9, Copyright 1986-2002 by cisco Systems, Inc. Compiled Sun 17-Feb-02 11:22 by erlang advertisement version: 2 VTP Management Domain: Native VLAN: 10 Duplex: full <output omitted>
Extensive information from the CDP output requires the CDP to be disabled in interfaces that cannot be controlled or that are user-owned or requested, such as dialer interfaces. To disable the CDP on a dialer interface, the following command has to be congured:
Router(config-if)#no cdp enable
Another source of topology information can be the routing protocol. All routing protocols support information for their neighbors, and link-based routing protocols, such as Open Shortest Path First (OSPF) and Enhanced Interior Gateway Routing Protocol (EIGRP), support topology information. As soon as all members are running routing protocols (instead of static routing), these commands can be informative. Information for neighbors is usually more concise. The following command is an example:
Router#show ip eigrp neighbors detail
The topology output is usually detailed and relatively complex. It is not discussed in this book. It is up to you to know what type of information is required and what topology command to use.1 It is common for a consulting engineer to start troubleshooting in a new environment where the topology of the network is not available. Tools used in combination, such as telnet,
105
ping, cdp, and traceroute commands, produce information that can create a network topology before starting the troubleshooting process. Overall, the collected baseline information provides you not only with topology information, but also with IOS versions, types of devices, IP addressing conventions, and both routed and routing protocols.
Performance Characteristics and Path Characteristics

The baseline is related to the expected behavior of the system, including performance characteristics, latency, and expected RTTs. A useful and multioptional tool for establishing baseline performance is the path characteristics (PathChar or Pchar) utility. Pchar is designed to baseline the network performance. The utility enables you to stress test each hop and provides the ability to collect detailed information. It is based on the path characterization model of Van Jacobson. Pchar measures network performance on a perhop and a total path basis. It supports IPv4 and IPv6, and it is useful in isolating performance problems. Some of the drawbacks are that the latency gures might not be accurate when measuring application performance, and Internet Control Message Protocol (ICMP) messages can be ltered or respond differently (typical in the case of satellitebased connections). The utility runs on UNIX, Linux, and Solaris platforms. The options are listed in Table 41. The following shows the usage of Pchar:
UNIX-host:/users/pnedeltc> ./pchar Usage: ./pchar [-a analysis] [-b burst] [-c] [-d debuglevel] [-g gap] [-G gaptype] [-h] [-H hops] [-I increment] [-m mtu] [-n] [-p protocol] [-P port] [-q] [-R reps] [-s hop] [-t timeout] [-T tos] [-v] [-V] [-w file] -r file | host]
Table 4-1
Path Characteristics (Pchar) Options Pchar Option -a Description AnalysisSet analysis type (default is lsq): lsqLeast sum of squares linear t kendallLinear t using Kendalls test statistic lmsLeast median of squares linear t lmsintLeast median of squares linear t (integer computations) -b -c -d -g Burst size (default is 1) Ignore route changes (useful for load-balancing situations) Debug levelSet debugging output level GapInter-test gap in seconds (default is 0.25) continues
106
Table 4-1
Path Characteristics (Pchar) Options (Continued) Pchar Option -G Description Gap typeInter-test gap type (default is xed): xedFixed gap expExponentially distributed random -H -h -I -l -m -M HopsMaximum number of hops (default is 30) Print this help information IncrementPacket size increment (default is 32) HostSet origin address of probes (defaults to hostname) Maximum transmission unit (MTU)Maximum packet size to check (default is 1500) ModeOperational mode (defaults to pchar): pcharPath characteristics troutTiny traceroute -n -p Dont resolve addresses to hostnames ProtocolNetwork protocol (default is ipv4udp). Species the protocol that Pchar uses: ipv4udp (default) ipv4raw ipv4icmp ipv4tcp ipv6icmp ipv6udp -P -q -r -R -s -S -t -T -v -V -w le PortStarting port number (default is 32768) Quiet output FileRead data from a le (- for stdin) RepsRepetitions per hop (default is 32) HopStarting hop number (default is 1) Do Simple Network Management Protocol (SNMP) queries at each hop to determine the nexthop interface characteristics TimeoutICMP timeout in seconds (default is 3) Type of service (ToS)Set IP ToS eld (default is 0) Verbose output Print version information Write data to le (- for stdout)
107
Table 4-2 shows some performance measurements from Cisco users of different technologies in the U.S. that connect to the corporate network.
Table 4-2 Pchar and a Baseline Measurement Technology Dial ISDN Frame (FT1) Frame (56K) Asymmetric DSL (ADSL) Speed 56 kbps 128 kbps 128 kbps 56 kbps ~ 600 kbps down ~ 250 kbps up StarBand Satellite ~ 600 kbps down ~128 kbps up Cable Modem Sprint BroadBand 10 Mbps ~ 500 kbps down ~ 128 kbps up Ethernet Fiber Distributed Data Interface (FDDI) T1 T3 OC-3 OC-12 10 Mbps 100 Mbps 1.54 Mbps 45 Mbps 150 Mbps 622 Mbps 1.2 ms 120 us 4.5 ms 267 us 80 us 19 us ~ ~ 1509 kbps ~ ~ ~ 13.6 ms 76.6 ms 7912 kbps 720 kbps 813.5 ms 42 kbps RTT 125.6 ms 22.8 ms 13.8 ms 61.2 ms 11.6 ms Path Bottleneck 31 kbps 118 kbps 118 kbps 52.8 kbps 568.5 kbps
Usually, the bottleneck is at the last hop in the test, but not always. In the following examples (see Figure 4-3 and Example 4-2), the Cisco 350 AP is connected to an 804 ISDN router, which in turn is calling a 7206VXR core router. A Microsoft Windows 2000 laptop (IP: 161.70.209.86) is associated with the AP (IP: 161.70.209.82), and the speed between them is 11 Mbps.
108
Figure 4-3
Functional Model for Bottleneck Discovery
The Pipe
The Bottleneck
11 Mbps
10 Mbps
128 kbps
100 Mbps
CO
IP = 10.70.209.81
CO
IP = 10.71.86.86
IP = 10.70.209.86
ISDN Cloud
AP 350 - IP 10.70.209.82
UNIX-Host:/users/ pnedeltc> CO
IP = 10.70.192.243
Example 4-2 Pchar Discovers a Bottleneck

UNIX-host:/users/pnedeltc> ./pchar -p ipv4icmp -v -R 3 -s 8 10.70.209.86 -p protocol ipv4icmp; -v verbose; -R-3 repetitions per hop; -s starting from hop 8 pchar to 10.70.209.86 (10.70.209.86) using ICMP/IPv4 (raw sockets) Using raw socket input Packet size increments from 32 to 1500 by 32 46 test(s) per repetition 3 repetition(s) per hop 7: 10.71.86.86 (UNIX-Host) Partial loss: 0 / 138 (0%) Partial char: rtt = 1.359319 ms, (b = -0.000003 ms/B), r2 = 0.000210 stddev rtt = 0.021433, stddev b = 0.000027 Partial queueing: avg = 0.000052 ms (0 bytes) 8: 10.70.192.243 (Cisco-isdn.cisco.com) Partial loss: 0 / 138 (0%) Partial char: rtt = 25.581711 ms, (b = 0.072820 ms/B), r2 = 0.999766 stddev rtt = 0.135654, stddev b = 0.000168 Partial queueing: avg = 0.029341 ms (402 bytes) Hop char: rtt = 24.222391 ms, bw = 109.855819 Kbps Hop queueing: avg = 0.029288 ms (402 bytes) 9: 10.70.209.81 (pnedeltc-isdn.cisco.com) ! 6% loss: Partial loss: 9 / 138 (6%) Partial char: rtt = 25.566884 ms, (b = 0.075063 ms/B), r2 = 0.999448 stddev rtt = 0.387928, stddev b = 0.000276 Partial queueing: avg = 0.029208 ms (402 bytes) Hop char: rtt = --.--- ms, bw = 3566.545092 Kbps Hop queueing: avg = -0.000133 ms (0 bytes)
Common and Cisco-Specic Tools
109
Example 4-2 Pchar Discovers a Bottleneck (Continued)

The connection between 10.70.209.81 and 10.70.209.86 is wireless 11 Mbps. 10: 10.70.209.86 (pnedeltc-isdn5.cisco.com) Path length: 10 hops Path char: rtt = 25.566884 ms r2 = 0.999448 ! This bottleneck matches the bandwidth of ! the core router 7206-isdn (see step 8): Path bottleneck: 109.855819 Kbps Path pipe: 351 bytes Path queueing: average = 0.029208 ms (402 bytes) Start time: Fri Dec 21 07:48:33 2001 End time: Fri Dec 21 07:51:43 2001 executor:/users/pnedeltc>
The Pchar is run from 10.71.86.86 towards 10.70.209.86 with the options -p protocol ipv4icmp; -v verbose; -R-3 repetitions per hop; -s starting from hop 8. Because of conguration options, the utility performs an initial reachability test and assigns hop 7 to the source (IP: 10.71.86.86), hop 8 to the core ISDN router (IP: 10.70.192.243), 804 ISDN router (IP: 10.70.209.81), and reaches the nal hopCisco AP 350 (IP: 10.70.209.86). The interesting spots are the level of lossabout 6 percent in hop 9 and the comparison between hop 8 and the last report, where the bottleneck is discovered to be at hop 8see the message bw = 109.855819 kbps.
NOTE
In Example 4-2, you can see stddev rtt = 0.387928. This measurement is the standard deviation of the RTT. The standard deviation is the most commonly used measure of the spread. The calculation is based on variance, mean, and standard deviation. If the RTT = 1, 2, 3, the variance is = [(1 2)2 + (2 2)2 + (3 2)2] /3 ~ 0.667, and 2 is the mean. The standard deviation is the square root of the variance, which in this case, is 1/2 ~ 0.816.
The Pchar utility has two limitations: the utility has difculties when the hop is a multipath type and when there are transparent hops because of bridges or ATM links on the path.

A variety of tools are available under different platforms. It is worthwhile to explore each of them, and to create a set of pros and cons for each one. This type of research is worth a separate book. One possible approach to classify all tools is the following:
Network monitoring tools such as local-area network (LAN) and wide-area network (WAN) analyzers and sniffers, such as Sniffer Pro from Network Associates or EtherPeek. Remote control software, such as pcAnywhere from www.symantec.com, or Virtual Network Computing (VNC) software, which is used widely throughout the industry.
110
Simulative equipment and software. Usually new solutions require lab environment testing before testing in production. The same logic applies to some unique problems when you need to recreate the problem and test the resolution prior to implementing any solution. A convenient tool for this purpose is a hardware simulator. ADTRAN Inc. (www.adtran.com) offers a comprehensive line of WAN test equipment that enables quick and economical deployment of ber, T3, DSL, T1, E1, Frame Relay, VPN, ISDN, Digital Data Service (DDS), and wireless digital networks. Some of the best troubleshooting tools, such as Output Interpreter (www.cisco.com/ support/OutputInterpreter/parser.html), are available and updated at Cisco.com.
Network analyzers and sniffers are extremely useful when troubleshooting data link layer and network layer issues such as frame formats, segmentations, and access control lists. (For more information, see Chapter 13, Troubleshooting Scenarios for ISDN BRI.) Remote control software can be particularly useful for troubleshooting some applications when basic connectivity is available so that you can see what remote users see on their screen. Simulators and software that recreates the problem are recommended tools for the preproduction environment or for the pilot stage of the deployment of new products or services. Each of the tools listed here requires some investment and it is up to you to dene the purpose for each tool and to learn to use it effectively. A common set of tools is widely available for UNIX, Microsoft, and Cisco platforms that can be used for basic troubleshooting. Some of the more common tools are listed in the following sections.
Ping and Privileged (Extended) Ping Commands

These commands are available for Cisco, Microsoft, and UNIX platforms. The ping utility can determine basic connectivity. It is based on the specications for RFC 1256 and RFC 791. Ping is assigned a low priority. It is not an indicator of performance, and it is not used for other more sophisticated tests. During a ping test, the host sends an ICMP echo packet and receives a reply ICMP message if basic connectivity exists.
NOTE
An ICMPv6 is available for the IPv6 protocol (see RFC 1885).
The IOS-based ping can be used in two modes: user mode and ping EXEC mode (or Privileged Ping). The user mode ping command is for users who do not have privileged mode access to the device. The command syntax is as follows: | address] The protocol option allows you to dene several options such as IP, source-route bridging (SRB), and tag. Only the non-verbose form is available, and if the host address can be resolved by the Domain Name System (DNS) server, the ping command returns !!!!!. If it
Router>ping [protocol] [host
111
cannot be resolved by DNS, the host returns ...... If it fails, it is always a good idea to try to ping by IP address and bypass possible DNS issues. The command returns success rate in percent and RTT in minimum, average, and maximum. For example, if you see a RTT value equal to 50 ms, 500 ms, and 5 seconds, your next questions is: Is this what I should expect, or is this far from the baseline? These questions can be answered by using ping and knowing the topology of the network, the baseline, the expected performance characteristics, and the way that the trafc is carried (local exchange carriers [LECs], inter-exchange carriers [IXCs], local loop, and if it is dial, ISDN, Frame Relay, or any other technology). As an example, for satellite-based VPN connections, 0.7 seconds RTT is what you should expect; however, this RTT is unacceptable for Frame Relay. The extended ping is much more useful and interesting for troubleshooting. The command provides a variety of options for protocols such as IP, Internetwork Packet Exchange (IPX), AppleTalk, Connectionless Network Service (CLNS), Digital Equipment Corporation net (DECnet), Virtual Integrated Network Service (VINES), and Xerox Network Systems (XNS). The results can be interpreted differently (see Example 4-3).
Example 4-3 Example of Extended Ping to 10.68.10.70
Router#ping Protocol [ip]: Target IP address: 10.68.10.70 Repeat count [5]: 100 Datagram size [100]: 3000 Timeout in seconds [2]: 3 Extended commands [n]: y Source address or interface: Type of service [0]: Set DF bit in IP header? [no]: Validate reply data? [no]: Data pattern [0xABCD]: 0x0000 Loose, Strict, Record, Timestamp, Verbose[none]: Sweep range of sizes [n]: Type escape sequence to abort. Sending 100, 3000-byte ICMP Echoes to 10.68.10.70, timeout is 3 seconds: Packet has data pattern 0x0000
The rst important consideration is the ability to modify the repeat count (the default is 5), datagram size, and the timeout period (the default is 2). A higher number of ICMP echoes creates trafc for a longer period of time, and combined with the increased size of the packet (3000 bytes), allows you to test Point-to-Point Protocol (PPP), Multilink PPP (MPPP), and Multichassis Multilink PPP (MMP) (see Part II, Dial, and Part III, ISDN, for more detail on PPP, MPPP, and MMP) for dialup or ISDN connections, and for thresholds, reliability, txload, and rxload in some interfaces. It is rare to receive a timeout greater than two seconds in wired networks; however, the option is available and can be used accordingly in a wireless environment. One indicator for successfully running compression over a WAN connection is a non-proportional increase in RTT, when you
112
increase the packet size following every test. This is based on the fact that the compression ratio is not a linear function of the packet size. RFC 791 denes different types of reports that can be used to analyze connectivity issues. The reports are Loose, Strict, Record, Timestamp, and Verbose, and are based on the content of the IP packet. The same is true for TOS parameters and for setting the fragmentation bit. The latter plays a signicant role in some connectivity issues and MTU issues in VPN solutions. This, combined with the sweep range of sizes, automatically modies the packet size and determines the minimum MTU in the path. More about MTU is discussed in Chapter 21, Remote Access VPN Troubleshooting. Regarding data patterns, in some instances, it is not appropriate to use the Cisco standard 0xABCD sequence because some connectivity tests are much more productive based on certain specics of the technology. In T1 and Primary Rate Interface (PRI) connectivity issues, the ones density requirement requires a certain number of 1s to be available. Their absence is referred to as a loss of signal (LOS) (see Chapter 3, The Cloud). Running 0x0000 or 0xffff provides more information than a standard Cisco sample. Another example for the same purpose is 0xAAAA, 0xA5A5, and 0x4040. Because of the specics of T1 lines, it is recommended that you use the 0x0000 pattern for testing. Long series of 0s are indistinguishable from LOS (see Chapter 3 and Chapter 7, Dial Troubleshooting), so if the T1 is functional, a zero-insertion procedure is in effect (see Part IV, Frame Relay). 0xFFFF helps to localize repeater power problems, and 0x4040 is recommended for timing problems. It is also recommended to use different patterns when testing the compression ratio in a lab environment because of the deciencies in the standard 0xABCD pattern. In general, ping returns the following replies:
NOTE
.Timed out; waiting for reply !Reply received UDestination unreachable NNetwork unreachable PProtocol unreachable QSource quench MCould not fragment ?Unknown packet type
ICMP type messages are listed in Table 4-3. When the ICMP type is 3 (destination unreachable), the ICMP codes identify the failure. The failures are dened in Table 4-4.
113
Table 4-3
ICMP Type Messages and Descriptions ICMP Type Message 0 3 4 5 8 11 12 13 14 15 16 17 18 Description of ICMP Types Echo Reply Destination Unreachable Source Quench Redirect Message Echo Request Time Exceeded Parameter Problem Timestamp Request Timestamp Reply Information Request (No Longer Used) Information Reply (No Longer Used) Address Mask Request Address Mask Reply
Table 4-4
ICMP Codes When the ICMP TYPE Is 3Destination Unreachable ICMP Codes for the ICMP Message Type = 3Destination Unreachable 0 1 2 3 4 5 6 7 8 9 10 11 12 13 Description Network unreachable Host unreachable Protocol unreachable Port unreachable Fragment needed and Dont Fragment (DF) bit set Source route failed Network unknown Host unknown Source Host isolated Communication with destination network is administratively prohibited Communication with destination is administratively prohibited Bad type of service for destination network Bad type of service for destination host Administratively blocked by lter
114
Ping tests the end-to-end connectivity, but if the ping fails, it does not provide you with information on where the possible problem exists. The hop-by-hop information is available in the traceroute command, which in a sense extends pings functionality.
The Traceroute and Privileged (Extended) Traceroute Commands

Available as traceroute in Cisco and UNIX based-platforms, and tracert in Microsoftbased platforms. The traceroute (Cisco/UNIX) and tracert (Microsoft) commands differ slightly. Cisco/UNIX uses UDP packets, and Microsoft uses ICMP packets, which are more likely to be ltered. The traceroute command tests the connectivity of the path between two devices (hops). It narrows down connectivity issues, helps to discover routing loops, and determines baseline network layer performance on a hop-by-hop basis.
NOTE
The traceroute command is considered a baseline tool. This suggestion is not exactly correct because every router contains links, switching-forwarding engines, and queues. The mathematical model for traceroute does not consider the queues that are typical for every hop when there is competing trafc. This is why it is more precise to refer to traceroute as a hop-discovery tool.
The traceroute mechanism is based on the TTL eld of an IP packet. This eld is initialized by the sender. If the eld is decremented to 0, the packet is discarded and an error indication packet (an ICMP time exceeded) is sent back to the sender. The source address of the ICMP error packet identies the hop that discarded the data packet. This is the mechanism that identies every hop. The sending host sets the TTL initially to 1. Every hop in the path decreases the TTL by 1. So for the rst hop in the path, the TTL is decreased by 1, and because TTL now equals 0, the error message containing the hop information packet is sent back to the sender. The source then increases the TTL to 2, and after two hops it is sent back. The sender now tries using 3, and so on. The traceroute repeats itself until the command terminates when either the host is reached, the escape sequence (Ctrl-Shift-^) is triggered, the TTL reaches 30 (default TTL for Cisco), or the TTL exceeds the set amount. If the timer goes off before the response from the probe packet is back, the symbol * is displayed. The traceroute command can be used with the following protocols:
clns ip ipx oldvines vines ISO CLNS Trace IP Trace IPX Trace Vines Trace (Cisco) Vines Trace (Banyan)
The privileged traceroute command offers some additional features, as shown in Example 4-4.
115
Example 4-4 The Privileged traceroute Command

router#traceroute Protocol [ip]: Target IP address: 10.68.10.70 Source address: 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.
The options are self-explanatory and a detailed description of expected output from this command is listed in Table 4-5.
Table 4-5 Traceroute Output Description Output nn msec * ? Q P, N, U, H Description of the Output RTT in ms for each number of probes Probe TTL expired Unknown packet type Source quench Protocol, network, port, host unreachable
The Netcat Utility

The Netcat utility takes advantage of the fact that telnet cannot test UDP connections, but Netcat can. It offers better functionality than telnet and can be used as a replacement because it does not inject too much data into the network. It can also test application connectivity and it is available in UNIX and Microsoft platforms. The following are some of the options of the Netcat utility for the Microsoft NT platform (see Table 4-6):
C:\cisco\pnedeltc\tools\netcat>nc -h [v1.10 NT] connect to somewhere: nc [-options] hostname port[s] [ports] ... listen for inbound: nc -l -p port [options] [hostname] [port] options:
116
Table 4-6
Netcat Utility Options for Windows NT 4.0 and Windows 2000 Netcat Option -d -e -g -G -i -I Description Detach from console, stealth mode. Execute inbound program. Gateway; source-routing hop point(s), up to 8. Number for source-routing pointer: 4, 8, 12, .... Delay interval in seconds for lines sent, ports scanned. Causes Netcat to listen to a given port (as specied with the p Flag); this option is useful for creating mock services to test throughput or connectivity; use with the u ag to create a UDP server. Listen mode, for inbound connects. Listen harder; relisten on socket close. Numeric IP address. Hex dump of the trafc. Local port number; when Netcat is run with the -I ag, use the specied port and IP address respectively. Randomize local and remote ports. Local source address; when Netcat is run with the -I ag, use the specied port and IP address respectively. Answer TELNET negotiation. UDP mode; tell Netcat to use UDP instead of TCP; Netcat simulates a UDP connection. Verbose (use twice to be more verbose). Timeout for connects and nal net reads in seconds; changes the network inactivity timeout; changing this to at least 3 is useful when checking web or gopher services. ZeroInput/Output (I/O) mode (used for scanning).
-l -L -n -o -p -r -s -t -u -v -w
-z
Port numbers can be individual or a range: m-n (inclusive). A simple example of using Netcat is to pull down a web page from a web server. With Netcat, you see the full HTTP header to see what web server a particular site is running. The command line is as follows:
C:\cisco\pnedeltc\tools\netcat>nc -v www.website.com 80 < get.txt
Netcat makes a connection to port 80, sends the text contained in the le get.txt, and provides the web servers response to stdout. The -v stands for verbose.
117
Another combination is the -l or listen option and the -e or execute option that instructs Netcat to listen on a particular port for a connection. When a connection is made, Netcat executes the program of your choice and connects the stdin and stdout of the program to the network connection.
C:\cisco\pnedeltc\tools\netcat>nc -l -p 23 -t -e cmd.exe
The telnet equivalent here is as follows:

C:\cisco\pnedeltc\tools\netcat>nc 110.71.87.84 23
You can listen on any port that gives you an opportunity, even to determine if the rewall you might be behind lets port 53 through. To run Netcat listening behind the rewall on port 53, use the following:
C:\cisco\pnedeltc\tools\netcat>nc -L -p 53 -e cmd.exe
Then from outside the rewall, connect to the listening machine by using the following command:
C:\outside\pnedeltc\tools>nc -v 10.71.87.84 53
The extended set of features for different platforms is widely available over the Internet. This particular version was written by Weld Pond (weld@l0pht.com).
Service Assurance Agent

A sophisticated Cisco IOS-based tool is available in IOS versions 12.2 or higher. The Service Assurance Agent (SAA) feature replaces the Response Time Reporter (RTR) in earlier IOS versions and provides extra capabilities such as VoIP metrics, response time, availability of HTTP (port 80) applications, and QoS based on the precedence eld of the IP packet. The feature allows you to monitor network performance between a Cisco router and a remote device, which can be another Cisco router, an IP host, or a mainframe host, by measuring key Service Level Agreement (SLA) metrics such as response time, network resources, availability, jitter, connect time, packet loss, and application performance. SAA enables you to perform troubleshooting, problem analysis, and notication based on the statistics collected by the SAA. Example 4-5 shows a sample using IOS 12.2(6) that is conguring the HTTP trafc monitoring to www.cisco.com, and scheduling the data collection.
Example 4-5 SAA Sample
Router#conf t Enter configuration commands, one per line. End with CNTL/Z. Router(config)#rtr 1 Router(config-rtr)#type http operation get url http://www.cisco.com Router(config-rtr)#exit Router(config)#rtr schedule 1 start-time now Router(config)#^Z Router#wr
continues
118
Example 4-5 SAA Sample (Continued)

Router#show rtr collection-statistics Collected Statistics Entry Number: 1 HTTP URL: http://www.cisco.com Start Time: *00:15:04.000 UTC Mon NOV 1 2001 Comps: 0 OvrTh: 0 DNSTimeOut: 0 TCPTimeOut: 0 TraTimeOut: 0 DNSError: 0 HTTPError: 0 IntError: 8 RTTMin: 0 RTTMax: 0 RTTSum: 0 RTTSum2: 0 DNSRTT: 0 TCPConRTT: 0 TransRTT: 0 MesgSize: 0
It is recommended to place the SAA in strategic areas of your network (in the core or distribution layer) to ensure monitoring and to receive performance metrics for the network functionality. The SAA feature provides an extended set of #show and #debug features.
The IOS Commands show and debug

The #show and #debug features of the IOS are the main Cisco-specic tools that have to be continually learned by troubleshooting engineers to obtain the maximum available information from the devices. Cisco dened seven severity levels of report of certain events in Cisco routers. One important point here is to understand that by default the #debug command provides information for a certain severity level and higher. The default severity level can be changed with the command in Example 4-6.
Example 4-6 Changing the Default Severity Level
804-isdn(config)#logging console ? <0-7> Logging emergencies System is unusable alerts Immediate action needed critical Critical conditions errors Error conditions warnings Warning conditions notifications Normal but significant conditions informational Informational messages debugging Debugging messages guaranteed Guarantee console messages severity level (severity=0) (severity=1) (severity=2) (severity=3) (severity=4) (severity=5) (severity=6) (severity=7)
Review Questions
119
The #show and #debug commands are widely used in the troubleshooting process. Another important preliminary rule for the #debug command is that when debugging, some of the debug commands have chatty output and if mishandled, can crash the router. You can even cancel the terminal monitoring with Router#terminal no monitor, but this does not cancel the debug process. It is recommended that you open a secondary session (Telnet, Secure Shell [SSH]) to the same router and prepare to cancel the debugging with the shortest command you know. Remember that some debug commands can be used only if the utilization is low (use #show processes cpu [history] command), or in a non-production environment. These commands are widely described in the following chapters to demonstrate some of the most common and recommended Cisco tools for a remote access environment.
End Notes
1Retana,
Slice, and White. Advanced IP Network Design (CCIE Professional Development). Cisco Press, 1999.
Summary
This chapter focused on troubleshooting models, tools, and approaches. You should be familiar with this preliminary information before you approach the technology-specic troubleshooting covered in the following parts of this book. Part of the discussion was about layered interconnection models because the following discussion in the book is based on the layer-by-layer troubleshooting model, starting from Layer 1. You have learned about baseline, performance characteristics, and some common and Cisco-specic troubleshooting tools. The PathChar utility, NetCat utility, and SAA of Cisco are discussed in more detail and are recommended for different aspects of the troubleshooting process.
Review Questions
1 What is the name of the layer above the network layer in the DoD model? 2 Name at least one keyword for each of Layer 2, Layer 3, and Layer 4 of the OSI
model.
3 What is the communication subsystem in the seven-layer OSI model? 4 What is the baseline of the system? 5 Name at least ve of the key concepts in the troubleshooting process.
120
6 What are the complete and the shortest IOS commands to save the running
conguration to the NVRAM?

7 What are the complete and the shortest IOS commands to cancel all debugging in the
router?
8 Why does the CDP use a multicast address? 9 When troubleshooting the serial interface, you see HDLC protocol type 0x2000, what
is it?
10 Is it recommended that you disable the CDP over the dialer interface? If so, what is
the command?
11 What is the measurement of the spread when measuring the path characteristics with
Pchar?
12 What does ICMP type 3 mean? 13 What is the command to see the statistics when using Service Assurance Agent
(SAA)?
PART
II
Dial
Chapter 5 Dial Technology Background Chapter 6 Dial Design and Conguration Solutions Chapter 7 Dial Troubleshooting Chapter 8 Dial Troubleshooting Scenarios
CHAPTER
Dial Technology Background

Dial is an essential part of remote access infrastructures because it is one of the easiest means by which a traveling user can obtain network access. For connectivity at home, in most cases, it provides the cheapest form of Internet access. Dial also provides an inexpensive, reliable backup solution when broadband alternatives are not available because of circuit outages or maintenance windows. Dialup networking seems simplistic in terms of how it works. The steps to establish a connection include modem train-up, authentication, and establishment of a Point-to-Point Protocol (PPP). After you complete these steps, you have a PPP connection from client to server, which allows you to pass trafc. The difcult part of dialup networking is overcoming its limitations to get the best possible connection speed and the most stable connection. Dial is a technology that everyone has at their ngertips, but it is limited in certain areas because of the telephone company (telco) infrastructure. This chapter covers some of the details regarding dial and its limitations. It also provides some tips on how to overcome these limitations. The main focus of this chapter is not the detailed, but the essential technology background information, which is, in most cases, sufcient when troubleshooting dial issues. This chapter includes the following sections:
Overview of existing modems Typical telco issues, including digital pads and line code errors Authentication options for dial Extensive information about one of the most commonly used protocols in dial environmentPPP
Overview of Modems
In general, modulator-demodulators (modems) are devices that modulate digital signals into audible sounds and demodulate audible sounds into digital signals. Included in this section are some basic facts about telephone companies, how telephone companies deal with switched services, and the limitations that this places on data connections. Besides the information provided in Chapter 1, Remote Access Overview, and Chapter 3, The Cloud, this section also includes information on ways that telcos are improving connection parameters.
126
Chapter 5: Dial Technology Background
A local telco takes the signal from the analog line that terminates at a remote users residence and digitizes it to 64 kilobits per second (kbps). This is done so that each call can take the same amount of bandwidth and can be easily placed into larger circuits, such as a Primary Rate Interface (PRI) or channelized digital service 3 (DS3). A 64-kb bandwidth per call is limiting in the amount of data that a modem can push. However, this bandwidth assists the telephone company because they can multiplex hundreds of calls together for ease of transport from one central ofce (CO) to another. The quality of digital signals sent over long distances is better than that of analog signals sent over long distances. This is an advantage for modems when calling outside your local CO. Digital signals can be amplied by a device called a repeater. When the signal-to-noise ratio (SNR) drops below acceptable margins, repeaters are often inserted into the line. While amplifying analog signals, the noise is part of the analog signal and is also amplied, which results in lost data because of the noise at a point further down the line. There are two different types of basic modems. The rst is an analog modem, which is the type of modem installed on a users computer. These can be internal (hardware card installed on a system, motherboard) or external (independent, free-standing hardware). Examples of these modems are 3Com/US Robotics Sportster, Lucent WinModems, and Best Data V.90 modems. These modems demodulate the signals coming from an analog line and pass that data off to your computer. They also modulate the data into analog signals and send it down the analog line to your provider. The second type of modem is a digital modem. Digital modems are found in most dial access servers that interface directly with the 64-kbps trunks from the telco in the form of a PRI or a channelized DS3. They decode the digital signals directly off the 64-kbps trunk and pass them to the dial-in server. They also place the digital signals directly on the 64kbps trunk and pass them to the end user. Digital modems were key to breaking the 33.6-kbps speed barrier that analog modem to analog modem calls could not surpass. With digital modem to analog modem calls, the digital modem can send up to 53,333 bps to the analog modem by placing the digital signals directly on the line, but the analog modem can only send at speeds up to 33,600 bps back to the digital modem because it has to perform a digital to analog conversion prior to sending the data. Table 5-1 describes the different standards that have evolved modems to todays speeds. The different modulations and the speeds achieved by each of them throughout the years are listed in Table 5-1.
Overview of Modems
127
Table 5-1
Modulations and Their Connection Speeds Standard CCITT V.21 CCITT V.22 CCITT V.22 bis CCITT V.32 CCITT V.32 bis V.32 ter V.Fast* V.FC* ITU-T V.34 X2* K56Flex* ITU-T V.90 (terbo)* Speeds Achieved 300 bps (falls back to 150 and 110 bps) 1200 bps (falls back to 600 bps) 2400 bps 9600 bps (falls back to 7200, 4800, and 2400 bps) 14,400 bps (falls back to 12000 bps and V.32) 20,000 bps 28,800 bpsPreliminary implementations of V.34 28,800 bpsAn attempt to make V.Fast more compatible between different implementations 28,800 bps (falls back to 26,400, 24,000, 21,600, 19,200, 16,800, and 14,400 bps; V.32 bis; and V.32) U.S. Robotics 56,000 bps 56,000 bps 56,000 bpsFCC limited to 53,333 bps (falls back to 52,000, 50,667, 49,333, 48,000, 46,667, 45,333, 44,000, 42,667, 41,333, 40,000, 38,667, 38,400, 37,333, 34,667, 34,000, 33,600, 33,333, 32,000, 31,200, 30,667, and 29,333 bps and V.34) 56,000 bpsSame as V.90 with added features including Modem on Hold and Quick Connect
ITU-T V.92
* Not a standard, but worth mentioning because they helped pave the way for the standards to evolve.
NOTE
CCITT (Consultative Committee for International Telegraph and Telephone) changed its name to ITU-T (International Telecommunications Union Telecommunication Standardization Sector) on March 1, 1993. The analog signal loss mentioned previously is easy to notice with modems because they are noise-sensitive devices. After you reach a range of about 15,000 cable feet from your CO, the quality drops to a point where 56k/V.90 is no longer available. The further out you are from the CO, the slower the connection speed becomes. The worst case I have recorded is 42,800 cable feet from a CO, where most modems did not train-up at all, and the ones that did only connected at 4800 to 9600 baud at best. Surprisingly, this was in the city of San Jose, Californiaone of the most populous and upto-date areas in terms of carrier services.
NOTE
128
As speeds increase towards the 56 k limit, the factors that affect a modems ability to connect and remain at those speeds become more apparent. The number one limiting factor is distance from the CO. The second limiting factor is the SNR (S/N ratio). If there is a lot of crosstalk from other lines, your line will have more noise, which limits your connections. Another factor is the telcos cloud that your call travels across on its way to its nal destination.
Telco Issues
This section discusses some modem issues that are not so easy to identify. Before getting to this, having a lot of information can help to determine the fastest speeds you can get by analyzing what your modem sees after a connection is established. Any form of landline should achieve a V.34 connection, but the two key components of a good V.34 connection are the SNR and the amount of usable voice spectrum. For a connection of 33600 baud, the SNR must be 38 dB or higher and the usable spectrum must range from 244 to 3674 Hz. Otherwise, the speaking signal strength to noise strength ratio has to be higher than 79.44. Anything below these standards degrades service. The decibel (dB) is a unit of measuring the strength of the signal, or of a sound. From Newtons Telecom Dictionary (Harry Newton, 1999), The power in telecommunications is low and normally is measured in milliwatts. However, the milliwatt is not a convenient way to express differences in power level between circuits. Voice frequency circuits are designed around the human ear, which has a logarithmic response to changes in power. Therefore, in telephony, the decibel, which is logarithmic rather than linear measurement, is used as a measure between circuits or transmission level points. As you well know, 1 db = 20 log(signal/noise). At least eight factors can reduce the SNR, frequency response, or both:
NOTE
Robbed bit signaling reduces the SNR. Extra analog to digital conversions reduce the SNR. Load coils on the local loop reduce the frequency response. Long local loops reduce frequency response and reduce the SNR. Bridged taps create a loss in signal strength and reduce the SNR. Most of the industry analysts determine bridged taps to be as prominent as on 75 percent of existing copper lines (www.teradyne.com/prods/btd/articles/adsl_test.html). Electrical disturbances including crosstalk, corroded connectors, lines running parallel to uorescent lights or power cables, and equipment sharing the same power jack as the modem can all reduce the SNR.
Telco Issues
129
Voice circuits that pass through any sub-64 k coding reduce the frequency response. Most circuits with sub-64 k coding result in speeds of less than 16,800 baud. If incorrectly congured, Subscriber Loop Concentrators (SLCs), which multiplex multiple loops into a trunk, can limit the voice spectrum and subsequently create a low SNR ratio.
With these and other limitations mentioned later, a V.90 connection rarely obtains its maximum speed. First, only one analog to digital conversion can exist on a circuit, which means that from the moment the call from the client modem hits the rst digital switch, the call must stay in digital form over a DS0 all the way until it hits the network access server (NAS). This also indicates that the NAS must interface with only DS0s in the form of a PRI or a channelized T1 (DS1). The ideal scenario for a V.90 call is a 3200 Hz response range and the local loop should not be longer than 3 miles. At 3.5 miles in the U.S., a load coil is usually applied to the line, which degrades frequency response and in turn eliminates any chance for a V.90 connection. The SNR from the client modem should be 40 dB (40 dB is a SNR of 100), or higher.
Digital Pad
A telephone line connected to a remote users minimum point of entry (MPOE) or to a telecommuters hotel room carries a full-duplex call on a single pair of wires. This means that both send and receive signals are transmitted simultaneously, but on individual wires. When the send and receive signals are broken apart from each other, there is a leakage of audible sound from send to receive and vice versa. This leakage is heard as an echo and becomes more noticeable as the distance increases from source to destination. Because analog lines are primarily used for voice, this echo must be quieted through the use of a pad to remove the echo. Placement of a pad can cause issues with a 56-bps connection. Both analog and digital pads act as a volume control for both sides of the line. Although a digital pad uses the digital data to adjust the volume, it can affect the speed, but should not prevent a connection. Analog pads have to convert digital data to analog, adjust the volume, and convert back to digital. An analog pad that is located between a residence and the CO can introduce another analogto-digital conversion into your segment and might prevent a 56-kbps modem connection, although some testing suggests that modems are not adversely affected. The following are three different call scenarios that demonstrate these issues:
In cases where your call originates and terminates within the same CO, there is no pad applied to the line. The distance between source and destination is so small that the echo is not heard and a pad is not required.
130
If your call travels through a long-distance provider to get from source to destination, there is most likely a 6-dB pad on the line. 6 dB (6 dB is a SNR of 2) is only a general rule and can be different depending on your carrier. If your call stays within the same local carrier, but travels from one CO to another, there is a 3-dB pad on the line (signal to noise ratio of approx. 1.4). Again, this is only a general rule and can differ from carrier to carrier. In most cases, this is the type of call that customers make to an Internet service provider (ISP), and an ISP does not generally have equipment at every CO. ISPs do usually have equipment at one CO within a certain calling area or hub, and back haul the trafc from neighboring COs to the location where the equipment resides. The reason that the 3-dB pad was mentioned is because it seems to interfere with a lot of 56 k modems in terms of speed and connection quality. There is a way to change your pad to 6 db to see if it makes the connection quality any better. If you dial 1 + area code + number instead of just dialing the number, you are telling the carrier that this is a long-distance call, and that it needs to have a 6-dB pad. If the connection quality is any better, the 3-dB pad is causing the issues.
There is no available data to explain why a 3-dB digital pad adversely affects the connection, nor is there any way to correct this through access server congurations. A carrier can change the padding on a line, but it is uncommon for them to change it for residential customers. In fact, many of the rst level support staff that handle trouble calls wont know what this is. A telco technician is the best person to answer these questions and to make this change.
Line Code Errors

On both a PRI and a T1, time slots exist for each of the 64-kbps channels. (See Chapter 2, Telecommunication Basics, for more information.) As the data is received, a time slot generator places the bits into these time slots. There can never be more than seven 0s in a row, even across time slots, and this is where line coding must be considered. If eight 0s are in a row, the time slot generator converts the eight 0s to a combination of 0s and 1s, depending on the line code. (See Figure 2-10 for a comparison of different coding schemes.) Alternate mark inversion (AMI) is based on a pseudoternary or three level system signal, which represents binary digits, in which successive marks (logical 1s) are of alternately positive and negative polarity pulses, and the absolute values of their amplitudes are normally equal, and spaces (logical 0s) are of 0 amplitude, or no symbol. Each pulse is approximately 3 volts in amplitude and has a 50 percent duty cycle, which means that it takes up half of the time slot for pulse transmission. Pulses have a tendency to spread out in the time domain as they travel down a line. Restricting the initial transmission to occupy half the time slot helps the repeaters, and the receiving end, nd the middle of each time slot and stay synchronized. In AMI, the pattern of bits 1 0 0 0 0 1 1 0 encodes to + 0 0 0 0 - + 0.
Telco Issues
131
A problem with this coding scheme is the way 0 is interpreted as a no-signal condition. Therefore, an absence of pulses (all 0s) can force repeaters and network equipment (the carriers facility Digital Phase-Locked Loop (DPLL) to lose frame synchronization. To prevent this, all T1s are required to meet the ones density (pulse density) requirement, in which the FCC rule states that no more than 15 consecutive 0s can be transmitted to the line (40 according to some sources). In fact, Cisco and other carriers dene the ones density scheme so as to allow a channel service unit/data service unit (CSU/DSU) to recover the data clock reliably, as no more than eight consecutive 0s. The CSU/DSU derives the data clock from the data that passes through it. To recover the clock, the CSU/DSU hardware must receive at least one 1-bit value for every 8 bits of data that pass through it. The rule is also called pulse density. Often, the carriers use the eighth bit (least signicant bit [LSB]) for supervision, which leaves only 7 of the 8 bits for user data, which provide a (7 bits 8000 frames per second =) 56,000-bps data channel. With AMI, the bits are changed to 0000000P in all time slots when data is being transmitted no matter the bit pattern. In the combination 0000000P, P is a pulse with the opposite polarity as the previous pulse. The LSB is always 1, which yields a 56-kbps time slot. Only the LSB is altered. With AMI, throughput suffers when the eighth bit is blindly stuffed with a 1. Maintaining synchronization requires only that enough pulses are sent down the line. Bipolar 8-zero substitution (B8ZS) can transmit an arbitrary bit sequence. When eight consecutive 0 bits are scheduled for transmission, a B8ZS transmitter replaces the eight 0s with a code word that contains intentional bipolar violations (BPVs), as shown in Figure 5-1. This technique guarantees a ones density independent of the data stream.
Figure 5-1 B8ZS Guaranties that Ones Density Is Independent of the Data Stream
NOTE
Time Slot n bit7 Bits to Be Sent (Time Slot n+1 is all 0s) x bit8 1 bit1 0 bit2 0 bit3 0
Time Slot n+1 bit4 0 bit5 0 bit6 0 bit7 0 bit8 0 bit1 x
Time Slot n+2 bit2 x ... x
Line Encoding Without B8ZS (ProblemNot Enough 1s) Line Encoding with B8ZS (Because the preceding LSB in time slot n is positive, the combination 00000000 in time slot n+2 will be replaced with 000+ 0 +.)
132
The combination of 00000000 is always replaced with the combination 000VP0VP, but the polarity of V and P can differ, based on a polarity of the preceding LSB. In Figure 5-1, the preceding bit in time slot n is positive, and the 0000000 in slot n + 1 is replaced with 000+-0-+. If the polarity of the preceding lsb is negative, the resulting combination will be 000-+0+-. The most commonly used coding scheme in Europe and Japan is called high density binary 3 (HDB3). This scheme is based again on AMI encoding, but the string of consecutive four 0 is replaced with a sequence that contains one or two pulses. In each case, the fourth bit is replaced with a code violation (v) signal. An additional rule is introduced to ensure effective violation, based on the polarity of the preceding pulse and the number of bipolar pulses since the last substitution: If the preceding polarity is negative and
The number of bipolar pulses since the last substitution is odd, the combination 0000 is represented as 000V (V-negative). The number of bipolar pulses since the last substitution is even, the combination 0000 is represented as V00V (V-positive). The number of bipolar pulses since the last substitution is odd, the combination 0000 is represented as 000V (V-positive). The number of bipolar pulses since the last substitution is even, the combination 0000 is represented as V00V (V-negative).
If the preceding polarity is positive and
Now imagine that an AS5300 router is using B8ZS line coding. The integral CSU/DSU in the router modies the data prior to sending it across the wire to the telephone company. The other side is expecting AMI coding. It is not difcult to understand that the side using AMI coding will misinterpret the incoming combination in time slot n + 1. While the B8ZS is sending 000VP0VP, the AMI side is expecting 0000000P, because only the LSB is altered in AMI, and as a result, this site passes the data without recognizing that the original combination is eight 0s. The same logic applies if AS5300 is using HDB3. The inaccurate transfer of data doesnt signicantly affect voice, but it does extensively interfere with a modem. The challenge of nding this type of problem is that it is well masked. The 108 Bert Test, which is supposed to nd any and all possible problems with a T1 or a PRI, never transmits more than seven bits set to zero in a row. This will never force the substitution algorithm and therefore never detect this problem. These types of errors are reported in RFC 1232 (see the BPV errors in Table 7-1 in Chapter 7). However, it is vital in the troubleshooting process to make sure that both sides are using the same coding scheme.
Authentication Options
Authentication for dial can be implemented in many different ways. It can be within PPP or outside of PPP, such as in the form of a login script or an after-dial terminal window. Within PPP, authentication can range from Password Authentication Protocol (PAP) to
Authentication Options
133
Challenge Handshake Authentication Protocol (CHAP) to Microsoft Challenge Handshake Authentication Protocol (MSCHAP). The username and password combinations can be stored on the router, a Remote Authentication Dial-In User Service (RADIUS) server, a Terminal Access Controller Access Control System (TACACS) server, or an Extended TACACS (TACACS+) server. You can also use any combination of these. Because there are a myriad of possibilities, additional considerations are highlighted here to help you decide what form of authentication is best to use for your specic application and requirements. The authentication options are fully applicable for both dialup and ISDN technologies. See Part III, ISDN for more information on ISDN service. The rst and easiest decision to make is whether to use an authentication server, such as TACACS or RADIUS, or to congure xed usernames and passwords directly on the router. Authentication servers can centrally manage authentications for thousands of users who are dispersed geographically and connecting to the NASs. They include added features for handling static or dynamic Internet Protocol (IP) allocation, dial-out scenarios, and account lockouts for account misuse or terminations. Having the authentication parameters all locally stored on the router is appealing for dialon-demand backup scenarios where usernames, passwords, and phone numbers are static unless manually changed. Next, you choose if you want PPP, a terminal window after connection, or a combination of both to handle authentication. This can be easily answered by reviewing your user-base and their needs. In almost all customer-oriented applications, you will most likely choose authentication through PPP only. However, in enterprise situations where some users have unique requirements, such as text-based dialup, you use a combination of both. If you decide to use PPP, you can determine which form of authentication to use inside of PPP. The most common form is PAP, but in areas where security is a concern you might opt for MS-CHAP or CHAP. CHAP offers the highest level of security out of the three methods. CHAP is the most common form of authentication for dial-on-demand applications. As before, you can use a combination of all of these. For example, if your typical user dials in with Microsoft Dial-Up Networking, the default settings for authentication are PAP over PPP. You might have some users, especially non-Windows users, connecting through text, and you can congure the lines to auto-select text or PPP. If the core router uses a dial-ondemand link in the event of an outage, you can congure the backup link on the router with a static CHAP username and password. The most common authentication for Internet Access (connecting to an ISP) is PAP. This is what most people are using when they connect to the Internet. In the corporate world and
NOTE
134
internal to a business, PAP is also used, but with one-time password tokens. This allows for simplistic end user setup along with the added security of an ever-changing password. In places where static (non-changing) passwords exist in the corporate world, CHAP prevails. Finally, there is one last form of authentication that is potentially a more secure form. It uses dial-back authentication. In this case, the user places a call to the server. After it is authenticated, the server dials back to the client and authenticates again by using the clients phone number as an added security measure. Unfortunately, this type of authentication requires a xed phone number, which is not possible for individuals who are traveling. The congurations for the different types of authentication are covered in Chapter 6, Dial Design and Conguration Solutions.
PPP
PPP is dened in RFC 1661 and replaces the Serial Line Internet Protocol (SLIP) because of its deciencies. SLIP only supports the IP protocol, and does not allow authentication and dynamic assignment of routed protocols. Unlike SLIP, PPP provides a standard method for transporting multiprotocol datagrams over point-to-point links. PPP is composed of three main components:
A method for encapsulating multiprotocol datagrams A link control protocol (LCP) for establishing, conguring, and testing the data-link connection A family of Network Control Protocols (NCPs) for establishing and conguring different network-layer protocols 1
The PPP protocol falls under the denitions of the second, or data link layer, of the Open System Interconnection (OSI) model. The format of the PPP frame is shown in Figure 5-2.
Figure 5-2 The Format of the PPP Frame
1 Byte Flag 01111110
1 Byte Address 11111111
1 Byte Control
1-2 Bytes Protocol
Variable Data and Padding
2-4 Bytes FCS
1 Flag 01111110
The descriptions of the elds in Figure 5-2 are as follows:
FlagSimilar to the one for high-level data link control (HDLC), the Flag indicates the beginning and the end of the PPP frame. Its value is 01111110. AddressBecause PPP is used for a point-to-point connection, the Address eld uses the broadcast address of HDLC, 11111111, to avoid the data-link address in the protocol.
PPP
135
ControlThe Control eld uses the format of the U-frame in HDLC. The value is 11000000 to show that the frame does not contain any sequence numbers, and that there is no ow and error control. ProtocolThis eld denes what is being carried in the Data eld. Some valid values of the Protocol eld include the following: c021LCP c023PAP c025Link Quality Report c223CHAP
Data eldThe user data or NCP packets are carried by the Data eld, sometimes called the Payload eld. FCSThe Frame Check Sequence (FCS) eld is the same as in HDLC. It contains a 2- or 4-byte cyclic redundancy check (CRC).
During the process of establishing the protocol, the PPP link goes through several distinct phases, which are specied as follows:
Link Dead (physical layer not ready) Link Establishment phase Authentication phase Network-Layer Protocol phase Link Termination phase
The following sections summarize these phases.
Link Dead (Physical Layer Not Ready)

The link necessarily begins and ends with this phase. When an external event, such as a Carrier Detect (CD) Up event, indicates that the physical layer is ready to be used, PPP proceeds to the Link Establishment phase. During this phase, the LCP automation (described later) is in the initial or starting state.
Link Establishment Phase

LCP establishes the connection through an exchange of congure packets. As soon as the Protocol eld contains c021h, the phase is changed to link establishment. After a Congure-Ack packet is both sent and received, the exchange is complete and the LCP Opened state begins. The LCP codes are 1-byte long and are listed in Table 5-2.
136
Table 5-2
LCP Codes, Packet Types, and Descriptions Code (Hex) 01 02 03 04 05 06 07 08 09 0A 0B Packet Type Congure-Request Congure-Ack Congure-Nak Congure-Rej Terminate-Request Terminate-Ack Code-Rej Protocol-Rej Echo-Request Echo-Replay Discard-Request Description List of proposed link conguration options Acknowledge the proposed conguration options Does not acknowledge the proposed conguration options Unknown conguration optionReject Request to terminate the phase Acknowledges the termination request Unknown codeReject Unknown protocolReject Checks if the other end is Up Response to Echo-Request Discard the request
Any non-LCP packets received during the Link Establishment phase must be silently discarded.
Authentication Phase
By default, authentication is not mandatory unless the protocol number used is c023 (PAP) or c223 (CHAP). The authentication negotiation occurs during the Link Establishment phase, where only LCP, authentication protocol, and link quality monitoring packets (protocol type c025Link Quality Report) are allowed. All other packets received during this phase are discarded. In PAP, one side supplies both a username and password in clear-text to the peer that is authenticating it. In CHAP, one peer challenges the other peer, and the latter one must be able to respond with the correct answer to the challenge before passing authentication. The password in CHAP creates the answer to the challenge and is never transmitted across the wire, which makes it inherently more secure. Also, there is MS-CHAP, which is similar to CHAP with the only exception being that MS-CHAP uses Microsofts version of the protocol.
Network Layer Protocol Phase

After the link is established and optional facilities are negotiated as needed by the LCP, PPP must send NCP packets to choose and congure one or more network-layer protocols (such as IP, Internetwork Packet Exchange [IPX], or AppleTalk). After it is congured, datagrams from each network layer protocol can be sent over the link. The link remains congured for communications until explicit LCP or NCP packets close the link down. Each NCP can be
PPP
137
opened and closed at any time. After an NCP reaches the Opened state, PPP carries the corresponding network-layer protocol packets. One example for NCP is the IP Control Protocol (IPCP). Its format is shown in Figure 5-3. The value of the Protocol eld for a PPP packet is 8021h. 2
Figure 5-3 The Format of an IPCP Frame
1 Byte Code
1 Byte ID
2 Bytes Length
2 Bytes Protocol= 8021h
Variable IPCP Data
Because every NCP negotiates its own phases, reaching levels of Open and Close, Code values are dened in the Code eld to facilitate the process. The Code eld is 1-byte and the valid values are identied in Table 5-3.
Table 5-3 Code Values of an IPCP Protocol Code (Hex) 01 02 03 04 05 06 07 Packet Type Congure-Request Congure-Ack Congure-Nak Congure-Rej Terminate-Request Terminate-Ack Code-Rej Description List of proposed link conguration options Acknowledge the proposed conguration options Does not acknowledge the proposed conguration options Unknown conguration optionReject Request to terminate the phase Acknowledges the termination request Unknown codeReject
Link Termination Phase

PPP can terminate the link at any time. Possible reasons include loss of carrier, authentication failure, link quality failure, expiration of an idle-period timer, and the administrative closing of the link. LCP closes the link through an exchange of terminate packets (see LCP packets 05h and 06h). While the link is closing, PPP informs the networklayer protocols so that they can take appropriate action.
PPP Troubleshooting Considerations

For practical purposes, engineers often consider PPP as a four-phase protocol, ignoring the very rst phase (Link Dead). This does not make a difference for troubleshooting purposes. 3
138
NOTE
PPP over different technologies, such as dial, ISDN, and Frame Relay, poses different requirements to ensure inter-operability with the PPP protocol. For additional information, see RFC 1618 or Parts III and IV, Frame Relay, of this book. One of the most resource-intensive procedures in PPP negotiation occurs during the LCP negotiation. Previously, Cisco IOS created a statically congurable number of processes to authenticate calls. Each of these processes handles a single call, but in some situations, the limited number of processes cannot keep up with the incoming call rate, resulting in some calls timing out (the empiric numbers were showing about 1300 users per NAS). The AAAPPP-VPDN Non-Blocking feature, introduced in IOS release 12.2(4)T, changed the software architecture such that the number of processes does not limit the rate of call handling. Async HDLC framing (the frame type dened in RFC 1662) engine for the R1.1 release is compatible with the 7200 platform and ensures that each Packet Data Serving Node (PDSN) can handle 8000 active PPP sessions on the 7200 platform.
End Notes
1 RFC 2 RFC
1661. The Point-to-Point Protocol (PPP). W. Simpson, Editor, 1994. 1332. PPP Internet Protocol Control Protocol (IPCP). McGregor, G. 1992.
3 Cisco
Systems, Inc. CCIE Fundamentals: Network Design and Case Studies, Second Edition. Cisco Press, 2000.
Summary
This chapter focused on essential background information to give you a better understanding of the main components of dial technology. This chapter provided an overview of existing modems and dial standards and discusses some typical telco issues, such as digital pads and line code errors. This chapter also detailed authentication options for a dial environment and provided a relatively detailed section on the PPP, which is the main protocol, used for dial connections. Some troubleshooting techniques were also included to increase the knowledge of engineers who will need to troubleshoot dial environments.
Review Questions
1 Name two added features in ITU-T V.92 standard, compared to ITU-T V.90. 2 Name two limiting factors for the ability of the modem to connect.
Review Questions
139
3 If the SNR is 40, how many times higher is the signal strength than noise strength? 4 How would you troubleshoot a case in which a pad of 3dB might be the root of the
problem?
5 If AMI needs to transmit the octet 1 0 0 1 0 1 1 0, and the rst mark is +, what are the
next marks? Write the entire octet.

6 If the preceding LSB in B8ZS is positive, what is the combination for 00000000? 7 What is the main disadvantage of dial-back authentication? 8 Name the main phases of the PPP protocol. 9 What is the value 0xC223 in the protocol eld of PPP? 10 Which protocol in the PPP suite establishes and congures the data-link connection? 11 What is the address eld value of the PPP protocol? 12 Which packet types of LCP terminate the data-link connection?
CHAPTER
Dial Design and Conguration Solutions

Most commonly, modem dial access is used for dial-in network connectivity, dial-out network connectivity, and dial-on-demand routing (DDR). These specic instances are covered in the dial design solutions portion of this chapter, along with dial-out for support purposes and large-scale dial-out services. Fax server capability is another common use for dial, but is not covered here because it is more of a specialized service. The main topics covered in the design portion of this chapter are as follows:
Dial-in network design Dial-out network design Dial-on-demand backup options Dial-in conguration essentials Dial-out conguration essentials Dial-on-demand backup conguration essentials
This part aims at teaching the dial-in and dial-out design essentials. It also teaches the basic conguration options that are required to congure a dial server to either accept or place calls for the particular needs of the network that you are building. Dial-on-demand is also covered here in both design and conguration for use as a backup connection. Following the design portion of this chapter is an extensive section on dial conguration solutions. The following topics in the conguration portion of this chapter give you detailed information about the common and specic dial congurations, including the following:
Text dial-in conguration Point-to-Point Protocol (PPP) dial-in conguration Large-scale dial-in conguration Text dial-out conguration PPP dial-out conguration Large-scale dial-out conguration Dial-on-demand backup conguration
142
Chapter 6: Dial Design and Conguration Solutions
Dial Design Solutions

In the design part of this chapter, some design components remain constant. Dial (in, out, or on-demand) is generally served out of an access server that is connected to the network. Usually, there is an authentication server of some kind to ofoad the authentication processing from the router, making it centrally manageable. Design considerations need to also include the backbone architecture. If dial is a component of a remote access solution for your company, it is a small part of the overall network and should tie into the backbone accordingly. Large service provider dial networks should be designed accordingly as well. Going into greater detail is not practical because of the wide variety of existing services. However, the best way to manage dial networks is to use a hub and spoke design. The hub is a gateway that ties the spokes (dial routers) into the backbone. This gateway is usually a Layer 3 switching device. In cases where the dial routers are just components of a remote access solution, not a large service provider network, it might be appropriate to include all remote access services as spokes behind the hub. These services can include home Frame Relay, ISDN, xDSL, and perhaps Virtual Private Network (VPN). This approach works well because backbone networks change frequently because of the rapid advancements of local-area network/widearea network (LAN/WAN) equipment. Remote access devices generally do not increase speeds as dramatically because the WAN piece of remote access solutions is slowly evolving by comparison. An example of the hub and spoke design for an enterprise is shown in Figure 6-1.
Figure 6-1 Hub and Spoke Backbone Design for Remote Access Services, Including Dial, Frame Relay, ISDN, and a xDSL Gateway
Dial
PRI
To Backbone
ISDN
Si
PRI Telephone Company T1
cat6500
Frame
DSL
DS3
143
Text Dial-In Network

Text-based dial-in networks are generally for support purposes. Typically, modems are attached to the aux port of a router and set up as a console. If you want to add text-based authentication to PPP dial-in services, go to the section, PPP Dial-In Network. The text dial-in design used for remote consoles is relatively simple and the architecture only varies slightly from one implementation to the next. Figure 6-2 shows a modem connected to the aux port of a router. In most cases, this is done using a rolled cable and an RJ45 to DB15 connector. The modem is connected to the telephone company by using a POTS line.
Figure 6-2 Text Dial-In Network Used as a Remote Console
Telephone Company Analog Phone Line AUX Port
PPP Dial-In Network

PPP dial-in networks can vary signicantly from situation to situation; however, the hardware and way it is connected into each network is similar in all cases. Each dial-in router has either a number of async interfaces or group-async interfaces and connects back into the network by an Ethernet or a serial connection. To facilitate centrally managed authentication, an authentication server should also exist on the network. If not, local authentication can be congured on the router, but at the cost of not having the service centrally managed, which can also be difcult to maintain. Figure 6-3 shows an AS5300, an AS5400, or an AS5800 router congured for PPP dial-in. This router has eight Primary Rate Interfaces (PRIs) to the telephone company (telco), which can take in 23 calls each. These PRIs are connected to the Controller T1 ports of the router. The router processes, authenticates, and routes the trafc back into the corporate network through a Fast Ethernet connection. In Figure 6-3, only one PRI is shown; the other seven are connected in exactly the same way.
144
Figure 6-3
PPP Dial-In Network Diagram of an Access Server Connected to the Telephone Company and the Network
Network
AS 5300
PRI
Telephone Company
In the case of text-based authentication, the architecture does not change but the conguration changes slightly to allow for text authentication. These conguration changes are noted later in this chapter.
Text Dial-Out Network

Dial-out networks are commonly used for support purposes. They are used in conjunction with routers that are congured for text dial-in as remote consoles, and for access to these routers when their primary links are down. They can also be used as a way to script dial-out for polling pieces of equipment that are attached to modems in any geographic location. This includes using a dial-out system to test the functionality of dial-in servers. Ciscos Technical Assistance Center (TAC) uses a text-based dial-out service to dial into customer equipment and perform troubleshooting. This is a key resource that the TAC uses and relies upon to do its job daily. This is one way that a TAC can gain access to your equipment. A text-based dial-out server makes quick connections to modems from a place on the network where an analog line does not exist. The typical user-base of a text-based dial-out server must know modem AT commands, or at least the basic AT commands to dial-out, break, and hang-up. The network itself is straightforward. You can use the same network as described in the previous section, PPP Dial-In Network. Figure 6-4 shows an alternate network that you can also use. This gure includes a router with external modems, connected to Async ports through rolled cables, and separate analog lines rather than PRI.
145
Figure 6-4
Text Dial-Out Network Using a 2500 Series Router and External Modems
Analog Phone Line Analog Phone Line Analog Phone Line

2511
Telephone Company
Analog Phone Line Analog Phone Line
PPP Dial-Out Network

Two types of PPP dial-out solutions exist, depending on the user requirement: on net dialout using a software client versus off net dial-out using a router.
On Net Dial-Out
The rst type of dial-out service involves setting up a text-based dial-out server and using a software client to virtually attach a modem from that server to a PC via a LAN. This type of PPP dial-out uses the same conguration as the text dial-out service mentioned earlier. The only difference is that a user of a PPP dial-out service has a software client installed on their machine that emulates a modem connected to a virtual COM port. This client uses the resources of a dial-out server as a directly connected virtual modem, even for fax use. No additional conguration lines are required to set up this service, but you must purchase a software client that can do this. The solution is recommended for companies who frequently use PPP dial-out, potentially saving a signicant amount of money rather than purchasing separate analog lines for everyone that requires them. For the current TAC recommended dial-out software, search Cisco.com by using the keyword CiscoDialOut. Consult the software documentation for the recommended IOS version.
146
Off Net Dial-Out

The second kind of PPP dial-out service connects to an Internet service provider (ISP) using a router as the connecting device. This network design is typical for a home network, when you want more than one PC to access the Internet. It is also similar to a home ISDN design. The setup consists of a modem hanging off of an async interface or an aux port, which dials into a service provider. On the other side of the router is an Ethernet interface where a home computer is connected. The router most likely takes care of Network Address Translation (NAT) to serve each of the computers behind it. It is also possible to set up routing of a subnet through this connection but only if it is set up by your service provider in advance. Figure 6-5 shows the typical network design for this type of connection.
Figure 6-5 PPP Dial-Out Design for Off Net
AUX Port
Telephone Company Analog Phone Line
2511
Large-Scale Dial-Out Network

Large-scale dial-out places many calls to multiple locations, mostly for polling purposes. In this scenario, you can do one of two things: include all the phone numbers and locations on the router in the form of dialer maps or place them on a Terminal Access Controller Access Control System (TACACS+) or Remote Authentication Dial-In User Service (RADIUS) server to pass to the dial-out server during the routers boot sequence. Both situations are covered later in this chapter. Figure 6-6 demonstrates that the network design is identical to the text dial-out network. The only difference is in the conguration. The conguration changes are covered in the section, Large-Scale Dial-Out Conguration later in this chapter. In many cases, you can use the same router for both purposes, which saves hardware and circuit costs by sharing the same set of circuits.
147
Figure 6-6
Large-Scale Dial-Out Network Using an AS5300 Congured to Place Calls over PRI Circuits
Telephone Company AS 5300 PRI
Dial-On-Demand Backup Network

Dial-on demand backup routing is similar to the second form of PPP dial-out covered previously. The section, PPP Dial-Out Network did not cover routing, how to bring up the line when a primary circuit fails, and how to tear it down again when the primary circuit comes back up. There are three different ways to congure DDR:
Using a backup interface Using a oating static route Using a dialer watch
All three options have advantages and disadvantages. Each option is explained here.
Backup Interface
A backup interfaces main advantage is that it is independent of routing protocols, which means that it is not affected by route convergence or stability. The most common use for a backup interface is on a WAN router at a remote site where the only route is a static route back to headquarters. When the primary WAN interface protocol changes its state to down, the backup interface takes over. The router then dials, connects, and passes trafc over the backup. A backup interfaces major downfall is that it is dependent on an interfaces physical state or protocol to change the state to down before the backup link is activated. In the case of Frame Relay, the permanent virtual circuit (PVC) can go down while the circuit is still up, and the backup link is not activated. Using a backup interface also requires interesting trafc to bring up a connection. It can also back up only a single interface on a router, which means that, if one site is connected to two locations, you need a backup interface for each main connection, excluding interfaces from other uses.
148
Floating Static Route

Floating static routes are weighted heavier than the routes that are normally used. It does require a routing protocol, but it does not rely on the physical state or line protocol dropping to trigger a backup connection. For the oating static route to trigger the backup connection, the routing protocol must remove the primary route from the routing table. The speed at which the routing table converges determines how fast the backup connection is triggered. A route showing as possibly down does not trigger the call. Floating static routes still rely on interesting trafc to bring up the line when the primary connection is lost. A good example of a oating static route is on a WAN router running Enhanced Interior Gateway Routing Protocol (EIGRP). In most cases, the oating static route is a default route. When the primary WAN link goes down, the default route is lost, and the oating static default route sends trafc through the backup connection.
Dialer Watch
Dialer watch provides backup connectivity without relying on interesting trafc. With dialer watch, the router monitors the existence of a specied route, and if that route is not present, it initiates dialing on the backup link. It is more difcult to congure and requires either the EIGRP or Open Shortest Path First (OSPF) routing protocol. The main advantage of this solution is that the router dials immediately when the primary route is lost. Dialer watch does not depend on line protocol, encapsulation type, or interesting trafc. The backup dial link stays active until the primary link comes back up, and can be congured to stay up longer in case of apping routes. The details required to congure Dialer Watch are covered in a later section of this chapter, Dial-On-Demand Backup Conguration.
Summary of Each Backup Solution

Table 6-1 summarizes each backup solution.
Table 6-1 Factor Determination of when to place the backup call Summary of Each Type of Backup Solution and Relevant Information on Each One Backup Interface Dependent on the line protocol status of primary interface and requires that the primary interface go down. Encapsulation is a factor, for example, a Frame Relay backup might not work correctly with a backup interface. Floating Static Route Employs static routes with a higher administrative distance to trigger a dial-on-demand routing (DDR) call. Encapsulation independent. Dialer Watch Watches specic routes in the routing table and initiates a backup link if the route is missing. Encapsulation independent.
Encapsulation
Dial Conguration Solutions
149
Table 6-1 Factor
Summary of Each Type of Backup Solution and Relevant Information on Each One (Continued) Backup Interface Does not consider end-toend connectivity. Problems with end-to-end connectivity, such as routing errors, do not trigger backup links. Needs interesting trafc to trigger dialing the backup link. Floating Static Route Evaluates the status of primary links based on the existence of routes to the peer. Hence, it considers primary link status based on the ability to pass trafc to the peer. Needs interesting trafc to trigger dialing the backup link, even after the route to the peer is lost. Dialer Watch Evaluates the status of primary links based on the existence of routes to the peer. Hence, it considers primary link status based on the ability to pass trafc to the peer. Does not rely on interesting packets to trigger dialing. Dialing the backup link is done immediately when the primary route is lost. Dependent on the routing protocol convergence time. EIGRP/OSPF supported. Supports multiple router backup scenario. For example, one router monitors the link between two other routers and starts the backup if that link fails. Bandwidth on demand is not possible because the route to the peer exists regardless of the load on the primary link.
Limitations of determining when to place the backup call
Backup triggers
Routing protocol dependence Supported routing protocols Interface/router limitations
Does not depend on the routing protocol. Routing protocol independent. Limited to one router, one interface.
Dependent on the routing protocol convergence time. All routing protocols supported. Typically limited to single router, but with multiple interface/networks.
Bandwidth on demand
Can be used to provide bandwidth on demand. The backup interface can be set up to activate when the primary link reaches a specied threshold.
Bandwidth on demand is not possible because the route to the peer exists regardless of the load on the primary link.

A dial network can be as small as a single modem on a router or as large as millions of modems across a continent. From modest to grand, the conguration skeleton remains relatively the same. IOS lists the congurations in a standard way because of the hierarchy that is predened in the system. By no means are you expected to write a conguration the way IOS displays it. In fact, the approach used in this chapter to create dial congurations is a logical approach where the conguration commands are covered in an order thats more direct than the way IOS displays them.
150
Text Dial-In Conguration

To create a text dial-in conguration, start by creating a fresh conguration in which a modem is connected to the AUX port of a router for remote console purposes. The router needs to be congured to allow text-based authentication. Because you are using a remote console, which means that the authentication servers might not be reachable, you have the choice of using local usernames and passwords, line passwords, or the enable secret as the password. AAA is optional, but because of its exibility, its used in the following example. The authentication method name used for the following is console, which allows only the enable secret to log in:
3600-wan(config)#aaa authentication login console enable 3600-wan(config)#line aux 0 3600-wan(config-line)#login authentication console
Next, add the lines necessary to congure the modem. In this case, a US Robotics Sportster modem is used. You can congure the modem by using the discovery method, using one of the dened modemcaps, or by creating your own modemcap. To see the list of predened modemcaps, use the command show modemcap. The output from the #show modemcap command is shown in Example 6-1.
Example 6-1 Output of the Command show modemcap
3600-wan#show modemcap default codex_3260 usr_courier usr_sportster hayes_optima global_village viva telebit_t3000 microcom_hdms microcom_server nec_v34 nec_v110 nec_piafs cisco_v110 microcom_mimic mica
The modem autocongure line conguration command performs a series of AT commands that are associated with a modemcap. These are either predened in IOS or user dened by the modemcap global conguration command. The following shows the conguration commands necessary to congure the modem using the predened modemcap for a US Robotics Sportster modem:
3600-wan(config)#line aux 0 3600-wan(config-line)#modem autoconfigure type usr_sportster
Finally, the command modem InOut sets the line up to allow incoming and outgoing calls. For only outgoing calls, such as setting up a router to dial into an ISP, you use the command
151
modem host. The following shows this router being set up to answer calls using the line conguration command modem InOut:
3600-wan(config)#line aux 0 3600-wan(config-line)#modem InOut
The display of a full conguration for a remote console through a modem is shown in Example 6-2.
NOTE
Example 6-2 is the full conguration required for the console section only. The rest of the router must still be congured to address your requirements.
Example 6-2 Text Dial-In Conguration as a Remote Console

3600-wan#show running-config aaa new-model aaa authentication login console enable enable secret 5 $1$VzVJ$B6sbqGo8e2HJDBQ.gxGZp/ ! line aux 0 login authentication console modem InOut modem autoconfigure type usr_sportster speed 115200 ! end
PPP Dial-In Conguration

All PPP dial-in congurations must have a set of the same elements, whether only one or one hundred modems are attached. The rst key element is authentication. This can be done locally with a xed username and password congured on the router or with an authentication, authorization, and accounting (AAA) server. AAA servers can run TACACS+ or RADIUS services for authentication. To apply any aaa conguration, you must rst issue the command aaa new-model. This instructs the router to user the local username/password if there are no other aaa statements. You can use the following command for general purposes, such as allowing any dial-in authentication:
3600-dialin(config)#aaa new-model 3600-dialin(config)#aaa authentication ppp dial group auth
The preceding command simply states that the PPP authentication type named dial is to use the authentication servers in the group named auth. To dene the group auth as a TACACS+ group, you need to add the following lines:
3600-dialin(config)#aaa group server tacacs+ auth 3600-dialin(config-sg-tacacs+)#server 192.168.100.1 3600-dialin(config-sg-tacacs+)#server 192.168.100.2
152
Also, you must specify other characteristics about the TACACS+ servers, such as the port number, key, and timeout, by using the following command structure. For the example, use the default TACACS+ port with a timeout of 18 and a key of 0u812:
3600-dialin(config)#tacacs-server host 192.168.100.1 timeout 18 key 0u812 3600-dialin(config)#tacacs-server host 192.168.100.2 timeout 18 key 0u812
When using a RADIUS group with a slightly different key, the lines change a bit, as shown in Example 6-3.
Example 6-3 RADIUS AAA Group Conguration
3600-dialin(config)#aaa group server radius auth 3600-dialin(config-sg-radius)#server 192.168.100.1 3600-dialin(config-sg-radius)#server 192.168.100.2 3600-dialin(config-sg-radius)#exit 3600-dialin(config)#radius-server host 192.168.100.1 timeout 18 key a10u8 3600-dialin(config)#radius-server host 192.168.100.2 timeout 18 key a10u8
Review the AAA authentication and determine how it works using RADIUS conguration as the example. The dial authentication type for PPP uses the group called auth. This group contains two RADIUS servers, 192.168.100.1 and 192.168.100.2, both of which have a timeout of 18 seconds and a key of a10u8. Other authentication requirements can be met by conguring additional features. For example, if you want to put a local username and password on the router for testing purposes, but still use the auth group for all other authentications, you could use the following line. This can be added to the same conguration because its authentication list has a different name. The name for this authentication list is testing, and the previous one is named dial:
3600-dialin(config)#aaa authentication ppp testing local group auth
Authentication is congured in a particular order. In this case, if the username that tries to pass authentication is not found within the router conguration, the authentication is done by using the group named auth. It is worth mentioning that if a username is set in the routers conguration, the router never passes the authentication for this username to the authentication servers, whether it is correct or incorrect. In other words, after an authentication passes or fails, it never passes through to the next authentication method. The router determines which named authentication method to use based on what is stated in the interface conguration that is listed later in the full conguration, which is why you can have both the dial and the testing named methods in the same conguration. All dial-in routers that support PPP must have an Async interface. It is much easier to work with a Group-Async interface in any environment that has multiple modems with the same interface conguration. In either case, the commands are exactly the same. The GroupAsync interface applies its subcommands to every Async interface in its group range. The group-range command at the end of the list identies what Async interfaces to apply the
153
subcommands. Example 6-4 shows three separate Async interfaces that are congured the same.
Example 6-4 Three Async Interfaces Congured for PPP Dial-In
3600-dialin(config)#interface Async1 3600-dialin(config-if)#ip unnumbered Loopback0 3600-dialin(config-if)#encapsulation ppp 3600-dialin(config-if)#async mode dedicated 3600-dialin(config-if)#ppp authentication pap dial 3600-dialin(config-if)#exit 3600-dialin(config)#interface Async2 3600-dialin(config-if)#ip unnumbered Loopback0 3600-dialin(config-if)#encapsulation ppp 3600-dialin(config-if)#async mode dedicated 3600-dialin(config-if)#ppp authentication pap dial 3600-dialin(config-if)#exit 3600-dialin(config)#interface Async3 3600-dialin(config-if)#ip unnumbered Loopback0 3600-dialin(config-if)#encapsulation ppp 3600-dialin(config-if)#async mode dedicated 3600-dialin(config-if)#ppp authentication pap dial
The preceding three interfaces were all congured the same way. They could have been easily consolidated into the commands in Example 6-5.
Example 6-5 Group-Async Interface to Consolidate Individual Async Interfaces
3600-dialin(config)#interface Group-Async1 3600-dialin(config-if)#ip unnumbered Loopback0 3600-dialin(config-if)#encapsulation ppp 3600-dialin(config-if)#async mode dedicated 3600-dialin(config-if)#ppp authentication pap dial 3600-dialin(config-if)#group-range 1 3
In both examples, all three Async interfaces use the IP address of Loopback0, use PPP as the encapsulation type, are dedicated to async mode (not interactive), and also authenticate through PPP using the dial named authentication method. While conguring the Async interfaces, add the lines necessary to congure the modem; this case uses US Robotics Sportster modems as the example. You can congure the lines on which these modems reside by either using the discovery method, the dened modemcaps, or by creating your own modemcap. To see the list of predened modemcaps in Cisco IOS, use the command show modemcap. The following congures this modem with the predened modemcap built into an IOS named usr sportster:
3600-dialin(config)#line 1 3 3600-dialin(config-line)#modem autoconfigure type usr_sportster
154
The following shows the command modem InOut being congured to allow incoming modem calls in the same way as it was done in the text dial-in scenario:
3600-dialin(config)#line 1 3 3600-dialin(config-line)#modem InOut
There are still a few more components to add to this conguration to provide client modems with all the information they require. First, you must provide an IP address from a specied pool:
3600-dialin(config)#ip local pool dialpool 192.168.0.250 192.168.0.254
The rst line species the pool named dialpool. It denes an address pool range starting with 192.168.0.250 and ending with 192.168.0.254. For this pool to be used, it must be applied to the Group-Async interface using the following commands:
3600-dialin(config)#interface Group-Async1 3600-dialin(config-if)#peer default ip address pool dialpool
After it is applied to the interface, the client modems can get an IP address from the range specied. Because the interface Loopback0 still does not have an IP address, however, the client modems do not have a default gateway that works. Therefore, you must assign an IP address for that interface using the following commands:
3600-dialin(config)#interface Loopback0 3600-dialin(config-if)#ip address 192.168.0.249 255.255.255.248
The interface for Loopback0 is given the rst address in the subnet. This address is not contained within the dialpool address pool, but is still within the same subnet. By not including it in the pool, you ensure that the IP is not inadvertently given to a host, thus causing a conict. Now, the connecting modems can now get an IP address, but some services still need to be congured. The connecting clients now require Domain Name System (DNS) and Windows Internet Naming Service (WINS) server information, and default gateway and subnet mask information:
3600-dialin(config)#async-bootp 3600-dialin(config)#async-bootp 3600-dialin(config)#async-bootp 3600-dialin(config)#async-bootp dns-server 192.168.100.3 192.168.100.4 nbns-server 192.168.100.5 192.168.100.6 gateway 192.168.0.249 subnet-mask 255.255.255.248
The connecting modem has all the information that it needs to connect and route, and to use DNS and WINS services. Now, you must congure this dial-in router to route all trafc to the backbone. In most cases, you use a routing protocol that handles this issue for you; however, because this is a single-homed router, static routing is preferred. On the dial-in core router, the Ethernet0/0 interface shown in these examples connects to the backbone and uses IP address 192.168.0.246/30. Your connection will use different IP addresses. You must add a default route to the device on the other side, which in this example uses the IP address 192.168.0.245:
3600-dialin(config)#interface Ethernet0/0 3600-dialin(config-if)#ip address 192.168.0.246 255.255.255.252 3600-dialin(config-if)#exit 3600-dialin(config)#ip route 0.0.0.0 0.0.0.0 192.168.0.245
155
Finally, issue the command show ip interface brief to ensure that all the interfaces on the router are not in shutdown state. If they are, you must issue the no shutdown command on each interface. Example 6-6 shows the output from this command. Youll notice that all the individual Async interfaces exist in the output, even though their conguration is consolidated under the Group-Async1 interface. These interfaces remain in a down/down state until they are connected.
Example 6-6 Output from the PPP Dial-In Command show ip interface brief
3600-dialin#show ip interface brief Interface IP-Address OK? Ethernet0/0 192.168.0.246 YES Async1 192.168.0.249 YES Async2 192.168.0.249 YES Async3 192.168.0.249 YES Group-Async1 192.168.0.249 YES Loopback0 192.168.0.249 YES Method manual NVRAM NVRAM NVRAM unset manual Status up down down down down up Protocol up down down down down up
The basic PPP dial-in conguration is now complete and Example 6-7 is the output of the full conguration.
Example 6-7 PPP Dial-In Conguration
3600-dialin#show running-config version 12.2 service timestamps debug uptime service timestamps log uptime no service password-encryption ! hostname 3600-dialin ! boot system flash aaa new-model ! ! The authentication type is specified here: aaa group server radius auth server 192.168.100.1 auth-port 1645 acct-port 1646 server 192.168.100.2 auth-port 1645 acct-port 1646 ! aaa authentication ppp dial group auth aaa authentication ppp testing local group auth aaa session-id common ! ip subnet-zero ! async-bootp subnet-mask 255.255.255.248 async-bootp gateway 192.168.0.249 async-bootp dns-server 192.168.100.3 192.168.100.4 async-bootp nbns-server 192.168.100.5 192.168.100.6
continues
156
Example 6-7 PPP Dial-In Conguration (Continued)

! ! Begin interface configurations: interface Loopback0 ip address 192.168.0.249 255.255.255.248 ! interface Ethernet0/0 ip address 192.168.0.246 255.255.255.252 ! ! Notice that Async Group requires only one configuration section. ! These configurations apply to all Async interfaces, members of the group. interface Group-Async1 ip unnumbered Loopback0 encapsulation ppp async mode dedicated peer default ip address pool dialpool ppp authentication pap dial group-range 1 3 ! ip local pool dialpool 192.168.0.250 192.168.0.254 ip classless ip route 0.0.0.0 0.0.0.0 192.168.0.245 ! ! Authentication server specifications: radius-server host 192.168.100.1 auth-port 1645 acct-port 1646 timeout 18 key a10u8 radius-server host 192.168.100.2 auth-port 1645 acct-port 1646 timeout 18 key a10u8 radius-server retransmit 3 ! line con 0 exec-timeout 0 0 line 1 3 modem InOut modem autoconfigure type usr_sportster speed 115200 line aux 0 line vty 0 4 ! end
You can also use text authentication in conjunction with standard dial-in services to allow for modem scripts, and with any client that uses after-dial terminal windows for authentication. For the following example, the conguration from Example 6-7 on PPP dial-in services is used as the base conguration for text-based authentication; all subsequent commands are added to it. To enable an interactive text session, you must congure the Async interface to allow interactive use. To do this, use the command async mode interactive. Again, you can use the conguration created in the last example as a base conguration:
3600-dialin(config)#interface group-async1 3600-dialin(config-if)#async mode interactive
157
The preceding commands enable a connecting modem to connect directly to the VTY line instead of the Async interface. Now, you must congure authentication and the lines associated with the Async interfaces that were just made interactive. First, set the same authentication for the line as previously set for PPP. You must also include the testing line in the event that you want to test or connect using a local username and password in the future:
3600-dialin(config)#aaa authentication login dial group auth 3600-dialin(config)#aaa authentication login testing local group auth
Heres an important step thats often forgotten: If you authenticated already via text, you do not want to force authentication in PPP as well. The if-needed parameter tells the router to only authenticate via PPP, as long as the user has not been authenticated by another method already. If conguring this feature, these commands replace the previous ones:
3600-dialin(config)#aaa authentication ppp dial if-needed group auth 3600-dialin(config)#aaa authentication ppp testing if-needed local group auth
Then, apply the authentication method to the VTY lines by using the following command:
3600-dialin(config)#line 1 3 3600-dialin(config-line)#login authentication dial
Next, you must congure the lines to accept a dial-in call. Because the preceding async mode interactive command sends the call to the line rst, the line must be congured to automatically determine if the client is using PPP or text authentication. The following lines determine what automatic selection criteria you want the router to use:
3600-dialin(config)#line 1 3 3600-dialin(config-line)#autoselect during-login 3600-dialin(config-line)#autoselect ppp
First, autoselect during login tells the router to do the automatic selection at the username and password prompt. Then, autoselect ppp tells the router to check for PPP when it performs the automatic selection. You can also congure it to do automatic selection of Serial Line Internet Protocol (SLIP) and AppleTalk Remote Access Protocol (ARAP) with the commands autoselect slip and autoselect arap respectively. To prompt for username and password from the line, the router must allow an exec session by conguring the command exec on the line:
3600-dialin(config)#line 1 3 3600-dialin(config-line)#exec
The added exec command starts an exec process, or enables you to have access to a router prompt. The prompt issued after authentication is not an enable prompt, but a user can enable it by entering the enable secret. For security purposes, an ISP uses a command that automatically executes after the user logs in, so that the user does not have access to a router prompt. In most cases, the command you want to automatically execute is ppp default, which starts a PPP session. To automatically execute this command, you need to select the preferred lines and congure the autocommand ppp default command:
3600-dialin(config)#line 1 3 3600-dialin(config-line)#autocommand ppp default
158
The new router conguration is shown in Example 6-8. This conguration allows dial-in using either PPP or text authentication.
Example 6-8 Text and PPP Dial-In Conguration
version 12.2 service timestamps debug uptime service timestamps log uptime no service password-encryption ! hostname 3600-dialin ! boot system flash aaa new-model ! ! RADIUS authentication and server specifications aaa group server radius auth server 192.168.100.1 auth-port 1645 acct-port 1646 server 192.168.100.2 auth-port 1645 acct-port 1646 ! ! Local group access configuration: aaa authentication login dial group auth aaa authentication login testing local-case group auth aaa authentication ppp dial if-needed group auth aaa authentication ppp testing if-needed local-case group auth aaa session-id common ! ip subnet-zero ! async-bootp subnet-mask 255.255.255.248 async-bootp gateway 192.168.0.249 async-bootp dns-server 192.168.100.3 192.168.100.4 async-bootp nbns-server 192.168.100.5 192.168.100.6 ! interface Loopback0 ip address 192.168.0.249 255.255.255.248 ! interface Ethernet0/0 ip address 192.168.0.246 255.255.255.252 ! interface Group-Async1 ip unnumbered Loopback0 encapsulation ppp async mode interactive peer default ip address pool dialpool ppp authentication pap dial group-range 1 3 ! ip local pool dialpool 192.168.0.250 192.168.0.254 ip classless ip route 0.0.0.0 0.0.0.0 192.168.0.245 ! radius-server host 192.168.100.1 auth-port 1645 acct-port 1646 timeout 18 key a10u8
159
Example 6-8 Text and PPP Dial-In Conguration (Continued)

radius-server host 192.168.100.2 auth-port 1645 acct-port 1646 timeout 18 key a10u8 radius-server retransmit 3 ! line con 0 exec-timeout 0 0 ! Line configuration to allow dial group login: line 1 3 login authentication dial modem InOut modem autoconfigure type usr_sportster autocommand ppp default autoselect during-login autoselect ppp speed 115200 line aux 0 line vty 0 4 ! end
Large-Scale Dial-In Conguration

A large-scale dial-in conguration does not signicantly differ from a regular dial-in conguration. In most cases, it just requires that you use an access server, which provides extended capacity versus any router with a few async ports. To congure an access server such as an AS5300 or AS5400, use the same PPP or text and PPP dial-in conguration as covered in the previous section. The group range of the groupasync interface must increase to include all modems in the router. The IP pool set aside for dial-in users must be increased to handle the number of digital service 0s (DS0s) terminating on the device. Also, the automatic conguration of the modem must be set to the type of modem in the server. There is also additional conguration information that must be added for large-scale dialin servers. The phone lines no longer attach directly to the modems; instead, a PRI circuit carries the calls from the central ofce (CO) to your equipment. Because of this design, the rst thing to congure is the PRI. There are two sections to congure: the controller and the serial interface. Example 6-9 shows a sample T1 controller conguration.
Example 6-9 Controller T1 Conguration
5300-dialin(config)#controller T1 0 5300-dialin(config-controller)#framing esf 5300-dialin(config-controller)#linecode b8zs 5300-dialin(config-controller)#pri-group timeslots 1-24 5300-dialin(config-controller)#no shutdown
160
To begin with, the controller must be congured according to the way that the circuit was provisioned. In most cases where the circuit is a PRI, the framing is Extended Superframe (ESF), and the linecode is bipolar 8-zero substitution (B8ZS). After framing and linecode are congured, you must specify what time slots are to be used. Generally, all time slots are used for PRI DS0s, and they are congured as stated previously. Finally, you can bring the controller up. Non-Facility-Associated Signaling (NFAS) allows a single D channel to control multiple PRI interfaces. Allowing multiple PRIs to use a single D channel permits the use of an extra DS0 per PRI member of an NFAS group. Also, a backup D channel can be congured for use when the primary NFAS D channel fails. All NFAS members of a group must terminate on the same dial router. To congure NFAS, you must know the circuit with the primary D channel, the circuit with the backup D channel (if there is one), and all NFAS members in order. The easiest way to congure NFAS is to plug the circuits into the router in order. For example, if you have four circuits in an NFAS group with the primary D channel plugged into controller T1 4, you plug the circuit with the backup D channel into T1 5, and the following two into T1 6 and T1 7, in the order that they are congured from the telco. The controller conguration for this example is shown in Example 6-10.
Example 6-10 Controller Conguration for NFAS Circuits
5300-dialin(config)#controller T1 4 5300-dialin(config-controller)#framing esf 5300-dialin(config-controller)#linecode b8zs 5300-dialin(config-controller)#pri-group timeslots 0 nfas_group 0 5300-dialin(config-controller)#exit 5300-dialin(config)#controller T1 5 5300-dialin(config-controller)#framing esf 5300-dialin(config-controller)#linecode b8zs 5300-dialin(config-controller)#pri-group timeslots 1 nfas_group 0 5300-dialin(config-controller)#exit 5300-dialin(config)#controller T1 6 5300-dialin(config-controller)#framing esf 5300-dialin(config-controller)#linecode b8zs 5300-dialin(config-controller)#pri-group timeslots 2 nfas_group 0 5300-dialin(config-controller)#exit 5300-dialin(config)#controller T1 7 5300-dialin(config-controller)#framing esf 5300-dialin(config-controller)#linecode b8zs 5300-dialin(config-controller)#pri-group timeslots 3 nfas_group 0
1-24 nfas_d primary nfas_int
1-24 nfas_d backup nfas_int
1-24 nfas_d none nfas_int
1-24 nfas_d none nfas_int
You can have up to 37 different NFAS groups on the same router. Each PRI within each group must have a unique interface number, starting with zero and increasing by one for
161
each PRI in the group. A maximum of 20 PRIs can exist in an NFAS group. D channels are marked as primary, backup, or none.
NOTE
The NFAS considerations shown for a dial environment are fully applicable to the NFAS conguration and utilization rules as in an ISDN environment.
Each PRI and each NFAS group has a serial interface that corresponds to it and that needs to be congured. The serial interface number is the same as the controller number of the circuit with the D channel, with a :23 appended to the end of it. This is done because the D channel on a PRI is the 24th channel, starting with channel number 0refer to Figure 2-9 in Chapter 2. In the case of an NFAS group, the only serial interface that exists is the one with the D channel. The serial interface for the previously congured NFAS group is shown here:
5300-dialin(config)#interface Serial0:23 5300-dialin(config-if)#isdn switch-type primary-4ess 5300-dialin(config-if)#isdn incoming-voice modem 5300-dialin(config-if)#no shutdown
The serial interface contains a few components that must be set:
The rst component to be congured is the switch type, which needs to match what the telephone company congured on their side of the circuit. Next, the command isdn incoming-voice modem is crucial, as it tells the router that any voice call (non-ISDN) must be sent to a modem. Finally, you must bring the interface up with the no shutdown command. The NFAS group is congured the same way:
5300-dialin(config)#interface Serial4:23 5300-dialin(config-if)#isdn switch-type primary-4ess 5300-dialin(config-if)#isdn incoming-voice modem 5300-dialin(config-if)#no shutdown
That completes the conguration for a large-scale dial-in service. Example 6-11 shows the full conguration, including four PRI and one NFAS group that contains four circuits.
Example 6-11 Large-Scale Dial-In Conguration
version 12.2 service timestamps debug uptime service timestamps log uptime no service password-encryption ! hostname 5300-dialin ! boot system flash aaa new-model !
continues
162
Example 6-11 Large-Scale Dial-In Conguration (Continued)

aaa group server radius auth server 192.168.100.1 auth-port 1645 acct-port 1646 server 192.168.100.2 auth-port 1645 acct-port 1646 ! aaa authentication login dial group auth aaa authentication login testing local-case group auth aaa authentication ppp dial if-needed group auth aaa authentication ppp testing if-needed local-case group auth aaa session-id common ! ip subnet-zero ! async-bootp subnet-mask 255.255.255.0 async-bootp gateway 192.168.1.1 async-bootp dns-server 192.168.100.3 192.168.100.4 async-bootp nbns-server 192.168.100.5 192.168.100.6 ! ! Begin controller configurations: controller T1 0 framing esf clock source line primary linecode b8zs pri-group timeslots 1-24 ! controller T1 1 framing esf clock source line secondary linecode b8zs pri-group timeslots 1-24 ! controller T1 2 framing esf linecode b8zs pri-group timeslots 1-24 ! controller T1 3 framing esf linecode b8zs pri-group timeslots 1-24 ! ! NFAS configuration with primary and backup interfaces specified respectively: controller T1 4 framing esf linecode b8zs pri-group timeslots 1-24 nfas_d primary nfas_int 0 nfas_group 0 ! controller T1 5 framing esf clock source line primary linecode b8zs pri-group timeslots 1-24 nfas_d backup nfas_int 1 nfas_group 0 !
163

controller T1 6 framing esf clock source line primary linecode b8zs pri-group timeslots 1-24 nfas_d none nfas_int 2 nfas_group 0 ! controller T1 7 framing esf clock source line primary linecode b8zs pri-group timeslots 1-24 nfas_d none nfas_int 3 nfas_group 0 ! interface Loopback0 ip address 192.168.1.1 255.255.255.0 ! interface Ethernet0/0 ip address 192.168.0.246 255.255.255.252 ! interface Serial0:23 no ip address isdn switch-type primary-4ess isdn incoming-voice modem ! interface Serial1:23 no ip address isdn switch-type primary-4ess isdn incoming-voice modem ! interface Serial2:23 no ip address isdn switch-type primary-4ess isdn incoming-voice modem ! interface Serial3:23 no ip address isdn switch-type primary-4ess isdn incoming-voice modem ! ! The D-channel of this T1 is configured as a primary D-channel. ! When this channel goes down, the T1 #5, which is configured as a ! backup D-channel, inherits this configuration. interface Serial4:23 no ip address isdn switch-type primary-4ess isdn incoming-voice modem ! ! Serial 5:23, 6:23 and 7:23 interfaces dont need to be configured, because ! T1 5, T1 6 and T1 7 belong to the NFAS group. interface Group-Async1 ip unnumbered Loopback0
continues
164

encapsulation ppp async mode interactive peer default ip address pool dialpool ppp authentication pap dial group-range 1 240 ! ip local pool dialpool 192.168.1.2 192.168.1.254 ip classless ip route 0.0.0.0 0.0.0.0 192.168.0.245 ! radius-server host 192.168.100.1 auth-port 1645 acct-port 1646 timeout 18 key a10u8 radius-server host 192.168.100.2 auth-port 1645 acct-port 1646 timeout 18 key a10u8 radius-server retransmit 3 ! line con 0 exec-timeout 0 0 line 1 240 login authentication dial modem InOut modem autoconfigure type mica autocommand ppp default autoselect during-login autoselect ppp speed 115200 line aux 0 line vty 0 4 ! end
Text Dial-Out Conguration

For a text dial-out service, you must rst make a decision on whether to use local authentication on the router or to use an authentication server. These users do not call into the modems, so security is probably not as much of a concern as a dial-in pool. In the case of dial-out, the user connects through text on a VTY port, which means that the type of authentication is login. A small ctitious insurance company is used as the example. The company has eight WAN sites, all on dedicated links, and there is no backup implemented because of costs. The routers at each of the WAN sites have modems attached to the AUX ports, and an analog line attached to the modem, so that in the case of any site going down, support personnel can log into the WAN router to troubleshoot the connection from both ends. There are only four headcounts to support the network, so they choose to use local authentication on the router. For a larger company, this could easily be changed to allow for an authentication server. The conguration lines in Example 6-12 specify the authentication component. The name given to the authentication type is dialout, and it uses local passwords. Usernames and passwords are also congured.
165
Example 6-12 Local Authentication Conguration

3600-dialout(config)#aaa new-model 3600-dialout(config)#aaa authentication login dialout local 3600-dialout(config)#username jbrown password james 3600-dialout(config)#username jbob password joe 3600-dialout(config)#username ksmith password keith 3600-dialout(config)#username wclark password will
Because of the size of the company, the dial numbers are in the incoming banner to make it easy for anyone to place a call to a site that is down. Therefore, when a support person logs in, that person has all the numbers for the WAN sites listed. They assume that no more than one or two sites would ever be down at once, so they planned the dial-out server to handle three outbound connections at once, thus placing three modems in the dial-out rotary (in this case, lines 1-2). The conguration lines in Example 6-13 provide the authentication for the three dial-out lines. Also, the banner is put in place listing the ofce console phone numbers.
Example 6-13 Authentication and Banner Conguration
3600-dialout(config)#line 1 3 3600-dialout(config-line)#login authentication dialout 3600-dialout(config-line)#exit 3600-dialout(config)#Banner incoming ^ Enter TEXT message. End with the character ^. Site Router Console Number --------------------------------------------------Dallas Office 231-444-8282 Oakland Office 415-663-9012 Las Vegas Office 772-404-9923 Minneapolis Office 416-223-9245 St. Louis Office 314-677-4378 Chicago Office 294-229-3943 New York Office 723-655-8966 Atlanta Office 404-339-6774 Use modem AT commands to dial-out. ^
Next, congure the modem lines for a typical dial-out setup. In this case, the requirement is for databits set to 8, stopbits set to 1, and parity set to none. Also, set up the lines in rotary group number one, and set the input to be telnet, which sets the router up to allow a reverse telnet directly onto the modem. Finally, turn off exec, which does not allow a router prompt to anyone who tries to dial into this server. Example 6-14 shows dial-out modem conguration commands for a typical text dial-out router.
166
Example 6-14 Text Dial-Out Line Conguration

3600-dialout(config)#line 1 3 3600-dialout(config-line)#databits 8 3600-dialout(config-line)#parity none 3600-dialout(config-line)#stopbits 1 3600-dialout(config-line)#modem host 3600-dialout(config-line)#rotary 1 3600-dialout(config-line)#transport input telnet 3600-dialout(config-line)#no exec
Then, you must give the router an IP address and put it on the network:
3600-dialout(config)#interface Ethernet0/0 3600-dialout(config-if)#ip address 192.168.0.10 255.255.255.248
Use another IP address on the Ethernet segment to create an alias to the rotary group, by using the following command:
3600-dialout(config)#ip alias 192.168.0.11 3001
Telnet to the Ethernet address on port 3001 and connect to the rst available modem in rotary group 1. This command allows direct telnet to 192.168.0.11 by using the default port (23), and it connects as if they telnet to port 3001 on the Ethernet address. Port 3002 lands on rotary group number two, which is not congured. Example 6-15 shows the nal conguration used for this small company to access their WAN routers in the event that the WAN links are down.
Example 6-15 Text Dial-Out Conguration
version 12.2 service timestamps debug datetime msec service timestamps log uptime service password-encryption ! hostname 3600-dialout ! aaa new-model ! ! aaa authentication login dialout local aaa session-id common enable secret 5 $1$VzVJ$B6sbqGo8e2HJDBQ.gxGZp/ ! ! Local username and password files for local login as specified by ! aaa authentication login dialout local configuration command. username jbrown password 7 000E120B0148 username jbob password 7 020C0B5E username ksmith password 7 050003063544 username wclark password 7 02110D5707 ! ip subnet-zero
167
Example 6-15 Text Dial-Out Conguration (Continued)

! interface Ethernet0/0 ip address 192.168.0.10 255.255.255.248 ! ip classless ip route 0.0.0.0 0.0.0.0 Ethernet0/0 192.168.0.9 ip alias 192.168.0.11 3001 no ip http server ! banner incoming ^ Site Router Console Number --------------------------------------------------Dallas Office 231-444-8282 Oakland Office 415-663-9012 Las Vegas Office 772-404-9923 Minneapolis Office 416-223-9245 St. Louis Office 314-677-4378 Chicago Office 294-229-3943 New York Office 723-655-8966 Atlanta Office 404-339-6774 Use modem AT commands to dial-out. ^ ! line con 0 line 1 3 no exec login authentication dialout modem autoconfigure type nextport rotary 1 transport input telnet stopbits 1 speed 115200 line aux 0 line vty 0 4 ! end
Now that the router is congured, it must be tested. If you do not see characters appearing when you type AT and press Enter, but you do see OK being returned, the modem is not echoing local commands, but all else works correctly. Consult the owners manual for the modem to turn this feature on. Example 6-16 shows the dial-out test being performed. In the example, a call is placed to the WAN router in Atlanta.
Example 6-16 Text Dial-Out Test to Verify Functionality
Trying 192.168.0.11 ... Open User Access Verification
continues
168
Example 6-16 Text Dial-Out Test to Verify Functionality (Continued)

Username: jbrown Password: Site ----------------------Dallas Office Oakland Office Las Vegas Office Minneapolis Office St. Louis Office Chicago Office New York Office Atlanta Office Router Console Number ----------------------------231-444-8282 415-663-9012 772-404-9923 416-223-9245 314-677-4378 294-229-3943 723-655-8966 404-339-6774
Use modem AT commands to dial-out. at OK atdt14043396774 CONNECT 26400/REL atlanta-wan line 65 User Access Verification Username: jbrown Password: atlanta-wan>exit NO CARRIER
The call was placed when user jbrown typed atdt14043396774. It was successfully answered when the modem echoed CONNECT 26400/REL. At that point, the atlanta-wan router asked for authentication. User jbrown logged in and everything worked as planned.
PPP Dial-Out Conguration

The following PPP dial-out conguration section refers to the second type of PPP dial-out mentioned earlier in this chapter, where the router dials into a service provider to gain access to the LAN behind the router. First, a xed password is required for this type of conguration, and you must gather a few pieces of information about your service provider. Dialup the provider with a PC and gather the DNS server addresses, the WINS server addresses (if any), and the domain name assigned to you. Unless you previously arranged to route a network to the service provider, you must use NAT on the router to provide all the computers on your LAN access to the Internet. This
169
example uses NAT and the modem is an external US Robotics Sportster that is attached to the AUX port of a router. Start by assigning an RFC 1918 subnet to your local network. Give an IP address from this network to the Ethernet interface, and set up Dynamic Host Conguration Protocol (DHCP) for the client computers as shown in Example 6-17.
Example 6-17 Conguration of DHCP on a Local LAN Segment
2500-dialout(config)#interface Ethernet 0/0 2500-dialout(config-if)#ip address 192.168.1.1 255.255.255.0 2500-dialout(config-if)#no shutdown 2500-dialout(config-if)#ip dhcp pool pool1 2500-dialout(dhcp-config)#network 192.168.1.0 255.255.255.0 2500-dialout(dhcp-config)#default-router 192.168.1.1 2500-dialout(dhcp-config)#dns-server 207.217.126.41 207.217.77.42 2500-dialout(dhcp-config)#domain-name earthlink.net
In this case, no WINS servers are congured because the ISP does not offer these services. If they had assigned WINS servers, you would use the DHCP conguration command netbios-name-server ip_address_1 ip_address_2 to congure them on your router. The next action is to put the service provider information into the async interface. The phone number to dial, along with a username and password, is also required. In this example, the router dials up to a typical service provider where the IP address is supplied. The interface is set up to be in dialer-group 1. Also, a dialer hold-queue is added to queue packets in case the modem speedshifts, retrains, or needs to completely reconnect. Example 6-18 shows the conguration lines needed to dial into the providers network.
Example 6-18 Async Interface Conguration for PPP Dial-Out Access
2500-dialout(config)#interface async65 2500-dialout(config-if)#ip address negotiated 2500-dialout(config-if)#dialer in-band 2500-dialout(config-if)#dialer string 6222230 2500-dialout(config-if)#encapsulation ppp 2500-dialout(config-if)#ppp pap sent-username jhuegen password test 2500-dialout(config-if)#dialer-group 1 2500-dialout(config-if)#dialer hold-queue 100
Congure the line for dial-out and set up the modem through the autocongure command. Additionally, you might include the no exec command for security reasons. This prevents someone from connecting if they try to dial into the router:
2500-dialout(config)#line aux 0 2500-dialout(config-line)#modem autoconfigure type usr_sportster 2500-dialout(config-line)#modem InOut 2500-dialout(config-line)#no exec
170
Next, congure NAT so that trafc on the Ethernet interface translates to the IP address negotiated for the async interface:
2500-dialout(config)#access-list 1 permit 192.168.1.0 0.0.0.31 2500-dialout(config)#ip nat inside source list 1 interface asy65 overload
Then, assign NAT as either inside or outside to all congured interfaces, and congure a default route to the service provider, as shown in Example 6-19.
Example 6-19 NAT Inside, NAT Outside, and Default Route Conguration Commands
2500-dialout(config)#interface async65 2500-dialout(config-if)#ip nat outside 2500-dialout(config-if)#exit 2500-dialout(config)#interface ethernet0/0 2500-dialout(config-if)#ip nat inside 2500-dialout(config-if)#exit 2500-dialout(config)#ip route 0.0.0.0 0.0.0.0 async65
Finally, identify on the router what trafc to mark as interesting, which limits the trafc allowed to bring up the line. In this example, all IP trafc is identied as interesting. You can use an access control list (ACL) to only allow certain types of trafc with the command dialer-list 1 protocol ip list access-list-number:
2500-dialout(config-if)#dialer-list 1 protocol ip permit
This completes the conguration for PPP dial-out to a service provider. The full conguration is shown in Example 6-20.
Example 6-20 PPP Dial-Out Conguration for Connecting to a Service Provider
version 12.2 service timestamps debug datetime msec service timestamps log uptime service password-encryption ! hostname 2500-dialout ! boot system flash ! enable secret 5 $1$VzVJ$B6sbqGo8e2HJDBQ.gxGZp/ ! ip subnet-zero ! ! local DHCP service configuration parameters: ip dhcp pool pool1 network 192.168.1.0 255.255.255.0 default-router 192.168.1.1 dns-server 207.217.126.41 207.217.77.42 netbios-name-server 207.217.126.42 207.217.77.43 domain-name earthlink.net !
171
Example 6-20 PPP Dial-Out Conguration for Connecting to a Service Provider (Continued)
interface Ethernet0/0 ip address 192.168.1.1 255.255.255.0 ip nat inside ! interface Async65 ip address negotiated ip nat outside encapsulation ppp dialer in-band dialer string 6222230 dialer hold-queue 100 dialer-group 1 ppp pap sent-username jhuegen password 7 044F0E151B ! ! NAT configuration with default route identified: ip nat inside source list 1 interface Async65 overload ip classless ip route 0.0.0.0 0.0.0.0 Async65 ! ! Access list configured to allow traffic to/from your Ethernet interface: access-list 1 permit 192.168.1.0 0.0.0.31 dialer-list 1 protocol ip permit ! line con 0 line aux 0 no exec modem InOut modem autoconfigure type usr_sportster line vty 0 4 ! end
Large-Scale Dial-Out Conguration

Two types of large-scale dial-out congurations exist. The rst uses static dialer maps put into a dialer interface, where they exist within the router conguration. The second type uses the AAA system for storing the dialer maps. In the rst example that follows, static dialer maps dial out to each individual client. The number of congurable clients is limited by the size of the conguration. After the conguration is full, no more clients can be added. Although this limitation exists, it is still the easiest way to prepare for large-scale dial-out. Example 6-21 shows a sample Group-Async interface conguration with dialer maps for large-scale dial-out.
172
Example 6-21 Large-Scale Dial-Out Interface Conguration with Dialer Map Statements
5300-dialout(config)#interface Group-Async1 5300-dialout(config-if)#ip address 64.221.12.1 5300-dialout(config-if)#encapsulation ppp 5300-dialout(config-if)#dialer in-band 5300-dialout(config-if)#dialer idle-timeout 30 5300-dialout(config-if)#dialer map ip 64.221.12.2 name ID127361 16632047789 5300-dialout(config-if)#dialer map ip 64.221.12.3 name ID127364 17366224431 5300-dialout(config-if)#dialer map ip 64.221.12.4 name ID127365 12232718341 5300-dialout(config-if)#dialer map ip 64.221.12.5 name ID127367 12812123434 <output omitted> 5300-dialout(config-if)#dialer map ip 64.221.12.253 name ID196458 14732812238 5300-dialout(config-if)#dialer map ip 64.221.12.254 name ID196459 15123848161 5300-dialout(config-if)#dialer hold-queue 100 5300-dialout(config-if)#dialer-group 1
As you can see, this can take up much space in the conguration. There is also a manageability issue with removing old customers and adding new ones because it is a manual and time-consuming process. Unfortunately, theres no easy way to keep a conguration like this up to date. This limitation is where a AAA large-scale dial-out setup is an alternative because AAA is already in a database format. Therefore, you can add information to this database that can be used for other purposes, such as billing and running reports against active and non-active customers. To set up a large scale dial-out in this manner, the AAA database must be populated with the phone numbers and IP addresses of the remote hosts. The router must be set up for either TACACS+ or RADIUS authentication. TACACS+ is used in the following example:
5300-dialout(config)#aaa 5300-dialout(config)#aaa 5300-dialout(config)#aaa 5300-dialout(config)#aaa new-model authentication ppp default group tacacs+ authorization network default group tacacs+ authorization configuration default group tacacs+
The Group-Async interface is congured as in the earlier example; however, instead of the dialer map statements, you use the command dialer aaa. Example 6-22 shows the conguration of the Group-Async interface using AAA for large-scale dial-out.
Example 6-22 Group-Async Interface Using AAA for Large-Scale Dial-Out
5300-dialout(config)#interface Group-Async1 5300-dialout(config-if)#ip address 64.221.12.1 5300-dialout(config-if)#encapsulation ppp 5300-dialout(config-if)#dialer in-band 5300-dialout(config-if)#dialer idle-timeout 30 5300-dialout(config-if)#dialer aaa 5300-dialout(config-if)#dialer hold-queue 100 5300-dialout(config-if)#dialer-group 1
173
Finally, use the following command to download all the routes from the AAA server. In the example, its set to update the downloaded table every 60 minutes; however, you might opt for a different frequency (remember that the size of the table can make this an intensive process):
5300-dialout(config)#aaa route download 60
To verify that everything works correctly, turn on terminal monitoring. A temporary debug comes up with the important information about this particular call. Example 6-23 shows the temporary debug. If this does not happen, turn on other AAA debugs to determine the problem.
Example 6-23 Large-Scale Dial-Out Temporary Debug
5300-dialout#ping 64.221.12.253 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 64.221.12.253, timeout is 2 seconds: Mar 9 03:59:35.173: %LSdialout: temporary debug to verify the data integrity Mar 9 03:59:35.177: dial number = 14732812238 Mar 9 03:59:35.177: dialnum_count = 1 Mar 9 03:59:35.177: force_56 = 0 Mar 9 03:59:35.181: routing = 0 Mar 9 03:59:35.181: data_svc = -1 Mar 9 03:59:35.181: port_type = -1 Mar 9 03:59:35.185: map_class = Mar 9 03:59:35.185: ip_address = 64.221.12.253 Mar 9 03:59:35.189: send_secret = hs7BsL1p Mar 9 03:59:35.189: send_auth = 3
You have now veried that the dial-out server is collecting the correct information from the AAA server to perform a successful dial-out. From here, basic PPP dial-out must take place for trafc to pass.
Dial-On-Demand Backup Conguration

In the conguration example provided, a WAN router is used with a fractional T1 to the main ofce and a modem for DDR. When the fractional T1 goes down, you want the modem to place a call to the DDR server at the main ofce and continue to support the ow of trafc. Although it is not the easiest to congure, using dialer watch is an effective way to perform dial-on-demand backup. Dialer watch checks on a route that is supposed to be in the routing table, and if the route disappears for any reason, the router believes it is disconnected from the network and dials. First, you want the router to watch a route that is up as long as the circuit back to headquarters is up. The easiest way to do this is to put a loopback address on the router on the
174
other end of the circuit. Then, use a routing protocol to propagate that route through the fractional T1 to the router at the WAN site (the one you are conguring). In this case, EIGRP 68 propagates the route for the loopback address 64.213.9.10:
<output omitted> D 64.213.9.10/32 [90/409600] via 64.213.8.41, 00:05:20, Serial0/2.10 <output omitted>
Then set up dial-on demand with a dialer-map statement to connect to the hq-ddr router that accepts calls for backup. The router uses Challenge-Handshake Authentication Protocol (CHAP) authentication with a local username and password. Example 6-24 shows the conguration for dialing and authenticating through CHAP to the hq-ddr router.
Example 6-24 Conguration to Dial and Authenticate to hq-ddr
3600-ddr(config)#aaa authentication ppp default local ! Local username and password for hq-ddr: 3600-ddr(config)#username hq-ddr password helpme 3600-ddr(config)#interface async65 3600-ddr(config-if)#ip address 64.213.10.12 255.255.255.240 3600-ddr(config-if)#encapsulation ppp 3600-ddr(config-if)#dialer in-band ! Maps ip for hq-ddr with calling number for access: 3600-ddr(config-if)#dialer map ip 64.213.10.1 name hq-ddr 16686222230 3600-ddr(config-if)#dialer hold-queue 100 3600-ddr(config-if)#dialer-group 1 3600-ddr(config-if)#ppp authentication chap
Next, verify that the route you want to monitor is in the routing table. To do this, issue the command show ip route ip address. After it is veried, proceed with conguring the rest of the dialer watch commands. The rst of the commands required for dialer watch sets the idle-timeout on the link to 30 seconds. The link does not disconnect every 30 seconds, but instead checks to determine if the route to the watched IP address specied is in place every 30 seconds:
3600-ddr(config-if)#dialer idle-timeout 30
Next, add a dialer map for the watched IP address by using the same name and phone number as the one congured earlier. This tells the router where to dial when the watched IP address is removed from the routing table:
3600-ddr(config-if)#dialer map ip 64.213.9.10 name hq-ddr 16686222230
Then, add the interface to a watch group. Because no watch groups were dened before, start with group number 1 (one):
3600-ddr(config-if)#dialer watch-group 1
Create a dialer watch list that includes the IP address that you want to watch:
3600-ddr(config)#dialer watch-list 1 ip 64.213.9.10 255.255.255.255
175
Finally, set all trafc to non-interesting:

3600-ddr(config)#dialer-list 1 protocol ip deny
The interface dials based on whether or not the watched IP address is in the routing table, not based on whether the trafc is interesting or not. This is an added measure to keep the dial-on-demand link down whenever it is not needed. Example 6-25 shows the nal conguration of this WAN router using dial-on-demand backup.
Example 6-25 Dial-on-Demand Conguration Using Dialer Watch
version 12.2 service timestamps debug datetime msec service timestamps log uptime service password-encryption ! hostname 3600-ddr ! boot system flash aaa new-model ! aaa authentication ppp default local ! enable secret 5 $1$VzVJ$B6sbqGo8e2HJDBQ.gxGZp/ ! username hq-ddr password 7 08294942191400 ! ip subnet-zero ! interface Ethernet0/0 ip address 64.213.11.193 255.255.255.192 no keepalive ! interface Serial0/2 bandwidth 256 no ip address encapsulation frame-relay IETF frame-relay lmi-type ansi ! interface Serial0/2.10 point-to-point bandwidth 256 ip address 64.213.8.42 255.255.255.252 no arp frame-relay frame-relay interface-dlci 20 ! ! Specifies watch-group and hq-ddr numbers for backup: interface Async65 ip address 64.213.10.12 255.255.255.240 encapsulation ppp dialer in-band dialer idle-timeout 30 dialer map ip 64.213.10.1 name hq-ddr broadcast 16686222230
continues
176
Example 6-25 Dial-on-Demand Conguration Using Dialer Watch (Continued)

dialer map ip 64.213.9.10 name hq-ddr broadcast 16686222230 dialer hold-queue 100 dialer watch-group 1 dialer-group 1 ppp authentication chap ! router eigrp 68 network 64.213.8.0 0.0.3.255 no auto-summary ! ip classless ! no ip http server ! ! Watch-list to match watch-group already specified on Async interface: access-list 1 permit 192.168.0.0 0.0.0.31 dialer watch-list 1 ip 64.213.9.10 255.255.255.255 dialer-list 1 protocol ip deny ! line con 0 exec-timeout 0 0 line aux 0 modem InOut modem autoconfigure type usr_sportster speed 115200 line vty 0 4 ! end
Example 6-26 is a debug to show you what happens during an outage, and what happens when the primary circuit comes back up. To simulate this force, the serial interface goes down by unplugging the cable.
Example 6-26 Dial-on-Demand Routing DebugPart I
00:12:38: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/2.10, changed state to down Mar 1 00:12:38.023: DDR: Dialer Watch: watch-group = 1 Mar 1 00:12:38.023: DDR: network 64.213.9.10/255.255.255.255 DOWN, Mar 1 00:12:38.023: DDR: primary DOWN Mar 1 00:12:38.023: DDR: Dialer Watch: Dial Reason: Primary of group 1 DOWN Mar 1 00:12:38.023: DDR: Dialer Watch: watch-group = 1, Mar 1 00:12:38.023: DDR: dialing secondary by dialer map 64.213.9.10 on As65 Mar 1 00:12:38.023: As65 DDR: Attempting to dial 16686222230
This starts a typical PPP dial-out connection and after it is authenticated, the network continues passing trafc through the DDR system. Example 6-27 shows what occurs when the serial interface is xed and comes back up; in this case, you plug the cable back in.
Review Questions
177
Example 6-27 Dial-on-Demand Routing DebugPart II

00:13:20: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/2.10, changed state to up Mar 1 00:13:21.819: DDR: Dialer Watch: watch-group = 1 Mar 1 00:13:21.819: DDR: network 64.213.9.10/255.255.255.255 UP, Mar 1 00:13:21.819: DDR: primary UP
Shortly following, the call is disconnected and trafc resumes over the serial interface.
Summary
This chapter is divided into two separate sections that cover dial design solutions and dial conguration solutions. The dial design solutions section covered the essentials of dial-in network connectivity, dial-out network connectivity, and DDR along with dial-out for support purposes and largescale dial-out services. The dial conguration solutions section provided detailed information about common and specic dial congurations, including the following:
Text dial-in conguration PPP dial-in conguration Large-scale dial-in conguration Text dial-out conguration PPP dial-out conguration Large-scale dial-out conguration Dial-on-demand backup conguration
Before the troubleshooting process starts, it is important to understand entirely the design and conguration specics of the dial solution. This gives you a better understanding of the troubleshooting methodology thats used for dial in the next chapter.
Review Questions
1 List three ways for using dial as a backup solution. 2 What is the main advantage of the dialer watch solution? 3 What is the line conguration command to congure a modem to use the modemcap
usr_sportster?
178
4 What is the global conguration command to dene a group named dial as a
TACACS+ group?
5 What is the default protocol and port number of RADIUS authentication and
accounting?
6 What is the line conguration command to automatically select the PPP protocol
during text authentication?

7 What is NFAS and what is its function? 8 What is the interface conguration command to ensure that voice calls are sent to a
modem?
9 What is the purpose of the command no exec? 10 What is the best way to test a backup solution? 11 How would you connect to a network access server to connect as a text dial-out
device?
12 True or False: PC software is required to use a router to perform PPP dial-out. 13 What is the most scaleable way to use large-scale dial-out? 14 What is the main purpose of a group-async interface? 15 What does the interface command group-range do?
CHAPTER
Dial Troubleshooting
The troubleshooting approach in this chapter demonstrates the layer-by-layer and phaseby-phase approach to dial issues. It is important to be systematic and go step-by-step, starting with the physical layer from both ends. Unlike service provider-based remote access solutions, both ends of the connection are available for troubleshooting in an enterprise remote access scenario. This chapter focuses on the following main topics:
Detailed troubleshooting network access server (NAS) wide-area network (WAN) links, including T1 circuits and PRIs Troubleshooting dial-in services Troubleshooting dial-out services Specic commands and debugs for NAS 5x00 routers, including Cisco 5200, 5300, and 5400
With this chapter, you can enhance your knowledge about T1s and PRIs. This information is relevant to all parts of this book and should be reviewed as necessary. The dial-in and dial-out troubleshooting techniques are explained in detail, from the viewpoint of the NAS, which gives you the best understanding about the nature of the processes. Troubleshooting the modem operational status is demonstrated in great detail. The specics of the different platforms provided in this chapter should help you to improve your skill set in dial technology.
Troubleshooting NAS WAN Links

A NAS is the key piece of equipment that accepts incoming calls, authenticates the caller, and routes trafc for each call. The NAS is connected to the telephone company cloud by using a variety of leased lines that range from Basic Rate Interfaces (BRIs) to digital service 3s (DS3s). Typical design solutions include T1s and Primary Rate Interfaces (PRIs), which is why more detailed explanations about troubleshooting them are included in this section.
Troubleshooting T1 Circuits
When you notice a problem with a T1 line, its recommended that you start troubleshooting with the core end to determine where the problem exists. Start with the physical layer rst.
182
Chapter 7: Dial Troubleshooting
Controller and Line Status

Start with the physical condition and integrity of the T1 line. Always check the status of the T1 controllers and verify that you do not receive any errors. The command that displays the status is show controllers t1, as shown in Example 7-1.
Example 7-1 Output of the Command show controllers t1
5300-dial#show controllers t1 0 ! The circuit is up according to the next line: T1 0 is up. Applique type is Channelized T1 ! Cable length is shown next. If the circuit is not long, it needs to ! be configured differently: Cablelength is long gain36 0db Description: T1 with Pacific Bell. ! Alarms are shown in the next line. ! If an alarm exists, there is a major problem in the circuit: No alarms detected. Version info of slot 0: HW: 1, PLD Rev: 11 Framer Version: 0x8 Manufacture Cookie Info: EEPROM Type 0x0001, EEPROM Version 0x01, Board ID 0x48, Board Hardware Version 1.0, Item Number 800-3883-01, Board Revision A0, Serial Number 11692119, PLD/ISP Version 0.1, Manufacture Date 6-May-1999. Framing is ESF, Line Code is B8ZS, Clock Source is Line Secondary. ! The following 4 lines show that no errors occurred in the last 10 seconds: Data in current interval (10 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 ! The following 4 lines show a mostly clean line, but there ! were 9 Slip Seconds and 9 Errored Seconds in the last 24 hours: Total Data (last 24 hours) 0 Line Code Violations, 0 Path Code Violations, 9 Slip Secs, 0 Fr Loss Secs, 0 Line Err Secs, 0 Degraded Mins, 9 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 0 Unavail Secs
The rst line shows line status and tells you if the T1 is either up, down, or administratively down. The rst section of the output also alerts you of any alarms that are on the circuit. On the next line, you nd your congured cable length. Make sure that this is congured correctly. If the observed output is not correct, the following options are available under the controller conguration mode:
5300-dial(config-controller)#cablelength {long [gain26 | gain36] [0db | -7.5db | -15db | -22.5db] | short [133 | 266 | 399 | 533
655]}
183
Cable length is dened as either long or short with long being anything over 655 feet in length. Length is the distance of the entire circuit from the closest repeater or switch to the NAS. In most cases, the closest repeater is not local, so you use the default long with a gain or a boost of 36 decibels (gain36). For shorter long cable lengths, the signal is stronger and you might only need gain26. The second part of dening a long cable length is transmitting attenuation. The default is 0db, which is the strongest transmit signal. If the circuit provider tells you that your signal is too strong, you can lower the transmit signal by using 7.5db, -15db, or 22db. A short cable length is dened in distance by feet from the NAS and closest repeater. You use the value of 133 for distances that range from 1 foot to 133 feet. The value of 266 is for distances that range from 134 to 266 feet. For distances of 267 to 399 feet, use 399. Use 533 for distances from 400 to 533. Finally, use 655 for anything between 534 and 655 feet in length.
NOTE
In modular routers (7200, 1600, and 1700 series), the command show service-module serial slot/port provides detailed information about the condition of the line. Examples of this command are included in Chapter 17, Frame Relay Troubleshooting.
Loopback Features
If you have difculty with any of Ciscos DS1 adapters or network modules with an internal CSU, you can troubleshoot by using the loopback command. The three main loopback modes that are congurable are diagnostic, local, and remote. Local loopback can be congured as either line or payload. Remote loopback can be congured as in-band bitoriented code (IBOC) or Extended Superframe (ESF). Specify the loopback format using one of the following controller conguration commands:
5300-dial(config-controller)#loopback [diagnostic | local | remote] 5300-dial(config-controller)#loopback [local {payload | line}] 5300-dial(config-controller)#loopback [remote {esf line | iboc | esf paylaod}]
Check Bit Errors with a Bit Error Rate Tester

A bit error rate tester (BERT) alerts you of any issues on the line. Although a circuit can be operational and passing data, some data might be awed, which can be detected by using a BERT. A BERT is not an available option on every piece of Cisco hardware. If the option is not available, the proper way to perform this test is to put a tester directly on the circuit. To use a BERT to check for bit errors, if the router supports it, use the following controller conguration command:
5300-dial(config-controller)# bert pattern test pattern interval minutes
184
The available options for test pattern are the following:
0sAll 0s test pattern 1sAll 1s test pattern 2^112^11-1 test pattern 2^152^15-1 O.151 test pattern 2^20-O1532^20-1 O.153 test pattern 2^20-QRSS2^20-1 QRSS O.151 test pattern 2^232^23-1 O.151 test pattern alt-0-1Alternating 0s and 1s test pattern 2^15 is an exponential number that represents a pseudo-random repeating pattern that is 32,767 bits long. 2^20 is a pseudo-random repeating pattern that is 1,048,575 bits long. 2^23 is a pseudo-random repeating pattern that is 8,388,607 bits long. 0s is a pattern of all 0s. 1s is a pattern of all 1s.
A further explanation of the most commonly used BERT test patterns include the following:
The minutes argument can be 1-14400, which designates the time that the BERT runs. BERT testing can only be done over a framed T1 signal. The test cannot run if the T1 is in an alarm state where Receiver has loss of frame (or signal). Additionally, it can only be run on one port at a time.
Physical Layer Alarms

The alarm section of the output from show controllers t1 is important as it tells you what type of problem might be present on the line. The presence of any alarm indicates a serious problem on the line (see Figure 7-1 and Table 7-1). In Figure 7-1, each WAN link is represented by a pair of cross-connected receivers and transmitters.
185
Figure 7-1
A Functional Model of Physical Layer Alarm Messages

Upstream Alarms Declared T R T1, T3, or SONET T R Incoming Signals Downstream T1, T3, or SONET Controller
LAN Interface
The Cloud
R T Cross-Connect Switch
T: Transmitter R: Receiver - A Red Alarm is declared because of an incoming Loss of Signal, Loss of Framing, or Alarm Indication Signal. - A Yellow Alarm is declared because of an incoming yellow signal from the far end. In effect, the circuit is declared to be a one-way link. - A Blue Alarm is declared because of incoming Alarm Indication Signal (AIS). The Blue Alarm indicates a problem upstream. If you shut down one side of the connection, a Blue Alarm is sent to the other side.
When you have a T1 in an alarm state, verify that the framing and linecoding parameters are congured correctly. A common message in the alarm eld is receiver has loss of frame. Some routers also report a loss of frame (LOF) even when it should be a loss of signal (LOS). Therefore, ensure whenever you receive these errors that the T1 signal is present and the framing is correct. There are three types of alarms:
Blue alarmAnother message you might receive is that the receiver is getting an Alarm Indication Signal (AIS), which means that a blue alarm indication signal is received. This generally indicates that there is a problem upstream. This is a framed or unframed all-ones signal, in both SF and ESF formats, which is transmitted to maintain transmission continuity. It typically occurs when the far-end channel service unit (CSU) has lost its terminal side equipment. For example, if you shut down your side of the connection, a blue alarm is sent to the remote side. Yellow alarmThe receiver has a remote alarm that indicates the presence of a yellow alarm. This means that the downstream CSU is in a LOF or LOS state. It is also a remote site alarm indication (RAI). When the receiver experiences LOS, the transmitter sends a yellow alarm. For SF-formats, a remote alarm is declared when bit 6 on all channels is set to 0 for at least 35 seconds. The alarm is cleared if the same bit is non-zero for 5 seconds or less (usually 1 second). When the format is ESF, a remote alarm indicates if the yellow alarm pattern exists in at least seven out of ten continuous 16-bit intervals. The alarm is cleared if this condition no longer exists for the same time intervals. Red alarmAnother typical failure is called a red alarm. A red alarm is usually indicated on the opposite end of the yellow alarm. The red alarm means that the receiver experiences LOS, LOF, or an AIS. A LOS failure is dened in RFC 1406 as is declared upon observing 175 +/- 75 contiguous pulse positions with no pulses of either positive or negative polarity. The LOS failure is cleared upon observing an
186
average pulse density of at least 12.5% over a period of 175 +/- 75 contiguous pulse positions starting with the receipt of a pulse. For E1 links, the LOS failure is declared when greater than 10 consecutive zeroes are detected. After a red alarm is declared, the device sends a yellow signal to the far end. When the far end receives the yellow signal, it declares a yellow alarm. This message is accompanied by a receiver has loss of frame message. Always verify the framing and T1 signal when troubleshooting.
TIP
NOTE
Regardless of the leased line connection that you are troubleshooting, whether a T1, T3, or Synchronous Optical Network (SONET), the alarm signals and their interpretations remain the same. The alarm states are always based on the presence or lack of signals or certain patterns. This is why the alarm states in this section apply to all circuits in the book.
Linecode Violations
These violations occur when either a bipolar violation (BPV) or excessive zero error event is present. BPVs are inserted as a means of synchronizing circuits with bipolar 8-zero substitution (B8ZS) linecoding. Linecode errors occur when BPVs that are not used for synchronization are received. Excessive zero errors occur when eight or more 0s in a row are received on a circuit where alternate mark inversion (AMI) linecoding is being used. The errors might occur because of an AMI/B8ZS conguration problem or there might be points along the transmission path that do not have all the linecoding parameters set correctly.
Pathcode Violations
Two examples for pathcode violations are frame synchronization errors for SF and cyclic redundancy check (CRC) errors for ESF. Typically, both pathcode violations and linecode violations are present simultaneously, so always that verify the linecoding is correct. Some smartjacks (and mux equipment) might need to be specically congured for AMI/B8ZS because of problems with automatic linecode detection. Be aware that some amount of errors on your T1 can occur because of impulse noise; therefore, the errors might appear only a few times a day and the effects might be miniscule.
Slip Seconds
The presence of slips on a T1 line indicates a clocking problem. The network provides the clocking with which the customer premises equipment (CPE) must synchronize. If you see slips on the line, verify that you are deriving your clocking from the telephone company (telco) (clock source line). It is possible that only one side of the T1 is experiencing errors, so contact the provider to ensure that they are not seeing errors on their side of the circuit.
187
T1 Errors
RFC 1232 denes the managed objects for the DS1 interface type and standardizes the DS1 terminology and descriptions of error conditions on a T1 or E1 circuit. Table 7-1 shows the RFC 1232 categories, errors, and their descriptions.
Table 7-1 RFC 1232 Categories, Errors, and Their Descriptions Object Out of Frame event Description Declared when the receiver detects two or more framing-bit errors within a three millisecond period, or two or more errors out of ve or less consecutive framing-bits. At this time, the framer enters the Out of Frame state, and starts searching for a correct framing pattern. The Out of Frame state ends when reframe occurs. This event is declared upon observing 175 +/- 75 contiguous pulse positions with no pulses of either positive or negative polarity (also called keepalive). The occurrence of a received CRC code that is not identical to the corresponding locally calculated code. A BPV for B8ZS-coded signals is the occurrence of a received BPV that is not part of a zero-substitution code. It also includes other error patterns such as eight or more consecutive 0s, and incorrect parity. A second with one or more Code Violation Error events or one or more Out of Frame events. The presence of BPVs also triggers an Errored Second. A second with 320 or more Code Violation Error events or one or more Out of Frame events. A Severely Errored Framing Second is a second with one or more Out of Frame events. Declared at the onset of 10 consecutive Severely Errored Seconds. It is cleared at the onset of ten consecutive seconds with no Severely Errored Seconds. Calculated by counting the number of seconds that the CSU is in the Unavailable Signal State, including the initial ten seconds to enter the state, but not including the ten seconds to exit the state. Declared because of an incoming Yellow signal from the far end. In effect, the circuit is declared to be a one-way link. Declared because of an incoming LOS, LOF, or an AIS. After a Red Alarm is declared, the device sends a yellow signal to the far end. When the far end receives the yellow signal, it declares a Yellow Alarm. This is a character string that is specied by the circuit vendor, and is useful when communicating with the vendor during the troubleshooting process.
Loss of Signal
Code Violation Error Event Bipolar Violation
Errored Seconds Severely Errored Seconds Severely Errored Framing Second Unavailable Signal State Unavailable Seconds Yellow Alarm Red Alarm
Circuit Identier
188
Troubleshooting PRI Circuits

A PRI is actually an ISDN connection that uses a type of signaling to channelize a T1 without robbing signaling bits from each channel; instead, the signaling is done on the last (24th) channel. The rst step in troubleshooting problems with a PRI is to use the show isdn status command as shown in Example 7-2.
Example 7-2 Output of show isdn status
5300-dialin#show isdn status Global ISDN Switchtype = primary-5ess ISDN Serial0:23 interface dsl 0, interface ISDN Switchtype = primary-5ess 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) <output omitted>
The following sections explain this output.
Layer 1 Status
The Layer 1 status portion of the output shows whether the T1 access circuit that the PRI signaling rides on is up or not. If it is not in an active state, go to the beginning of this chapter and troubleshoot the T1 portion of the circuit rst.
Layer 2 Status
If the Layer 2 state does not show MULTIPLE_FRAME_ESTABLISHED, check the T1 circuit for incrementing errors and treat this situation as any T1 problem. More information about troubleshooting measures is covered in the section, Troubleshooting T1 Circuits. If the T1 checks out okay, verify that the ISDN switch type and PRI group time slots were set up the same as the circuit was provisioned. Then check the serial interface associated with the PRI by using the command show interface serial x:23, where X is the associated T1 port number. A sample output is shown in Example 7-3.
Example 7-3 Output of show interface serial 0:23
S5200-dialin>show interface serial 0:23 Serial2:23 is up, line protocol is up (spoofing) Hardware is DSX1 MTU 1500 bytes, BW 64 Kbit, DLY 20000 usec, reliability 128/255, txload 1/255, rxload 1/255
189
Example 7-3 Output of show interface serial 0:23 (Continued)

Encapsulation HDLC, loopback not set DTR is pulsed for 1 seconds on reset Last input 00:00:20, output never, output hang never Last clearing of show interface counters never Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0 <output omitted>e
Verify that the D channel is up and not in a loopback state. If the state of Layer 2 is still not MULTIPLE_FRAME_ESTABLISHED, you need to call your service provider. However, if you receive this message but you are still experiencing problems, turn on ISDN Q921 debugs. After using debug isdn q921 and show debug, ensure that the output is similar to that in Example 7-4.
Example 7-4 Output of show debug Indicates That debug isdn q921 Is On
5300-dialin#show debug ISDN: ISDN Q921 packets debugging is on ISDN Q921 packets debug DSLs. (On/Off/No DSL:1/0/-) DSL 0 --> 7 1 1 1 1 1 1 1 1
If you are not directly connected to the console port, you have to enable terminal monitor to see the output from debug commands. Also, verify that the only activity you see is similar to that in Example 7-5.
Example 7-5 Debug Output Showing ISDN q921 Activity
5300-dialin#terminal Jan 6 03:44:01.653: Jan 6 03:44:05.669: Jan 6 03:44:05.677: Jan 6 03:44:14.981: Jan 6 03:44:14.989: Jan 6 03:44:16.169: Jan 6 03:44:16.185: monitor ISDN Se0:23: ISDN Se1:23: ISDN Se1:23: ISDN Se2:23: ISDN Se2:23: ISDN Se3:23: ISDN Se3:23: RX TX RX TX RX TX RX <-> <-> <-> <RRf RRp RRf RRp RRf RRp RRf sapi sapi sapi sapi sapi sapi sapi = = = = = = = 0 0 0 0 0 0 0 tei tei tei tei tei tei tei = = = = = = = 0 nr = 4 0 nr = 113 0 nr = 1 0 nr = 0 0 nr = 0 0 nr = 79 0 nr = 79
A service access point identier (SAPI) has a value assigned to it. This value determines the data type coming from the device at the other end. The data types are as follows:
0Q931 (signaling information) 1Telemetry 16X.25 on the D channel 63Data-link management
190
A terminal endpoint identier (TEI) is an address used at Layer 2 that manages individual devices that are connecting to the ISDN network. The TEI is typically dynamically negotiated with the ISDN switch. The range is from 0 to 127. The following shows what each TEI number means:

NOTE
0Point-to-point service (as it is for PRI) 1-63Fixed assigned 64-126Dynamically assigned by telco switch 127Broadcast (send frame to all attached devices)
The correct TEI for PRI is always 0.
If Set Asynchronous Balanced Mode Extended (SABME) messages appear, the switchtype or PRI time slots are set incorrectly. SABME messages in the debug appear as follows:
Jan Jan 6 03:45:16.185: ISDN Se0:23: TX -> SABMEp sapi = 0 tei = 0 6 03:45:16.662: ISDN Se0:23: RX <- BAD FRAME(0x00017F)Line may be looped!
See Chapter 12, ISDN BRI Troubleshooting, for additional information about the Q921 protocol.
Troubleshooting Dial-In Service

In this section, detail is provided on what you can do to determine the cause of the dial-in connection problems. The troubleshooting techniques include commands for use on a modem, outputs from debug commands, and some common recommendations. This section does not include debugs from Cisco AS5x00 series routers because this is covered in a subsequent section later in this chapter. When troubleshooting a connection problem, try to piece together everything that is expected to occur throughout the process. Use a step-by-step approach to outline all activities from start to nish, and in the correct sequence. You might be required to make some assumptions as part of the process. First, assume that the analog lines connected to the modems are working, their phone numbers are correct, and a call placed from one end to the other occurs successfully (the switched services work correctly). Obviously, if a problem exists with an analog line, its a switched service problem, and your telephone provider must correct the issue. This section covers the following steps that are used to troubleshoot a problem with the NAS:
Step One: Verify that the modem is ready to accept incoming calls. Step Two: Verify the type of connection. Step Three: Verify Point-to-Point Protocol (PPP) negotiation.
191
Step One: Verify that the Modem Is Ready to Accept Calls

The rst event to occur is that the modem must pick up the call. If it is an external modem, increase the volume so that you can hear it. Place a call from a telephone to the modem to make sure it answers. If it does not, check the cabling between the modem and the router. The type of cable can differ between modems, so the easiest way to check is through the show line line-number command. The line you must check is the following:
Modem state: Idle
If the modem is ready to take an incoming call, but there is no call on the line, the state should be idle. If the state is anything other than idle, the modem will not answer the call. Several different signals (modem states) have to interact properly for the modem to be ready to accept a call. The Modem Hardware State are
CTS (Clear To Send)Provided by the data communications equipment (DCE). The DCE signals to the data terminal equipment (DTE) that the DCE accepts data. DSR (Data Set Ready)Provided by the DCE. DTR (Data Terminal Ready)Provided by the DTE. The DTE indicates to the DCE that it accept calls. RTS (Request To Send)Provided by the DTE. The DTE signals that the DTE accepts data.
Modem Hardware State: CTS noDSR DTR RTS

In this example, the Modem Hardware State is correct, but the modem is in a ready state instead of an idle state, as indicated by noDSR. If an active session is on the line, the modem cannot answer a new call. It displays a ready state. The show users command shows you if there is an active session. You can then clear the active session with the privileged command clear line. The second reason for noDSR can be because modem control is not congured on the line. Congure the line with either modem Dialin or modem InOut. Lastly, DSR might be high, which results from a cabling problem or if the modem is congured where Data Carrier Detect-Provided (DCD) is always high. Fix the cabling problem or recongure the modem so that DCD is only high when carrier detection (CD) is successful, which should clear the problem.
Modem Hardware State: noCTS noDSR DTR RTS

In cases where noCTS replaces CTS in the correct state, three different possibilities exist: the modem is turned off, a cabling problem exists, or hardware ow control on the modem is turned off. The line conguration command no owcontrol hardware xes the last of these three problems.
192
Modem Hardware State: CTS DSR DTR RTS

In cases where DSR replaces noDSR in the correct state, there can be a cable problem. Also, DCD can always be congured on the modem as high. Recongure the modem to correct this and ensure that either the line conguration command modem Dialin or modem InOut exists. Now that the cable connection from router to modem is operational, you must also ensure that the modem is set to auto answer. Consult the modems owners manual to set this up. This concludes the troubleshooting required if a modem does not answer.
Step Two: Verify Type of Incoming Connection

After step one, where the connection is a fact, perform the second step from the core router (NAS). The Cisco IOS features give you much more insight about the type of the connection than any other approach. Start the incoming type verication by using the debug modem command. The rst debug reects the conguration from a basic PPP dial-in service in Chapter 6, Dial Design and Conguration Solutions. When dialing into an external modem, one that does not have out-of-band signaling, the rst line should read as follows:
17:11:38: TTY1: DSR came up
This signies that the modem has trained up successfully. If this does not take place, there was a problem with the modem train-up. Line issues or modem incompatibilities can cause a train-up failure. To cure any modem incompatibility problem, ensure that the modems on both ends have the latest rmware and drivers. The following line indicates a change in modem state:
17:11:38: tty1: Modem: IDLE->(unknown)
The modem in this example happens to be external, so the router does not know which state the modem changed to. If it had been an internal modem with out-of-band functionality, you would have seen the following:
17:11:38: tty1: Modem: IDLE->READY
At this point, if you have the interface congured with async mode dedicated, the connection immediately jumps into PPP. The PPP debugs are covered later in this section. If the line was congured for text authentication and no PPP, such as a modem in an AUX port, the debug output in Example 7-6 would be displayed.
Example 7-6 Debug Output for Exec Creation
! The router starts an exec session: 17:11:43: TTY1: EXEC creation ! The following two lines are used when prompting for authentication: 17:11:43: TTY1: set timer type 10, 30 seconds
193
Example 7-6 Debug Output for Exec Creation (Continued)

17:11:56: TTY1: set timer type 10, 30 seconds 17:11:67: TTY1: create timer type 1, 600 seconds
The type 10 timer is used for username and password prompts. The fourth line in the output sets a 30-second timer for the username prompt and the fth line places another 30-second timer for the password prompt. The last line in the output is an exec timer. The default exectimeout set on a line is 10 minutes, or 600 seconds. In the preceding example, the modem changed state from idle to unknown. If the async interface was congured with async mode interactive and the line was congured with autoselect ppp and autoselect during-login, the debug is different, as shown in Example 7-7.
Example 7-7 Debug Output of Modem Autoselect for PPP
22:52:59: 22:52:59: 22:53:01: 22:53:01: 22:53:01: 22:53:01: 22:53:01: TTY1: EXEC creation TTY1: set timer type 10, 30 seconds TTY1: Autoselect(2) sample 7E TTY1: Autoselect(2) sample 7EFF TTY1: Autoselect(2) sample 7EFF7D TTY1: Autoselect(2) sample 7EFF7D23 TTY1 Autoselect cmd: ppp negotiate
During the username prompt, the router checks incoming characters to see if they are PPP or if they are part of a username. The autoselect samples shown in Example 7-7 are in hexadecimal format. If translated to ASCII, they show the text received over a line. There is an autoselect sample for each character that arrives. The router displays up to four characters in each new autoselect sample line and includes the three previous characters, followed by the last character entered as shown. The four autoselect characters in Example 7-7, if translated into ASCII, are ~}#, which is the typical representation of a PPP link control protocol (LCP) packet. For this reason, the last line in the debug shows that autoselect executed the command ppp negotiate, which instructs the router to negotiate PPP. The sample output in Example 7-8 uses the same conguration as before, except that the login was done through text. This can either be from typing it manually or from running a login script.
Example 7-8 Debug Output of Modem Autoselect for Text
23:15:22: TTY1: EXEC creation 23:15:22: TTY1: set timer type 10, 30 seconds ! Username entry of six characters, followed by carriage return 23:15:23: TTY1: Autoselect(2) sample 6A 23:15:24: TTY1: Autoselect(2) sample 6A68 23:15:24: TTY1: Autoselect(2) sample 6A6875
continues
194
Example 7-8 Debug Output of Modem Autoselect for Text (Continued)

23:15:24: TTY1: Autoselect(2) sample 6A687565 23:15:24: TTY1: Autoselect(2) sample 68756567 23:15:24: TTY1: Autoselect(2) sample 75656765 23:15:24: TTY1: Autoselect(2) sample 6567656E 23:15:25: TTY1: Autoselect(2) sample 67656E0D 23:15:25: TTY1: set timer type 10, 30 seconds ! The following lines state [suppressed--line is not echoing], because ! the password prompt never echoed the characters entered. 23:15:26: TTY1: Autoselect(2) sample [suppressed--line is not echoing] 23:15:26: TTY1: Autoselect(2) sample [suppressed--line is not echoing] 23:15:27: TTY1: Autoselect(2) sample [suppressed--line is not echoing] 23:15:27: TTY1: Autoselect(2) sample [suppressed--line is not echoing] 23:15:27: TTY1: Autoselect(2) sample [suppressed--line is not echoing]
In this case, the username entered is six characters followed by a carriage return. You can decode the incoming text for usernames by converting the hexadecimal characters in the sample to ASCII. The hexadecimal string can be pieced together to form 6A 68 75 65 67 65 6E 0D. When changed to ASCII, it spells jhuegen followed by 0D, which is a carriage return. The following lines states [suppressed--line is not echoing] because the password prompt never echoes the characters entered; however, you can make the assumption that the password entered was four characters followed by a carriage return (to make up the ve lines).
Step Three: Verify PPP Negotiation

After the call connects, PPP negotiation starts. The following output is from debug PPP negotiation. It is split into the major steps, which are explained:
Mar Mar Mar 2 13:32:45.354: %LINK-3-UPDOWN: Interface Async1, changed state to up 2 13:32:45.354: As1 PPP: Treating connection as a dedicated line 2 13:32:45.354: As1 PPP: Phase is ESTABLISHING, Active Open
NOTE
The Link Dead (physical layer not ready) transition state changes to the Link Establishment phase only if an external event, such as a carrier detect (CD), is up.
LCP Phase of PPP

The following explanations are based on the output you see if you type the debug ppp negotiation command to troubleshoot LCP issues. The rst part of the output identies how PPP treats the connection. For every dial case, it is treated as a dedicated line. The rst step in LCP takes place when the dial server sends an outgoing conguration request (O CONFREQ), as shown in Example 7-9.
195
Example 7-9 Debug Output of PPP Outgoing Conguration Request

Mar Mar Mar Mar Mar Mar 2 2 2 2 2 2 13:32:45.354: 13:32:45.354: 13:32:45.358: 13:32:45.358: 13:32:45.358: 13:32:45.358: As1 As1 As1 As1 As1 As1 LCP: O CONFREQ [Closed] id 33 len 24 LCP: ACCM 0x000A0000 (0x0206000A0000) LCP: AuthProto PAP (0x0304C023) LCP: MagicNumber 0xE82CFF9C (0x0506E82CFF9C) LCP: PFC (0x0702) LCP: ACFC (0x0802)
The server expects a reply and the reply should be similar to the Example 7-10, which is an incoming conguration acknowledgment (I CONFACK).
Example 7-10 Debug Output of PPP Incoming Conguration Acknowledgment
Mar Mar Mar Mar Mar Mar 2 2 2 2 2 2 13:32:45.546: 13:32:45.546: 13:32:45.546: 13:32:45.546: 13:32:45.546: 13:32:45.546: As1 As1 As1 As1 As1 As1 LCP: I CONFACK [REQsent] id 33 len 24 LCP: ACCM 0x000A0000 (0x0206000A0000) LCP: AuthProto PAP (0x0304C023) LCP: MagicNumber 0xE82CFF9C (0x0506E82CFF9C) LCP: PFC (0x0702) LCP: ACFC (0x0802)
Next, the incoming conguration request (I CONFREQ) from the connecting client is received. At this point, the client tries to negotiate the callback protocol, as shown in Example 7-11.
Example 7-11 Debug Output of PPP Request for Callback
Mar Mar Mar Mar Mar Mar Mar Mar Mar Mar 2 2 2 2 2 2 2 2 2 2 13:32:46.402: 13:32:46.402: 13:32:46.406: 13:32:46.406: 13:32:46.406: 13:32:46.406: 13:32:46.406: 13:32:46.406: 13:32:46.406: 13:32:46.406: As1 As1 As1 As1 As1 As1 As1 As1 As1 As1 LCP: I CONFREQ [ACKrcvd] id 2 len 50 LCP: ACCM 0x00000000 (0x020600000000) LCP: MagicNumber 0x588D5503 (0x0506588D5503) LCP: PFC (0x0702) LCP: ACFC (0x0802) LCP: Callback 6 (0x0D0306) LCP: MRRU 1614 (0x1104064E) LCP: EndpointDisc 1 Local LCP: (0x131701F9358C5F03D643118C9B7AC7F0) LCP: (0x70629C00000000)
The dial server then sends an outgoing rejection (O CONFREJ) because callback authentication is not turned on, as shown in Example 7-12.
Example 7-12 Debug Output of PPP Rejection for Callback
Mar Mar Mar 2 13:32:46.406: As1 LCP: O CONFREJ [ACKrcvd] id 2 len 11 2 13:32:46.406: As1 LCP: Callback 6 (0x0D0306) 2 13:32:46.406: As1 LCP: MRRU 1614 (0x1104064E)
The client then requests a new set of options. This is an incoming conguration request (I CONFREQ), as shown in Example 7-13.
196
Example 7-13 Debug Output of PPP Incoming Conguration Request

Mar Mar Mar Mar Mar Mar Mar Mar 2 2 2 2 2 2 2 2 13:32:46.594: 13:32:46.594: 13:32:46.594: 13:32:46.594: 13:32:46.594: 13:32:46.594: 13:32:46.594: 13:32:46.594: As1 As1 As1 As1 As1 As1 As1 As1 LCP: I CONFREQ [ACKrcvd] id 3 len 43 LCP: ACCM 0x00000000 (0x020600000000) LCP: MagicNumber 0x588D5503 (0x0506588D5503) LCP: PFC (0x0702) LCP: ACFC (0x0802) LCP: EndpointDisc 1 Local LCP: (0x131701F9358C5F03D643118C9B7AC7F0) LCP: (0x70629C00000000)
The server then acknowledges this by sending an outgoing conguration acknowledgement (O CONFACK), as shown in Example 7-14.
Example 7-14 Debug of PPP Outgoing Conguration Acknowledgment
Mar Mar Mar Mar Mar Mar Mar Mar 2 2 2 2 2 2 2 2 13:32:46.598: 13:32:46.598: 13:32:46.598: 13:32:46.598: 13:32:46.598: 13:32:46.598: 13:32:46.598: 13:32:46.598: As1 As1 As1 As1 As1 As1 As1 As1 LCP: O CONFACK [ACKrcvd] id 3 len 43 LCP: ACCM 0x00000000 (0x020600000000) LCP: MagicNumber 0x588D5503 (0x0506588D5503) LCP: PFC (0x0702) LCP: ACFC (0x0802) LCP: EndpointDisc 1 Local LCP: (0x131701F9358C5F03D643118C9B7AC7F0) LCP: (0x70629C00000000)
Next, LCP changes state to open. At this point, both sides agree that the server will provide a conguration for the client. LCP is then complete.
! The LCP is Open: Mar 2 13:32:46.598: As1 LCP: State is Open
IF LCP never completes and does not change state to open, a few problems can possibly exist:
First, LCP timeouts can be caused by a speed problem between the router and modem. A symptom of this problem is that either one or both of the peers do not see any incoming LCP packets. This occurs only if there is a speed issue between the router and an external modem. The second type of LCP problem is caused when both peers are not able to agree on authentication. The client and server must agree on authentication type, which is Password Authentication Protocol (PAP), Challenge Handshake Authentication Protocol (CHAP), or Microsoft CHAP (MS CHAP). For example, if the server side is set to authenticate through CHAP and the client is congured for PAP authentication, LCP times out while trying to negotiate. LCP can also fail because of a maximum transmission unit (MTU) mismatch. Make sure that MTU is dened as the same on both peers. If necessary, reduce the MTU on both sides until LCP succeeds.
197
The Authentication Phase of PPP

After LCP nishes and its state is open, the next step in the process is authentication. During this phase, you can see the authenticating party and whether or not authentication has passed. Example 7-15 shows the output of a successful PPP PAP authentication. This output is a result of the debug ppp authentication command.
Example 7-15 Debug Output of a Successful PPP PAP Authentication
Mar Mar Mar Mar Mar Mar Mar Mar Mar 2 2 2 2 2 2 2 2 2 13:32:46.598: 13:32:46.842: 13:32:46.846: 13:32:46.846: 13:32:46.846: 13:32:46.850: 13:32:46.850: 13:32:46.850: 13:32:46.850: As1 As1 As1 As1 As1 As1 As1 As1 As1 PPP: PAP: PAP: PPP: PPP: PPP: PPP: PAP: PPP: Phase is AUTHENTICATING, by this end I AUTH-REQ id 7 len 17 from jhuegen Authenticating peer jhuegen Phase is FORWARDING, Attempting Forward Phase is AUTHENTICATING, Unauthenticated User Phase is FORWARDING, Attempting Forward Phase is AUTHENTICATING, Authenticated User O AUTH-ACK id 7 len 5 Phase is UP
Network Control Protocol Phase of PPP

When the PPP phase is up, authentication has completed successfully. Then, Network Control Protocol (NCP) negotiates Layer 3 protocols, including IP Control Protocol (IPCP). In the case of dial, IPCP negotiates IP addresses for the peer IP address, the Domain Name System (DNS) servers, and the Windows Internet Naming Service (WINS) servers. The following explanations are based on the output from the command debug ppp negotiation. Remember that the output can be long and you see these lines only if the previous (authentication) phase is successful. First, an outgoing conguration request is sent to the peer that contains its own IP address:
Mar Mar 2 13:32:46.854: As1 IPCP: O CONFREQ [Closed] id 7 len 10 2 13:32:46.854: As1 IPCP: Address 192.168.0.249 (0x0306C0A800F9)
The peer then sends a request to the NAS to do Compression Control Protocol (CCP):
Mar Mar 2 13:32:47.010: As1 CCP: I CONFREQ [Not negotiated] id 6 len 10 2 13:32:47.014: As1 CCP: MS-PPC supported bits 0x00000001 (0x120600000001)
CCP is then rejected by an outgoing protocol rejection (O PROTREJ) packet. The peer should not attempt to renegotiate CCP:
Mar 2 13:32:47.014: As1 LCP: O PROTREJ [Open] id 34 len 16 protocol CCP (0x80FD0106000A120600000001)
An incoming conguration request is received, and the peer requests VJ 15 header compression and IP addresses for the peer, including the Primary DNS, Primary WINS, Secondary DNS, and Secondary WINS servers, as shown in Example 7-16.
198
Example 7-16 Debug Output of IPCP Incoming Conguration Request

Mar 2 13:32:47.058: Mar 2 13:32:47.058: (0x0206002D0F01) Mar 2 13:32:47.058: Mar 2 13:32:47.058: Mar 2 13:32:47.058: Mar 2 13:32:47.058: Mar 2 13:32:47.058: As1 IPCP: I CONFREQ [REQsent] id 7 len 40 As1 IPCP: CompressType VJ 15 slots CompressSlotID As1 As1 As1 As1 As1 IPCP: IPCP: IPCP: IPCP: IPCP: Address 0.0.0.0 (0x030600000000) PrimaryDNS 0.0.0.0 (0x810600000000) PrimaryWINS 0.0.0.0 (0x820600000000) SecondaryDNS 0.0.0.0 (0x830600000000) SecondaryWINS 0.0.0.0 (0x840600000000)
NOTE
VJ compression is Van Jacobsen TCP header compression, which is a widely accepted compression method. See Part IV, Frame Relay for more information.
An outgoing conguration reject (O CONFREJ) is sent to reject VJ 15 header compression:

Mar 2 13:32:47.058: As1 IPCP: O CONFREJ [REQsent] id 7 len 10 Mar 2 13:32:47.058: As1 IPCP: CompressType VJ 15 slots CompressSlotID (0x0206002D0F01)
An incoming conguration acknowledgment (I CONFACK) is received and the peer acknowledges the IP address of the NAS:
Mar Mar 2 13:32:47.062: As1 IPCP: I CONFACK [REQsent] id 7 len 10 2 13:32:47.062: As1 IPCP: Address 192.168.0.249 (0x0306C0A800F9)
Because VJ 15 header compression was rejected, so was the request for IP addresses for the peer and those of the DNS and WINS servers. The peer then sends another conguration request packet because the rst was rejected, only this time, it asks for addressing without asking for header compression, as shown in Example 7-17.
Example 7-17 Debug Output of IPCP Incoming Conguration Request Without Compression
Mar Mar Mar Mar Mar Mar 2 2 2 2 2 2 13:32:47.246: 13:32:47.246: 13:32:47.246: 13:32:47.246: 13:32:47.246: 13:32:47.246: As1 As1 As1 As1 As1 As1 IPCP: I CONFREQ [ACKrcvd] id 8 len 34 IPCP: Address 0.0.0.0 (0x030600000000) IPCP: PrimaryDNS 0.0.0.0 (0x810600000000) IPCP: PrimaryWINS 0.0.0.0 (0x820600000000) IPCP: SecondaryDNS 0.0.0.0 (0x830600000000) IPCP: SecondaryWINS 0.0.0.0 (0x840600000000)
Confusion occurs when the router sends a conguration non-acknowledgment, which actually refuses the request for the peer to use 0.0.0.0 as every address. Along with this nonacknowledgment (NAK), the NAS sends the peer the IP address and those of the DNS and WINS servers that it wants the peer to use, as shown in Example 7-18.
199
Example 7-18 Debug Output of Outgoing Non-Acknowledgment with Server Assigned Addressing
Mar Mar Mar Mar Mar Mar 2 2 2 2 2 2 13:32:47.250: 13:32:47.250: 13:32:47.250: 13:32:47.250: 13:32:47.250: 13:32:47.250: As1 As1 As1 As1 As1 As1 IPCP: O CONFNAK [ACKrcvd] id 8 len 34 IPCP: Address 192.168.0.251 (0x0306C0A800FB) IPCP: PrimaryDNS 192.168.100.3 (0x8106C0A86403) IPCP: PrimaryWINS 192.168.100.5 (0x8206C0A86405) IPCP: SecondaryDNS 192.168.100.4 (0x8306C0A86404) IPCP: SecondaryWINS 192.168.100.6 (0x8406C0A86406)
The peer responds to the NAK with yet another conguration request to use the IP addresses provided with the previous NAK. Example 7-19 shows the expected output for this exchange.
Example 7-19 Debug Output of Incoming Request with Server Assigned Addressing
Mar Mar Mar Mar Mar Mar 2 2 2 2 2 2 13:32:47.446: 13:32:47.446: 13:32:47.446: 13:32:47.446: 13:32:47.446: 13:32:47.450: As1 As1 As1 As1 As1 As1 IPCP: I CONFREQ [ACKrcvd] id 9 len 34 IPCP: Address 192.168.0.251 (0x0306C0A800FB) IPCP: PrimaryDNS 192.168.100.3 (0x8106C0A86403) IPCP: PrimaryWINS 192.168.100.5 (0x8206C0A86405) IPCP: SecondaryDNS 192.168.100.4 (0x8306C0A86404) IPCP: SecondaryWINS 192.168.100.6 (0x8406C0A86406)
The NAS then acknowledges the peer as congured correctly by sending an outgoing conguration acknowledgment packet, as shown in Example 7-20.
Example 7-20 Debug Output of Outgoing Acknowledgment with Server Assigned Addressing
Mar Mar Mar Mar Mar Mar 2 2 2 2 2 2 13:32:47.450: 13:32:47.450: 13:32:47.450: 13:32:47.450: 13:32:47.450: 13:32:47.450: As1 As1 As1 As1 As1 As1 IPCP: O CONFACK [ACKrcvd] id 9 len 34 IPCP: Address 192.168.0.251 (0x0306C0A800FB) IPCP: PrimaryDNS 192.168.100.3 (0x8106C0A86403) IPCP: PrimaryWINS 192.168.100.5 (0x8206C0A86405) IPCP: SecondaryDNS 192.168.100.4 (0x8306C0A86404) IPCP: SecondaryWINS 192.168.100.6 (0x8406C0A86406)
When both sides agree on the addressing, IPCP changes state to open and installs the directly connected route to the dialup peer:
Mar 2 13:32:47.450: As1 IPCP: State is Open Mar 2 13:32:47.454: As1 IPCP: Install route to 192.168.0.251 Mar 2 13:32:47.454: %LINEPROTO-5-UPDOWN: Line protocol on Interface Async1, changed state to up
NOTE
To troubleshoot a problem during NCP negotiation, ensure that all required IP addresses and protocols are congured.
200
Two of the most common issues that occur during the NCP stage of PPP negotiation are the following:
The IP address is not congured on the group-async interface on the NAS. In most cases, you are not able to congure an IP address directly on the interface; therefore, you need to congure a loopback interface with an IP address. Use the command ip unnumbered interface on your group-async interface, where interface refers to your loopback interface. This instructs the group-async interface to use the IP address of the loopback. Verify the availability of pool IP addressing for the client. If all addresses in the pool are already allocated, NCP fails by not providing the peer with an IP address.
NOTE
The typical dial oversubscription ratio for Internet service providers (ISPs) is about ten users to one DS0, and scaling beyond this number is not recommended. In the case of an enterprise environment, remote users tend to dial up more often, and this ratio can be as low as 5 to 1. Oversubscription ratios for enterprises that provide a wide variety of remote access services might nd it easier to base their oversubscription rate on percentages. For example, an enterprise might try to keep an average of 40 percent of DS0s available throughout a typical day. This 40 percent is there to handle the spikes in daily usage and holidays, when dial usage is normally much higher than on average.
Verify that DNS and WINS server IP addresses are congured to respond to BOOTP requests. Use the global conguration commands async-bootp dns-server address(es) and async-bootp nbns-server address(es) to congure this feature.
After PPP negotiation is complete, the dial connection is complete and trafc is able to pass, unless of course routing problems exist in the network.

When an outbound call is placed, the output in Example 7-21 is generated from dial-ondemand events and PPP protocol negotiation debugging. The commands that enable this debugging include #debug dialer and #debug ppp negotiation.
Example 7-21 Debug Output of Dialer and PPP Negotiation for an Outgoing Call
Mar Mar Mar Mar Mar Mar 00:11:15.975: 00:11:15.975: 00:11:15.975: 00:11:15.975: 00:11:15.983: 00:11:15.983: & System script: Mar 1 00:11:15.987: Mar 1 00:11:15.987: Mar 1 00:11:15.987: 1 1 1 1 1 1 As65 DDR: place call As65 DDR: Dialing cause ip (s=192.168.0.2, d=216.115.102.82) As65 DDR: Attempting to dial 6222230 CHAT65: Attempting async line dialer script CHAT65: no matching chat script found for 6222230 CHAT65: Dialing using Modem script: d0efault-d0ials0cript none CHAT65: process started CHAT65: Asserting DTR CHAT65: Chat script d0efault-d0ials0cript started
201
To place a call, some interesting trafc must be routed out the async65 interface. In the output shown in Example 7-21, the source address 192.168.0.2 (a host on the Ethernet segment) sent a packet to 216.115.102.82, which caused the router to attempt to dial. In most cases, you do not need a dial chat script and the default works. The default dial script simply performs the modem AT commands to cause the modem connect and then hands the connection over to the async interface. If the modem does not attempt to dial, check for cabling problems or the correct line conguration. The line must be set for modem InOut and the async interface requires a dialer string. Also, ensure that the phone line is active because without a dial tone the modem cannot dial. At this point, the modem should train up. Once this is successful, the script ends and the interface changes state to up, as shown in the output in Example 7-22.
Example 7-22 Continuation of Debug from Example 7-21
Mar 1 00:11:39.731: CHAT65: Chat script d0efault-d0ials0cript finished, status = success 00:11:41: %LINK-3-UPDOWN: Interface Async65, changed state to up Mar 1 00:11:41.735: As65 DDR: Dialer state change to up Mar 1 00:11:41.735: As65 DDR: Dialer call has been placed Mar 1 00:11:41.735: As65 PPP: Treating connection as a callout Mar 1 00:11:41.735: As65 PPP: Phase is ESTABLISHING, Active Open Mar 1 00:11:41.735: As65 PPP: No remote authentication for call-out
After the interface is up, PPP negotiation takes place. By default with PAP and CHAP, the router attempts to authenticate the remote side, even on outbound calls. However, this router is congured to only authenticate inbound calls and does not authenticate the server that it is dialing into. To congure this, the word callin must be added to the ppp authentication interface conguration command. From this point, the PPP negotiation is exactly the opposite from the previous section because the router acts as a client, and not as the server. The dial-out router sends an outgoing conguration request to the NAS to advise it has connected, as shown in Example 7-23.
Example 7-23 Debug Output of PPP Outgoing Conguration Request
Mar Mar Mar Mar Mar 1 1 1 1 1 00:11:41.739: 00:11:41.739: 00:11:41.739: 00:11:41.739: 00:11:41.739: As65 As65 As65 As65 As65 LCP: O CONFREQ [Closed] id 12 len 20 LCP: ACCM 0x000A0000 (0x0206000A0000) LCP: MagicNumber 0xE0293F01 (0x0506E0293F01) LCP: PFC (0x0702) LCP: ACFC (0x0802)
Then, the NAS sends the dial-out router a conguration request asking to authenticate through PAP, as shown in Example 7-24.
202
Example 7-24 Debug Output of Incoming Request for PAP

Mar Mar Mar Mar Mar Mar Mar 1 1 1 1 1 1 1 00:11:41.915: 00:11:41.915: 00:11:41.915: 00:11:41.919: 00:11:41.919: 00:11:41.919: 00:11:41.919: As65 As65 As65 As65 As65 As65 As65 LCP: I CONFREQ [REQsent] id 253 len 28 LCP: MRU 1500 (0x010405DC) LCP: ACCM 0x000A0000 (0x0206000A0000) LCP: MagicNumber 0x01000000 (0x050601000000) LCP: PFC (0x0702) LCP: ACFC (0x0802) LCP: AuthProto PAP (0x0304C023)
The router responds to the conguration request for PAP with a conguration acknowledgment, as shown in Example 7-25.
Example 7-25 Debug Output of Outgoing Acknowledgment for PAP
Mar Mar Mar Mar Mar Mar Mar 1 1 1 1 1 1 1 00:11:41.919: 00:11:41.919: 00:11:41.919: 00:11:41.919: 00:11:41.919: 00:11:41.919: 00:11:41.919: As65 As65 As65 As65 As65 As65 As65 LCP: O CONFACK [REQsent] id 253 len 28 LCP: MRU 1500 (0x010405DC) LCP: ACCM 0x000A0000 (0x0206000A0000) LCP: MagicNumber 0x01000000 (0x050601000000) LCP: PFC (0x0702) LCP: ACFC (0x0802) LCP: AuthProto PAP (0x0304C023)
The NAS then responds with a conguration acknowledgment and LCP is complete, as shown in Example 7-26.
Example 7-26 Debug Output of Incoming Acknowledgment for PAP
Mar Mar Mar Mar Mar Mar 1 1 1 1 1 1 00:11:41.923: 00:11:41.923: 00:11:41.927: 00:11:41.927: 00:11:41.927: 00:11:41.927: As65 As65 As65 As65 As65 As65 LCP: I CONFACK [ACKsent] id 12 len 20 LCP: ACCM 0x000A0000 (0x0206000A0000) LCP: MagicNumber 0xE0293F01 (0x0506E0293F01) LCP: PFC (0x0702) LCP: ACFC (0x0802) LCP: State is Open
After the LCP phase is completed, the router and NAS start authentication. First, the router sends an outgoing authentication request with the username and password. The following shows the username in the debug output:
Mar Mar 1 00:11:41.927: As65 PPP: Phase is AUTHENTICATING, by the peer 1 00:11:41.927: As65 PAP: O AUTH-REQ id 1 len 37 from jhuegen
Next, the router receives an incoming authentication acknowledgment, which indicates that authentication is successful. If authentication had failed, a NAK would have been received along with a reason, which is usually authentication failure:
Mar 1 00:11:43.883: As65 PAP: I AUTH-ACK id 1 len 5
The following output shows that authentication is now complete, and the router moves on to the NCP stage of PPP negotiation:
203
Mar Mar Mar
1 00:11:43.883: As65 PPP: Phase is FORWARDING, Attempting Forward 1 00:11:43.887: As65 PPP: Phase is ESTABLISHING, Finish LCP 1 00:11:43.887: As65 PPP: Phase is UP
The router now sends an outgoing conguration request stating its intent to use IP address 0.0.0.0. The router expects this request will be refused and a real address will be assigned to it:
Mar Mar 1 00:11:43.887: As65 IPCP: O CONFREQ [Closed] id 1 len 10 1 00:11:43.887: As65 IPCP: Address 0.0.0.0 (0x030600000000)
Next, the dial-out router receives an incoming conguration request to use VJ 15 header compression. Also in this conguration request, the NAS sends its IP address:
Mar 1 00:11:43.891: As65 IPCP: I CONFREQ [REQsent] id 254 len 16 Mar 1 00:11:43.895: As65 IPCP: CompressType VJ 15 slots CompressSlotID (0x0206002D0F01) Mar 1 00:11:43.895: As65 IPCP: Address 216.192.135.254 (0x0306D8C087FE)
The router then rejects the header compression, and by doing so it rejects the IP address of the NAS. This is sent back to the dial-out router another time without the compression request:
Mar 1 00:11:43.895: As65 IPCP: O CONFREJ [REQsent] id 254 len 10 Mar 1 00:11:43.895: As65 IPCP: CompressType VJ 15 slots CompressSlotID (0x0206002D0F01)
The NAS rejects the requested IP address of 0.0.0.0 and offers 216.192.135.145 to the router for use:
Mar Mar 1 00:11:44.007: As65 IPCP: I CONFNAK [REQsent] id 1 len 10 1 00:11:44.007: As65 IPCP: Address 216.192.135.145 (0x0306D8C08791)
In return, the router requests that the NAS allow it to use the address it offered in the previous conguration request:
Mar Mar 1 00:11:44.007: As65 IPCP: O CONFREQ [REQsent] id 2 len 10 1 00:11:44.007: As65 IPCP: Address 216.192.135.145 (0x0306D8C08791)
The NAS then resends its IP address to the router; this time without requesting header compression:
Mar Mar 1 00:11:44.011: As65 IPCP: I CONFREQ [REQsent] id 255 len 10 1 00:11:44.011: As65 IPCP: Address 216.192.135.254 (0x0306D8C087FE)
The dial-out router replies and acknowledges the IP address of the NAS as follows:
Mar Mar 1 00:11:44.015: As65 IPCP: O CONFACK [REQsent] id 255 len 10 1 00:11:44.015: As65 IPCP: Address 216.192.135.254 (0x0306D8C087FE)
Next, the NAS acknowledges the requested IP address of the dial-out router, which it offered to the router in the rst place:
Mar Mar 1 00:11:44.123: As65 IPCP: I CONFACK [ACKsent] id 2 len 10 1 00:11:44.123: As65 IPCP: Address 216.192.135.145 (0x0306D8C08791)
Finally, the NCP state of PPP negotiation is completed, as signaled by the State is Open statement:
Mar 1 00:11:44.123: As65 IPCP: State is Open Mar 1 00:11:44.123: As65 IPCP: Install negotiated IP interface address 216.192.135.145
204
NOTE
The router did not request DNS and WINS server information. It is congured this way because there is no way to automatically provide negotiated information to PCs upon connection. Therefore, this information was obtained ahead of time, and statically congured into the Dynamic Host Conguration Protocol (DHCP) server in the router.
When PPP is up, the router forwards the packets it was holding in the dialer hold-queue during the train-up, authentication, and PPP negotiation phases to their destination. The router also installs a route to the peer on the other end of the connection, as shown in the third line of the output:
Mar 1 00:11:44.127: As65 DDR: dialer protocol up Mar 1 00:11:44.127: As65 DDR: Call connected, 5 packets unqueued, 5 transmitted, 0 discarded Mar 1 00:11:44.131: As65 IPCP: Install route to 216.192.135.254 00:11:44: %LINEPROTO-5-UPDOWN: Line protocol on Interface Async65, changed state to up
The command show ip interface brief shows the async interface with its negotiated IP address, and the method by which this IP address was received. Because in this case the IP address is a result of successful PPP negotiation, it shows IPCP as the method. This command and output is demonstrated in Example 7-27.
Example 7-27 Output of show ip interface brief
Router#show ip interface brief Interface IP-Address OK? Method Status Async65 216.192.135.145 YES IPCP up Ethernet0/0 192.168.0.1 YES NVRAM up Protocol up up
If PPP does not fully negotiate, it is most likely not caused by a LCP timeout issue on the NAS site. This is because a line speed issue prevents the modem from dialing in the rst place. If you receive LCP timeouts as covered in the section, Troubleshooting Dial-In Service, the service provider is most likely the source of the issue. Another issue is an authentication problem caused when the username and password combination fails. If this occurs, recongure the username and password and, if necessary, verify it with the provider. The last issue that can cause problems is the router trying to authenticate the NAS. Because the router is the connecting party, and no provider allows a connecting party to authenticate them (unless this is arranged in advance), check the conguration for ppp authentication type. This command should not be included in the async interface conguration because it will try to authenticate the NAS. If this is the case, your debug should display the output, as shown in Example 7-28.
AS5x00 Specic Commands and Debugs
205
Example 7-28 Authentication Type Mismatch

Mar Mar Mar Mar Mar Mar Mar Mar Mar Mar Mar Mar Mar Mar Mar Mar 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 00:09:29.507: 00:09:29.511: 00:09:29.511: 00:09:29.511: 00:09:29.511: 00:09:29.511: 00:09:29.827: 00:09:29.831: 00:09:29.831: 00:09:29.831: 00:09:29.831: 00:09:29.831: 00:09:29.831: 00:09:29.831: 00:09:30.083: 00:09:30.083: As65 As65 As65 As65 As65 As65 As65 As65 As65 As65 As65 As65 As65 As65 As65 As65 LCP: LCP: LCP: LCP: LCP: LCP: LCP: LCP: LCP: LCP: LCP: LCP: LCP: LCP: LCP: LCP: O CONFREQ [ACKsent] id 2 len 24 ACCM 0x000A0000 (0x0206000A0000) AuthProto PAP (0x0304C023) MagicNumber 0xE0273903 (0x0506E0273903) PFC (0x0702) ACFC (0x0802) I CONFREJ [ACKsent] id 2 len 8 AuthProto PAP (0x0304C023) O CONFREQ [ACKsent] id 3 len 24 ACCM 0x000A0000 (0x0206000A0000) AuthProto PAP (0x0304C023) MagicNumber 0xE0273903 (0x0506E0273903) PFC (0x0702) ACFC (0x0802) I CONFREJ [ACKsent] id 3 len 8 AuthProto PAP (0x0304C023)
In the debug in Example 7-28, the router requests PAP authentication from the NAS. The NAS rejects the request, and because authentication is required, the router requests it again. This process continues in a loop until the router is disconnected for exceeding the connect timer.

High-density Cisco dial routers include the AS5100, AS5200, AS5300, AS5400, and AS5800 series routers. These devices were all developed for an ISP to provide dial-in services for a wide variety of customers. All these devices are modular so that if a modem or a group of modems is faulty, a feature card can be replaced instead of the entire router. The AS5100 series router is no longer in production, but was solely a router with a lot of external modems on line cards connected to it, all in one chassis; not modular. In fact, phone lines were connected to each of the individual modem line cards on the router. Because the AS5100 is no longer in production and was essentially the same as the router used for the examples on Basic PPP Dial-In Service, it is not covered in detail in this chapter. The AS5200 series was the rst Cisco product in this line to introduce 56 k modems. The router used Microcom modems that were software upgradeable using a digital signal processor (DSP) and rmware les available from the Cisco Systems web site. This server was also the rst Cisco dial router to use channelized T1s or PRIs to handle incoming calls. This router has since reached the end of the production cycle. The AS5300 opened the door to out-of-band signaling. Although the AS5200 had limited out-of-band signaling, the AS5300 (with the MICA modems) allows for polling all kinds of data from the modem that was not previously available. This includes real-time bandwidth measurements, line shape measurements, serial-to-noise ratio, as well as many other
206
parameters that are key to troubleshooting real-time. Most, if not all competitor dial servers do not provide for this real-time data, and it must be extracted from the modems via the AT command ati11 after the call is completed. The AS5300 can handle a total of 8 PRIs worth of calls in its 2U chassis. The AS5400 provides the same out of band signaling, but it has taken port density to a new level. At the time this book was written, the AS5400 can receive a CT3 worth of calls (552 calls if split into 24 PRIs with 23 available channels each) in a router that only consumes 2U worth of rack space. This is possible because of the new NextPort modems included in the AS5400. The AS5350 shares these modems in a 1U chassis that can handle 16 PRIs worth of calls. The AS5800 was developed with the AS5300 and provided the same functionality as the AS5300, but in a higher density package. It is a large 48VDC unit that was designed for the service provider environment. As well as the use of the MICA modems, all conguration commands are the same as the AS5300. The AS5850 shares the new NextPort modems with the AS5400 and AS5350, but in a larger chassis developed for sizeable deployments. The AS5850 is a 14U rack mount unit that can handle up to 3360 calls (5xCT3s), 96 T1s or 86 E1s. While not as dense as the AS5400 in terms of ports per unit of rack space, the AS5850 was developed to handle six times its current density. One of the most commonly used maintenance procedures for all earlier platforms is to upgrade the modem rmware. Although it is relatively straightforward, the procedure requires some steps that are included in the following example. To upgrade modem software on the routers, you must rst know what version of IOS is running on the router. There are two different scenarios for upgrading modem rmware, depending on the IOS version. Each step is covered here. The rst step in upgrading modem rmware is to get the latest version from Cisco.com and put it on your TFTP server. Next, copy it to the ash on the router that requires the update. Be sure not to erase the original contents of the ash memory when copying the upgrade to ash. Example 7-29 shows how to copy an image le to ash.
Example 7-29 Output from the copy tftp ash Command
5300-dialin#copy tftp flash Address or name of remote host []? 192.168.1.17 ! Enter the image file name you want to copy: Source filename []? mica-modem-pw.2.7.3.0.bin Destination filename [mica-modem-pw.2.7.3.0.bin]? Accessing tftp://www-emp/ mica-modem-pw.2.7.3.0.bin... Erase flash: before copying? [confirm]n Loading mica-modem-pw.2.7.3.0.bin from 192.168.1.17 (via FastEthernet0): !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!! [OK - 474939/949248 bytes] Verifying checksum... OK (0xCB52)
207
The image must reside in ash because the modems load this software each time the router is restarted. For IOS versions earlier than 12.0(5), the modem upgrade is done through the copy ash modem command, at an enabled prompt, but not in conguration mode. The following is an illustration of that process:
5300-dialin#copy flash modem Modem Numbers (/[-/] | group | all)? all Name of file to copy? mica-modem-pw.2.7.3.0.bin Type of service [busyout/reboot] reboot
NOTE
Using reboot as the type of service does not upgrade the modems until the next time the router is reloaded. This is handy if there are prescheduled maintenance windows. You can then use the reload at command to schedule the reload for a specic time, in advance.
As a precaution, only use busyout if call volume on the router is low. The router upgrades the modems by busying out all modems and upgrading the groups that have no calls on them. These groups contain either six or 12 modems, depending on type. If calls currently connected prevent modems from upgrading, inbound calls can be rejected with a fast-busy signal because no modems are available. To conrm the upgrade, use the command show modem version to verify that the modems have the new version. For IOS releases later than 12.0(5), the upgrade is done in Software Port Entry (SPE) conguration mode. Use the command show spe version to see what rmware versions are stored in ash on the router and determine which ones require an upgrade. The following lines show the conguration commands required to upgrade spe software:
5300-dialin#configure terminal 5300-dialin(config)#spe 1/0 2/9 5300-dialin(config-spe)#firmware upgrade reboot 5300-dialin(config-spe)#firmware location flash:mica-modem-pw.2.7.3.0.bin
If you want to use reboot as the type of upgrade service, specify this before specifying the location of the rmware. After the location of the rmware is specied, the router begins the upgrade. Because the default is busyout, you can easily busy out every modem on a busy access server if you do not specify this beforehand. To conrm the upgrade, use the command show spe modem to verify that the modems have the new version.
AS5200 Specic Commands and Debugs

There are numerous additional commands for modems in the AS5200 series. Although this product has reached the end of life (EOL), it is still in widespread use so these commands are still worth covering. Only the most useful and most commonly used commands are covered.
208
The rst of these commands is show modem, which shows a list of all modems along with the number of successful and failed incoming call attempts, outgoing call attempts, and a percentage of successful calls. In addition, it displays the current status of every modem: active, busied out, bad, downloading rmware, or pending download. If you prefer to only see the summary of this information, use the command show modem summary. You can almost immediately tell if there is a problem by looking at the success percentage. Most dial-in pools have a 90 percent or higher success rate. Using the same show modem slot/port command (including a specic modem) shows you much more detail about the specied modem, along with all the connection speeds reached with that modem. The show modem call-stats command displays the statistics for all modems and includes reasons for disconnect, compression, number of retrains, and a summary of all the information. Another useful command is show modem connect-speeds, which shows the total number of connections at each speed throughout the range for both receive and transmit. A summary along with percentages is also provided later in the section. This is useful to get a quick glimpse of what your clients are experiencing. A command that you use often when reporting problems to the Technical Assistance Center (TAC) is show modem csm slot/port, which provides the TAC a view of exactly what is occurring with a call switching module (CSM) at that precise point in time. Another command that the TAC often uses to help debug problems is show modem log slot/port. It provides all information about what the modem has done previously. The data is purged on a rst in rst out basis, so use this show command immediately after the problem occurs. The command shows all RS232 events, modem state events, modem analog signal events, and connection events. It also contains information on train-up speeds, modulation, and serial-to-noise ratio. The last of the show commands created for the AS5200 is show modem version, which shows what version of software is on the modems. Always keep this software up to date to obtain the best possible connection for remote users. A separate procedure exists for each kind of modem (see www.cisco.com for further details). The AS5200s also have several added debugging modes. The rst is debug modem oob, which shows information about a modems out-of-band port that polls modem events. The debug modem csm command displays information about the CSM that connects calls. It shows all information about calls coming in from the PRI and what modem it lands on. Perhaps one of the most useful debug commands in dial routers is debug modem trace. With this debug, you can select normal, abnormal, or all reasons for call termination. To gather all abnormal call terminations on the entire router, use the command debug modem trace abnormal. If you want to gather all terminations from a specic modem, in the event that you think a particular modem is malfunctioning, use the command debug modem
209
trace all slot/port. When disconnecting a call that matched the debug, a trace is sent to the screen including everything that took place with the call, down to the nest detail. Finally, there is one other command that is neither a show command nor a debug command. This command is test modem back-to-back slot/port slot/port. It performs a test from one modem to the other to ensure that it can train up and pass data. This test is only done at V.34 speeds.

The commands for the AS5200 also work with the AS5300. The AS5300 added MICA modems along with some unique out-of-band functionality. This allowed for a few more commands to provide real-time information that was not possible before. Most of these commands provide little information, but assist the TAC in quickly determining a problem. The rst of these new commands is show modem conguration, which shows the setup of the modem. Any changes you make to the modem through a modemcap, appears in the output of this command. Another command for the AS5300 is show modem mica slot/port. This is another command that the TAC reviews to help determine a problem. The show modem operational-status slot/port command assists you in determining some problems, without the help of TAC engineers. The following is sample output from this command with additional comments provided to assist with troubleshooting:
5300-dial#show modem operational-status 1/13 Modem(1/13) Operational-Status: Parameter #0 Disconnect Reason Info: (0x0) Type (=0 ): <unknown> Class (=0 ): Other Reason (=0 ): no disconnect has yet occurred
The parameter #0 of the output shows a disconnect reason that identies the type of disconnect, the class of disconnect, and the reason that the disconnect took place. If there is an issue with a user frequently getting disconnected, determine what modem the user was last connected on, and perform this command to obtain information about the disconnection. Parameters #1 and #2 cover the connection protocol and compression:
Parameter #1 Parameter #2 Connect Protocol: LAP-M Compression: V.42bis both
Parameter #3 displays the error correction (EC) retransmission count, or the number of times that the modem has gone into error recovery in the transmit direction for a particular
210
connection. Compare this parameter against the count produced by Parameter #36 (EC packets transmitted, received) to determine if a problem really exists.
Parameter #3 EC Retransmission Count: 193
Parameter #4 shows the error count received during a back-to-back modem test. During any normal active call, this number is 0:
Parameter #4 Self Test Error Count: 0
Parameter #5 shows how long the call is connected in seconds. This client is connected for just over 3 hours and 44 minutes:
Parameter #5 Call Timer: 13491 secs
Parameter #6 shows the number of retrains done by the modems. A high number of retrains identies that the connection made by the client is not stable. This can happen from a dirty phone line, low signal-to-noise ratio (SNR), or even from someone picking up the phone and setting it back down while a modem call is in place over that line:
Parameter #6 Total Retrains: 4
Parameter #7 displays the measure of the receive signal quality (SQ) bit error rate for the current modulation, as estimated by the DSP. A value of 0 has the highest number of errors and 7 has the lowest. This value is used in conjunction with some S values congured on the modem to determine when to speed shift or retrain. If the SQ value reported in this parameter drops to the value of S32 (SQ Threshold) for longer than the value of S35 in seconds, the DSP attempts a downward speed shift or retrain. Similarly, if the SQ value goes above the threshold for longer than the value of S34 in seconds, an upward speed shift or retrain occurs. Parameters #8 and #9 show the connection standard and current connection speed of the modem. This real-time data and might not be the same for the connecting client. The client uses a modem that does not have out-of-band signaling and only knows the initial connection speed:
Parameter #7 Parameter #8 Parameter #9 Sq Value: 3 Connected Standard: V.90 TX,RX Bit Rate: 50666, 28800
Parameter #11 displays the transmit symbol rate that transmits samples to the line and the receive symbol rate that receives samples from the line:
Parameter #11 TX,RX Symbol Rate: 8000, 3200
Parameter #13 displays the transmit carrier frequency in Hertz that the local DCE uses and the receive carrier frequency that the remote DCE uses:
Parameter #13 TX,RX Carrier Frequency: 0, 1829
Parameter #15 shows trellis coding. Trellis coding adds dependency between symbols to make the detection in noise more robust (forward error correction [FEC]). Trellis coding is displayed in values. The value of 0 correlates to a connection standard V.22, V.22bis, V.21,
211
Bell212, Bell103, V.29, or V.27. The value of 8 correlates to a connection standard of V.32, V.32bis, or V.17. The value of 16, 32, or 64 correlates to a connection standard of V.34, V.34+, V.90, or K56Flex:
Parameter #15 TX,RX Trellis Coding: 0, 16
Parameter #16 shows the preemphasis index, which involves shaping the raw transmit spectrum to deal with spectrum roll-offs. A zero denotes no reshaping. This index is used only with V.34 and V.34+ connection standards:
Parameter #16 TX,RX Preemphasis Index: 22, 0
Parameter #17 shows if constellation shaping is used. Constellation shaping is a technique for improving noise immunity by using a probability distribution for transmitted signal points. The signal states predict the sensitivity to certain transmission impairments. Constellation shaping is used only with the V.34 and V.34+ connection standards. Values displayed by this parameter are either Off or On:
Parameter #17 TX,RX Constellation Shaping: Off, Off
Parameter #18 shows if nonlinear encoding is used. Nonlinear encoding occurs during the training phase and moves the outer points of the constellation away to deal with nonlinear distortion. Nonlinear distortion tends to affect the higher-powered signals. Moving the outer constellation points out reduces the chance of error. Nonlinear encoding is used only with the V.34 and V.34+ connection standards. Values displayed by this parameter are either Off or On:
Parameter #18 TX,RX Nonlinear Encoding: Off, Off
Parameter #19 shows if precoding is used. Precoding serves the same purpose as the preemphasis index, but instead manages the bits and not the raw transmit signals. This management is done only when asked for and therefore occurs only in the receive mode. Precoding is used only with the V.34 and V.34+ connection standards. Values displayed by this parameter are either Off or On:
Parameter #19 TX,RX Precoding: Off, Off
Parameter #20 shows the transmit level reduction. The transmit level affects the transmit signal by reducing it in a range of 0 to 15 dBm. If nonlinear distortion is detected on either end, the modem detecting this distortion requests a lower-powered transmit signal. Transmit level reduction is used with the V.34 and V.34+ connection standards:
Parameter #20 TX,RX Xmit Level Reduction: 0, 0 dBm
Parameter #21 shows the SNR. This is the ratio on the server side and should not change. The SNR on the client side is determined by issuing the command ati11 on the modem after disconnect. The higher the number, the better:
Parameter #21 Signal Noise Ratio: 36 dB
Parameter #22 shows that the power of the received signal ranges from 0 to -128. The optimum range for the receive level displayed by this parameter is from -12 dBm to -24 dBm:
Parameter #22 Receive Level: -23 dBm
212
Parameter #23 shows the frequency offset, which is a shift in the receive spectrum between the expected carrier frequency and the actual carrier frequency. The typical value is 0 Hz:
Parameter #23 Frequency Offset: 0 Hz
Parameters #24 and #25 deal with phase jitter. This is found only in analog trunk circuits. Typical frequencies are power generation frequencies and their harmonics (that is, 60 and 120 Hz within the U.S; 50 and 100 Hz international). MICA modems cancel all frequencies of phase jitter:
Parameter #24 Phase Jitter Frequency: 0 Hz Parameter #25 Phase Jitter Level: 0 degrees
Parameter #26 displays the far-end echo level (the portion of the transmitted analog signal that has bounced off of the analog front end of the remote modem), which can range from 0 to -90 dBm. A MICA modem cannot handle near-end echo if far-end echo is present and the round-trip delay is greater than ten microseconds. This constraint comes from the number of taps in the echo canceller of MICA modems. The reported far-end echo level must be less than -55 dBm to achieve a V.34+ connection. A greater echo level indicates a digital-to-analog conversion in the path between the MICA modem and the switch:
Parameter #26 Far End Echo Level: -47 dBm
A form of this signal/constellation pattern echoes off equipment at the central ofce and is sent back to the MICA modem. However, the constellation shape might be rotated from its original position. This rotation is called the phase roll. It is shown in degrees of rotation in Parameter #27. The echoed signal consists of a frequency component and a phase component. If the frequency component changes at all, a correction is needed for echo cancellation to work correctly. The typical value is 0 or close to 0:
Parameter #27 Phase Roll: 0 degrees
Parameter #28 shows round-trip delay, which is the total round-trip from modem to modem in microseconds. This delay is important for proper echo cancellation:
Parameter #28 Round Trip Delay: 7 msecs
Parameter #30 displays the total count of characters sent and received before any modem compression takes place:
Parameter #30 Characters transmitted, received: 11116387, 2693386
Parameter #32 is included but not used. Other parameters, such as 10, 12, 14, 34, and 37 do not even show up in the output:
Parameter #32 General Portware Information: 22
Parameters #33 and #35 show the number of packets transmitted and received by the dial server from the client modem. This is useful in determining whether or not the modems are passing trafc to each other:
Parameter #33 PPP/SLIP packets transmitted, received: 24080, 23583 Parameter #35 PPP/SLIP packets received (BAD/ABORTED): 0
213
Parameter #36 displays the number of EC packets transmitted and the number of EC packets received:
Parameter #36 EC packets transmitted, received OK: 53258, 48144
Parameter #38 shows the moving average of EC packets. One way to determine if the connection has gotten better or worse with speedshifts and retrains is to check the moving average several times over the duration of a call. If the value decreases, the connection has become more stable:
Parameter #38 Moving Average of EC packets (Received BAD/ABORTED): 88
Parameter #39 shows what robbed bit signaling pattern is used. If robbed bit signaling is detected, the dial server must run a pattern so that the missing bit does not affect data transfer. As long as this is a 0, there is no RBS line between the server and the client:
Parameter #39 Robbed Bit Signalling (RBS) pattern: 0
Chapter 5, Dial Technology Background, provided an explanation of the digital pad. Cisco dial servers try to avoid the problems incurred by the use of digital pads on a link. Parameter #40 shows if the dial server detected a digital pad and the compensation status:
Parameter #40 Digital Pad: 6.0 dB, Digital Pad Compensation: Enabled
Parameters 41 through 44 deal with V.110 calls. These parameters show frames received bad, frames received good, frames transmitted, and number of times synchronization has been lost. Because this is a V.90 call, the values are always 0:
Parameter Parameter Parameter Parameter #41 #42 #43 #44 V110/PIAFS V110/PIAFS V110/PIAFS V110/PIAFS frames received bad: 0 frames received good: 0 frames transmitted: 0 sync lost: 0
The last piece of information to specically review from the show modem operationalstatus output is the line shape. The MICA modems use the V.90 Digital Impairment Learning (DIL) sequence to determine the quality of the line and how much of the line is usable for data. Even if the DIL shows that V.90 is not feasible for the client modem connecting, it does store this information and trains up in V.34 mode. When reviewing the line shape, you want the vertical line created by the asterisks to be as straight as possible. As the line is more curved at the beginning and the end, the maximum attainable connection speed drops. Example 7-30 shows the line shape output.
214
Example 7-30 Line Shape

.........................* ................................* .................................* .................................* ................................* ................................* ................................* ................................* ................................* ................................* ................................* ................................* ................................* ................................* ................................* ................................* ................................* ................................* ................................* ................................* ................................* ................................* ...............................* .............................* .........................*
In this case, the line is mostly straight. Also, if you noticed the speed from parameter 9, the connection speed attained in the example is 50,666 baud, which is almost as good as you can get with a 56 k modem. The only debugs added for the AS5300s are MICA modem debugs. The command debug modem mica displays the status of software downloads to the modems.

With the introduction of the AS5400, most of the modem commands changed. The following is a list of the commands from the AS5200 and AS5300 that exist in the AS5400 under a different command:
show modem changed to show spe modem. show modem version changed to show spe version. show modem log changed to show spe log. show modem summary changed to show spe modem csr summary. show modem connect-speeds changed to two separate commands: show spe modem high shows high-speed modulation connects. show spe modem low shows low-speed modulation connects.
Review Questions
215
The rst of the two newly added show commands is show spe modem active slot/spe. It is not really a new command, but because modem types changed from MICA to NextPort modems, this command replaces the show modem operational-status from the AS5300s. Unfortunately, this command only works when the modem is active. To view the disconnect reason for a specic disconnected modem, refer to the command show spe log slot/spe. The other helpful command is show spe modem disconnect-reason [slot/port | summary]. This command reveals the allocation of disconnect reasons that the particular slot and/or port on that specic modem has encountered. When reviewing the summary, it displays the total number of disconnects for each disconnect reason. This provides a quick indication of how many modem train-up failures took place. Show commands are not the only thing that changed between the AS5300 and the AS5400. Most of the debug commands changed or are no longer available. The debug modem csm changed to debug csm modem and the debug modem trace command changed to debug spe modem trace. Many specialized debugs added for the AS5400 deal with the NextPort engine and modules. The details of each are more than this book can cover. If you are experiencing a problem where these debugs are required for troubleshooting, the TAC can instruct you on which debugs to run and provide the required output.
Summary
This chapter follows the troubleshooting methodology suggested in Chapter 4, Troubleshooting Approaches, Models, and Tools, with a layer-by-layer, phase-by-phase approach to remote access dial issues. Some of the topics of the chapter, such as detailed troubleshooting NAS WAN Links and T1s PRIs, are relevant to other parts of the book. This chapter includes an extensive amount of information about troubleshooting dial-in and dialout services, where the modems operational status is covered in greatest detail. The specics of the different NAS platforms provided in this chapter can serve as a practical troubleshooting manual when dealing with all the different platforms of 5x00 NASs.
Review Questions
1 What SQ value shows up in the output of show modem operational-status,
indicating the most stable connection possible?

2 True or False: Upgraded modem rmware does not have to be stored in ash after it
is copied to the modem.
216
3 What is the controller conguration command required to correctly congure the
distance of a circuit that is 639 feet?

Router(config-controller)#cablelength short 655
4 If you are receiving a blue alarm, what bit pattern is the equipment receiving? 5 What color is an alarm in which the controller status shows Receiver has loss of
Frame?
6 What happens if one end of a T1 receives a yellow signal? 7 What information is negotiated in the IPCP stage of NCP of a modem dial call? 8 What modem AT command shows the connection information for a call that was
previously disconnected?
9 What does BERT stand for? 10 What is the primary advantage that the AS5300 MICA modems have over the
Microcom modems in the AS5200 series?

11 What does the call timer show? 12 What command on an AS 5200 and AS5300 shows a summary of all disconnect
reasons and the number of disconnects for every reason?

13 What does CSM stand for and what is the command to show the processes of this
device?
CHAPTER
Dial Troubleshooting Scenarios

Many problems can occur through the train-up, authentication, and Point-to-Point Protocol (PPP) negotiation phases when making a dialup connection. In all cases, it is best to take a step-by-step approach through the connection until you nd the area where the problem occurs. This book cannot cover the details of all that can occur in the case of train-up failures or slow speed connections, but it does provide many helpful hints, tips, and tricks to assist with dial troubleshooting. The authentication and PPP negotiation stages can be resolved to the point of nding the exact cause of the problem almost every time. In certain cases, the provider or telephone company (telco) might be required to x the issue. Five troubleshooting scenarios are provided in this chapter. Each scenario covers the most common troubleshooting issues that occur and how to pinpoint the exact causes of the problems. Following the scenarios are frequently asked questions with answers that can help you with common troubleshooting issues that dont always have clear solutions, or that have causes that cannot be pinpointed without more expertise. The topics covered in this chapter are as follows:
Scenario 1: Authentication Time OutsPart I Scenario 2: Authentication Time OutsPart II Scenario 3: Frequent Retrains and Disconnects Scenario 4: Dirty Phone Line Scenario 5: Bad Modem Frequently Asked Questions and Answers
Scenario 1: Authentication Time OutsPart I

A user calls in to report that his modem wont authenticate successfully. It seems to be stuck at the verifying username and password stage. First, you use the command #debug ppp negotiation to debug the problem.
220
Chapter 8: Dial Troubleshooting Scenarios
After debugging the problem, the output in Example 8-1 is produced.

Example 8-1 Output from debug ppp negotiation for Authentication Time OutsPart I
Mar Mar Mar Mar Mar Mar Mar Mar Mar Mar Mar Mar Mar Mar Mar 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 13:38:46.291: 13:38:46.291: 13:38:46.291: 13:38:46.862: 13:38:46.862: 13:38:47.394: 13:38:47.394: 13:38:47.394: 13:38:47.919: 13:38:47.919: 13:38:48.488: 13:38:48.488: 13:38:48.488: 13:38:48.812: 13:38:48.812: As1 As1 As1 As1 As1 As1 As1 As1 As1 As1 As1 As1 As1 As1 As1 LCP: LCP: LCP: LCP: LCP: LCP: LCP: LCP: LCP: LCP: LCP: LCP: LCP: LCP: LCP: I CONFREQ [ACKrcvd] id 66 len 14 As1 LCP: AuthProto PAP (0x0304C023) MagicNumber 0xBC6B9F91 (0x0506BC6B9F91) O CONFNAK [ACKrcvd] id 66 len 9 AuthProto CHAP (0x0305C22305) I CONFREQ [ACKrcvd] id 67 len 14 AuthProto PAP (0x0304C023) MagicNumber 0xBC6B9F91 (0x0506BC6B9F91) O CONFNAK [ACKrcvd] id 67 len 9 AuthProto CHAP (0x0305C22305) I CONFREQ [ACKrcvd] id 68 len 14 AuthProto PAP (0x0304C023) MagicNumber 0xBC6B9F91 (0x0506BC6B9F91) O CONFNAK [ACKrcvd] id 68 len 9 AuthProto CHAP (0x0305C22305)
The output in Example 8-1 continues until the modems disconnect. In this example, the link control protocol (LCP) never completes and does not change to an open state. The client and server must agree on the authentication type (Password Authentication Protocol [PAP], Challenge Handshake Authentication Protocol [CHAP], or Microsoft CHAP [MS CHAP]) before LCP can change to an open state and allow authentication. In this case, the client requests PAP authentication and the server requires CHAP authentication, as shaded in Example 8-2.
Example 8-2 Excerpt of Example 8-1 with CHAP and PAP Commentary
! Non-acknowledgment is sent back saying no to PAP and requesting CHAP: Mar 2 13:38:46.862: As1 LCP: O CONFNAK [ACKrcvd] id 66 len 9 Mar 2 13:38:46.862: As1 LCP: AuthProto CHAP (0x0305C22305) ! Request comes in asking to authenticate via PAP: Mar 2 13:38:47.394: As1 LCP: I CONFREQ [ACKrcvd] id 67 len 14 Mar 2 13:38:47.394: As1 LCP: AuthProto PAP (0x0304C023) Mar 2 13:38:47.394: As1 LCP: MagicNumber 0xBC6B9F91 (0x0506BC6B9F91)
The client sends a conguration request to the network access server (NAS) requesting PAP authentication. The NAS sends a non-acknowledgment back to the client that denies PAP authentication and asks for CHAP authentication. The client only knows how to authenticate through PAP and resends its request for PAP authentication. This continues in a loop until a disconnect timer ends the call. The x is implemented by making sure that the authentication protocols on both ends are the same. If the service is supposed to authenticate through CHAP, the end user must recongure the dial client to use CHAP authentication. If the service is supposed to allow PAP authentication, the router must be recongured to accept PAP authentication.
Scenario 3: Frequent Retrains and Disconnects
221
In this case, the service was supposed to accept only CHAP, so the end user recongured the dial client and then reconnected.
Scenario 2: Authentication Time OutsPart II

An end user calls up and states that the connection hangs during the verifying username and password stage of the connection. This time, the problem seems to be widespread. Again, the command #debug ppp negotiation is used to log the connection while the client tries to dial in. After debugging, you see the LCP information in Example 8-3 repeat itself.
Example 8-3 Output from debug ppp negotiation for Authentication Time OutsPart II
Mar Mar Mar Mar Mar Mar Mar 2 2 2 2 2 2 2 19:58:19.768: 19:58:19.768: 19:58:19.768: 19:58:19.768: 19:58:19.768: 19:58:19.768: 19:58:21.768: As1 As1 As1 As1 As1 As1 As1 LCP: LCP: LCP: LCP: LCP: LCP: LCP: O CONFREQ [REQsent] id 74 len 25 ACCM 0x000A0000 (0x0206000A0000) AuthProto PAP (0x0304C023) MagicNumber 0x5779D9D2 (0x05065779D9D2) PFC (0x0702) ACFC (0x0802) TIMEout: State REQsent
The debug output in Example 8-3 happens every two seconds until the modems disconnect. If you review the output carefully, the only event that occurs is outgoing LCP packetsO CONFREQ. This type of problem usually occurs because of a speed mismatch between a router and a modem, which is why the problem seems so widespread. Any user connecting to this modem would have the same problem. This should occur only when there is an external modem attached to the router. The x involves verifying whether the speed is set the same on both the modem and the router. In this case, the modem is congured with a line speed of 15200 instead of 115200. It is xed by issuing the line conguration command speed 115200 on the client modem.
Scenario 3: Frequent Retrains and Disconnects

To the client, frequent retrains or speedshifts are reported as a bad connection, where data ow is interrupted often. In most cases, a client does not hear the modem retrain because the speaker is turned off after the rst train-up is successful. If you encounter a problem such as this, you can easily determine if the modem is retraining frequently. Just look at the output of the show modem operational-status command for the modem that this client last connected to or is currently connected to. Pay particular attention to the following output of these connections:
Parameter #5 Parameter #6 Call Timer: 1001 secs Total Retrains: 11
222
This shows that the user has retrained 11 times in the last 1001 seconds. Looking further down the output, other information about the users connection also helps (only the parameters necessary to review are shown; the other parameters were omitted from the output):
Parameter Parameter Parameter Parameter Parameter #8 #9 #21 #39 #40 Connected Standard: V.90 TX,RX Bit Rate: 49333, 31200 Signal Noise Ratio: 39 dB Robbed Bit Signalling (RBS) pattern: 0 Digital Pad: None, Digital Pad Compensation: Enabled
The client achieves a good speed for both upload and download, modulation is V.90, signalto-noise ratio is good, and no robbed bit signaling or digital pad events are affecting the call. Even further down in the output of the show modem operational-status command is a section for line shape. Check the line shape, as shown in Example 8-4.
Example 8-4 Line Shape of Frequent Retrain and Disconnect Problems
Line Shape: ..........................* ................................* .................................* .................................* ................................* ................................* .................................* ................................* ................................* ................................* ................................* ................................* ................................* ................................* ...............................* ...............................* ...............................* ...............................* ...............................* ..............................* ..............................* .............................* .............................* ...........................* ......................*
Overall, the line shape is not that bad. Remember, this line must be as vertical as possible. It does tail off slightly at the low and high frequencies, but neither of the extremes is too bad. Because everything checks out except for the retrain number, start with the simplest thing that might eliminate the problem. The rst of these is call waiting. Call waiting produces a beep when an incoming call comes in. This beep can upset the connection and
Scenario 4: Dirty Phone Line
223
force a retrain. Having the user dial *67 before the phone number disables call waiting in most cases. Check with the local telco if this does not work. A short in the cable that goes from the PC to the wall jack can be another source of trouble. It might be that the cable is ne, but that the PC has been bumped, and the connection has a short, which causes speedshift or retrain problems. This can also occur with other phones around the house. Another quick test is to unplug all the phones that are connected to that line and perform another test call. If two phone lines exist at the same location, a phone line problem can also be ruled out by trying to call over the other phone line. If none of these solutions helps the problem, software might be a good place to turn next. Because modem software is updated frequently because of bug xes, technology advancements, and stability improvements, you must make sure that the modems in the NAS are running the latest Technical Assistance Center (TAC) recommended software. If the modem code on the NAS is up to date, proceed by asking the end user to upgrade his modem code to the latest version. Modems that are driven from software, such as Lucent WinModems, typically have new driver versions available more often than rmware-based modems. Finally, if all else fails, a modem hardware problem might exist. When all other possible solutions are exhausted, recommend using a different modem to see if the problem disappears.
Scenario 4: Dirty Phone Line

A dirty phone line usually does not have the same symptoms as frequent retrains and disconnects; however, they do occur. In this case, the primary issue that the client reports is that the speed of the connection is unacceptable. The same outputs as Scenario 3: Frequent Retrains and Disconnects are provided here, except that these outputs show a modem that is connected to a dirty phone line. Again, the command to use is show modem operationalstatus while having the client attempt a connection. The output is shown in Example 8-5.
Example 8-5 The show modem operational-status Output with a Dirty Phone Line
Parameter #5 Call Timer: 10682 secs Parameter #6 Total Retrains: 12 <output omitted> Parameter #8 Connected Standard: V.34+ Parameter #9 TX,RX Bit Rate: 26400, 26400 <output omitted> Parameter #21 Signal Noise Ratio: 35 dB <output omitted> Parameter #39 Robbed Bit Signalling (RBS) pattern: 0 Parameter #40 Digital Pad: None, Digital Pad Compensation: None
224
There are many retrains over the length of the call, the speed is much lower, and the signalto-noise ratio is lower. The line shape from the end of the show modem operational-status output shows just how bad the line is, as shown in Example 8-6.
Example 8-6 Line Shape from a Dirty Phone Line
...........................* .................................* .................................* ................................* ...............................* ...............................* ..............................* ..............................* .............................* ............................* ...........................* ...........................* ..........................* ..........................* .........................* ........................* ........................* .......................* .......................* ......................* .....................* .....................* ....................* ..................* ............*
The line tapers off drastically compared to that of a clean line. Because of this reaction, bandwidth is signicantly limited, which makes the connection slower. You can use this data to tell the client that their phone line is the problem. The recommended x is for the user to notify his telco of this problem and, if possible, have it resolved. In most cases, the telco will rst test the line to see where a possible problem might exist. A wide variety of things might need to be xed, including replacing a bridge tap or repeater. The problem might also exist in a faulty line card at the central ofce (CO). The telco might even change the pair of wires that your phone is delivered on. Not all problems can be resolved by the telco. In cases where the distance between the CO and home is too great, there is no x for slow connections.
Scenario 5: Bad Modem
225
Scenario 5: Bad Modem

A bad modem is not something generally reported by your clients. A modem that is experiencing problems usually does not mark itself as defective unless there is an obvious hardware problem. Instead, you must analyze the modem with the show modem command. An output from show modem is provided in Example 8-7, where a group of six modems are obviously bad. In the AS5300 access server, modems generally become faulty in groups of six or 12, depending on the types of modems in the device.
Example 8-7 Output of show modem Showing a Bad Modem Card
Mdm * 1/0 * 1/1 * 1/2 * 1/3 * 1/4 * 1/5 <output * 1/30 * 1/31 * 1/32 * 1/33 * 1/34 * 1/35 Avg Hold Time 00:57:37 01:02:03 01:08:09 00:52:28 00:48:24 00:57:55 omitted> 01:04:09 00:46:53 00:53:40 00:53:00 00:48:18 00:58:22 Inc calls Succ Fail 408 7 397 8 374 8 419 7 434 8 417 5 350 409 366 384 393 362 36 41 43 37 38 39 Out calls Succ Fail 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 Busied Out 0 0 0 0 0 0 0 0 0 0 0 0 Failed Dial 0 0 0 0 0 0 0 0 0 0 0 0 No Answer 0 0 0 0 0 0 30 30 30 29 30 30 Succ Pct. 98% 98% 98% 98% 98% 99% 91% 91% 89% 91% 91% 90%
The rst six modems perform as they are supposed to. There are always a few bad calls because of people dialing the number with a telephone, calls cancelled after they have been placed, or other user initiated errors. However, when a group of modems in sequence (in groups of six with Modem ISDN channel aggregation [MICA]) are all showing a much higher number of failed incoming calls, the modems are not working properly. What is of interest in determining a bad modem can be seen in the next group of six. The call success ratio dropped eight to ten percent below that of the good modems. Also, these modems have not answered some calls, as noted by the column labeled No Answer. These modems likely became faulty recently because the output shows that they also have received many successful calls. Approximately the last 30 calls were answered by each modem, but not connected, which forced the customer to place the call again. To x this problem, these modems must be replaced. For companies that have a scheduled maintenance period, you can mark the modems as bad until the defective hex modem modules are replaced. To mark the modem as bad, use the line conguration command modem bad. This stops any future calls from being accepted on these modems:
5300-dialin(config)#line 31 36 5300-dialin(config-line)#modem bad
226
Frequently Asked Questions and Answers

The questions and answers in this section apply to the majority of users. These solutions will generally x the problems you or your clients are experiencing. If you still have a problem after taking into account everything listed here, search Ciscos web site for more recent troubleshooting information and, if required, open a TAC case for further investigation. Question: How can I achieve faster connection speeds? Answer: To start, some situations simply cannot be helped or improved. First, make sure that the point of presence (POP) that you are dialing is V.90- or V.92-enabled by asking your provider. Line quality and the distance of the user from the CO limit connection speeds and quality. More than any other factor, this is the most important to remember. With that being said, other reasons exist for slow connection speeds. If applicable, always start by making sure that the connecting modem has the latest drivers and rmware. As with client modems, ensure that the dial servers are running the latest TAC recommended software. Although the modems might not be new, the software running on them is constantly being upgraded to support new features such as modem call waiting and quick connections. The distance to your CO is measured in cable feet. It is good to know how far away you are from the CO. Anything under three miles should achieve an acceptable connection speed with V.90 modulation, unless there is a line quality issue. You can have the telco check your line for the signal-to-noise ratio, which should be at least 40 decibels. If you are dialing a local POP and still receive poor connection speeds, it might be a pad issue. Dial the full 10 digits to see if changing the pad to 6 dB xes the problem. This is the extent of what you can try to improve a slow connection speed. If you feel there is something still wrong, you can open a case with the TAC to investigate specic issues. Question: My clients complain about getting disconnected frequently. What can be done to stop this? Answer: The answer to this question is the same as for the previous question. Slow connections and frequent disconnects are both caused by incompatible modems. First, rule out any simple problems such as an idle-timeout, call waiting, a bad phone cable between a jack and PC, or another phone causing the problem. If it is not one of these factors, it is most likely a software problem that can be xed by upgrading drivers on the client modem or modem rmware on the dial router. Question: When dialing in, my clients receive a fast busy signal. How can I x this? Answer: Two possible causes exist for this problem. The easiest way to troubleshoot this is to turn on ISDN Q931 debugs to determine if calls are reaching the router. If the calls are not reaching the router, the fast busy is generated by a problem in the telco, possibly because of an overloaded switch or switch path.
Frequently Asked Questions and Answers
227
If the call successfully reaches the router, this indicates that the router does not know what to do with the call. The rst thing to check is that every Primary Rate Interface (PRI) has the line isdn incoming-voice modem in its serial interface conguration. This command instructs the router to send any voice calls that come in over that PRI to a modem. The next thing to check is that there are enough modems in each router for the total number of digital service 0s (DS0s). If you only have 60 modems and 92 DS0s (4 PRI worth), the 61st voice (modem) call received will get a fast busy signal. Question: My clients receive a slow busy signal but plenty of modems are free. How can I x this? Answer: It could be possible that the DS0s are at peak capacity, but that modems are still available. If this is the case, it is time to order more circuits from the telco. If DS0s are available, use the command show isdn status to verify that Layer 2 is MULTIPLE_FRAMES_ESTABLISHED. If not, see Chapter 7, Dial Troubleshooting, for PRI troubleshooting. If the PRI is up and working, use the command show isdn service to determine if any of the channels are out of service. Channels of a PRI are usually idle or busy. If they are out of service, you must open up a ticket with the provider to clear the out of service channels. Question: I have a large Non-Facility Associated Signaling (NFAS) group congured on a dial router. According to the D channel, calls are successfully connected, but some of the NFAS circuits dont ever seem to take calls. How can I troubleshoot what is happening with the calls? Answer: Because the D channel is one circuit that controls the incoming calls on all the other circuits, it is possible to have two or more circuits that contain out of order B channels. If they are out of order, the D channel still receives the incoming call notication, but it opens up the wrong B channel for data transfer. This results in the true incoming call being unable to connect because the call is not mapped to a modem. The solution is to verify the correct location for each circuit by any means possible, including tracing cables and getting help from your provider. Question: When dialing in, some users do not get IP addresses. How can I troubleshoot this? Answer: If you are using a locally congured pool of addresses, perform the command show ip local pool pool name, which shows both the in-use addresses and the addresses not in use. The in-use addresses show the username using that address. The addresses that are not in-use show the username of the last person to get that IP address. If all IP addresses in the pool are in use, the pool range is too small and must be increased. If you are using a Dynamic Host Conguration Protocol (DHCP) server to provide IP addressing, verify that the DHCP server is reachable and verify that it has enough
228
addressing for the number of DS0s in your dial router. Also, verify that leases do not stay active too long. The lease should expire when the client disconnects. Question: When some of my clients dial up, they get classful subnet masks. Does this affect anything? Answer: No. PPP is a Point-to-Point Protocol, which means that the client modems send everything down the pipe. Even if they have the wrong subnet mask, their peer (the dial router) knows how to route the trafc correctly and this should not adversely affect them. Question: How much of a problem do one-time passwords pose for dial-in users? Answer: First, having one-time passwords means that the end users have an extra step in dialing up. This generates trouble tickets by itself. Also, you must remember the type of one-time password that youre using because two different types exist: time-based and single-use. Time-based passwords are only good for a certain period of time, so be careful not to limit the time too much because of the 20-30 seconds it takes for the modems to train-up. Using 60- or 120-second passwords seems to work well and anything less generates numerous trouble tickets. Single-use passwords rely on an algorithm that puts passwords in order. These tend to be more user-friendly because the end user can take as much time between getting the password and connecting. Question: How does Virtual Private Networking (VPN) over dial affect throughput and latency? Answer: As always, this depends on the Internet, which can provide both positive and negative aspects. If you connect at any speed above 28,800 bps, the VPN overhead is minimal, especially if you use compression over the VPN connection. Latency is affected by the delay between the POP and the VPN concentrator. Most of the time, this is less than 50 ms, which is hardly noticeable over dial. One factor that usually suffers with VPN over dial is real-time applications, such as Telnet, Secure Shell, and any other command-line interface.
Summary
This chapter included some common, real-life scenarios designed to demonstrate the dial troubleshooting techniques discussed in Chapter 7. Another objective of this chapter is to give the troubleshooting engineer some practical recommendations and answers to some of the most commonly asked questions.
PART
III
ISDN
Chapter 9 ISDN Technology Background Chapter 10 ISDN Design Solutions Chapter 11 Cisco ISDN Conguration Solutions Chapter 12 ISDN BRI Troubleshooting Chapter 13 Troubleshooting Scenarios for ISDN BRI
CHAPTER
ISDN Technology Background

ISDN was developed by telephone companies (telcos) as an end-to-end out-of-band digital technology well suited for data, voice, and video streams. Connectivity over ISDN offers end users increased bandwidth, reduced call setup time, reduced latency, and gave a lower signal-to-noise ratio (SNR). Being a dialup service (fast dial is another name for ISDN), the technology carries digital signaling. In the United States, the ISDN denitions are described in National ISDN standards (NI) to ensure interoperability between a variety of services and providers. The standard denes architecture layers, services, protocols, channels, reference points, and devices. The main topics of this chapter are as follows:
ISDN standards, ISDN channels, and ISDN layered architecture Layer 1, Basic Rate Interface (BRI) ISDN devices, reference points, and interfaces Layer 2 in D channel Link Access Procedure on the D channel (LAPD) Layer 3 in D channel Q.931 ISDN switch types
ISDN Standards
From the end of the 1960s and up to the mid 1980s, a comprehensive set of standards dened the ISDN technology. The T sector of the International Telecommunication Union (ITU-T) was created in 1993 as a replacement for the former Comit Consultatif International Tlphonique et Tlgraphique (CCITT) with an initial 15 study groups. This organization issued protocols in three different series as dened in the sections that follow.
E-Series
E-Series protocols, developed for overall network operation, telephone service, service operation, and human factors, standardize the telephone networks for ISDN. ITU-T recommendation E.167 for example, denes the ISDN network identication codes.
234
Chapter 9: ISDN Technology Background
I-Series
I-Series protocols are grouped into three main categories and are designed for the standardization of concepts, terminology, and general methods related to users, UserNetwork Interfaces (UNIs), and Network-to-Network Interfaces (NNIs). I-Series standards, which are designed for ISDN, start from I.110 and end with I.762. I.431, for example, denes the Primary Rate Interface (PRI), and I.432 denes the BRI.
Q-Series
Q-Series protocols, which are designed for switching and signaling, dene the standards of switching and signaling schemes and techniques. The Q.921 standard, for example, describes the ISDN data-link processes of LAPD, which functions as Layer-2 processes in the International Organization for Standardization/Open System Interconnection (ISO/ OSI) reference model. Q.931 species ISO/OSI reference model Layer 3 functions.
ISDN Channels
In ISDN, the local loop carries only digital signals that represent signaling information and user data. The local loop typically carries voice, data, or video. The term channel, unlike other techniques, means a unidirectional conduit that carries signaling and user information. Three basic channels are dened by the standards:
D channel (Delta channel, signaling channel)The D channel is a packet-switched channel that carries signaling and control information for B channels between the customer premises equipment (CPE) and the network. It can also be used for user data. Typically, the D channel provides signaling for one or more ISDN access points. When providing signaling for more than one ISDN access point, the D channel saves equipment and resources (see NFAS Groups in Chapter 12, ISDN BRI Troubleshooting, Scenario 4). It operates at 16 or 64 kbps, depending on the implementation. B channel (Bearer channel)The B channel carries user data, including data, voice, and video. It operates at digital signal level 0 (DS-0) rates (64 kbps). It can be used for both circuit and packet-switching. The B channel also provides additional services depending on the signaling information from the D channel. H channel (Hybrid channel)The standard denes H0, H10, H11 and H12, which operate at rates of 384 kbps, 1.472 Mbps, 1.536 Mbps, and 1.920 Mbps respectively. The H0 channel is a logical grouping of six B channels, and the H11 is equivalent to four H0 channels. The H channels are used for user information that requires higher speeds such as high quality video, high-speed data, and facsimile.
ISDN Channels
235
NOTE
D, B, and H channels were dened in the rst ISDN standard and are known as narrowband ISDN (NISDN). A later set of standards called communication services was dened to provide data rates for up to 622 Mbps. These services were designed for multimedia services and are known as Broadband ISDN (BISDN). The focus of this book is on NISDN.
All types of channels share one physical medium. B and D channels dene the BRI, as shown in Figure 9-1. For the BRI, the D channel uses time-division multiplexing (TDM) technology to provide the signaling. The same applies for the PRI, but unlike BRI, PRI in the U.S. and Canada uses 23 B channels (from number 1 to number 23 and one D channel (number 24). For its practical use, the D channel can be the following: 0 = Idle 1 = Propose 2 = Busy 3 = Reserved 4 = Restart 5 = Maint_Pend There is a predened time slot for every channel, which is typical of synchronous TDM. See Chapter 3, The Cloud for more information on synchronous TDM. The PRI is dened differently for European and Asian countries.
Figure 9-1 ISDN BRI and PRI Channels Basic Rate Interface (BRI)
2 B Channels 2B * 64 kbps 1D * 16 kbps
D Channel
Primary Rate Interface (PRI)

23B Channels N1,N2,N3,N4... N23 23Bx64 kpbs
D Channel-N24
1Dx64 kbps
236
The ISDN network architecture is a roadmap that provides detail sufcient to guide ongoing network planning, design, and implementation. At the same time, the ISDN layered architecture matches the suggested layer-by-layer approach to troubleshooting in this book.
ISDN Planes: ISDN Layer Architecture

As with every technology, the ISDN architecture creates a framework for more informed decision making, including appropriate investments in network technologies, products, and services. The CCITT denes the ISDN architecture to consist of four planes:
C-planeControl plane U-planeUser plane T-planeTransport plane M-planeManagement plane
The C-plane primarily deals with UNIs and establishing and tearing down the calls, and, the U-plane deals with User-Network data carried by the B channel. When troubleshooting ISDN, it is important to remember how the ISDN protocol architecture relates to the OSI reference model. Unlike other technologies, ISDN covers the physical, data link, and network layers, which match the rst three layers of the OSI model. The three protocol layers for the B and D channel are dened in the following list and in Table 9-1:
Layer 1Denes the physical connection between the terminal equipment (TE) and the network termination (NT) including connectors, linecoding schemes, framing, and electrical characteristics. The physical connection can be point-to-point or pointto-multipoint with a short or extended passive bus. Layer 2Describes the LAPD, also known as Q921, which provides error-free communication over the physical link and denes the communication between the user and the network. It also denes the rules for multiplexing in point-to-multipoint implementations. Layer 3Denes the signaling messages for the initial call setup and the termination of the call as dened in Q.931.
Table 9-1 OSI Layer Physical
OSI and ISDN Layers ISDN Layer Layer 1 ISDN Protocols I.430 I.431 I.432 Description Layer-1 specications PRI BRI Channel Shared between B and D channels
237
Table 9-1 OSI Layer Data Link
OSI and ISDN Layers (Continued) ISDN Layer Layer 2 ISDN Protocols Q.920(I.440) Q.921(I.441) Q.921bis Point-to-Point Protocol (PPP), (high-level data link control (HDLC) Description Data link layer general aspects LAPD specications LAPD conformance testing B channels Channel D channel
Network
Layer 3
Q.930 Q.931 (I.450) Q.931bis Q.932 (I.451) AppleTalk, Connectionless Network Service (CLNS), DECnet, Internet Protocol (IP), Internetwork Packet Exchange (IPX), Banyan
Layer-3 general aspects Basic call control Conformance testing Supplementary services
D channel
B channel
Virtual Integrated Network Service (VINES), Xerox

Network Systems (XNS)
In the point-to-point physical connections, the NT (NT1 or NT2) and the TE (TE1 or TA) can be 1 km (3300 ft) apart. The passive bus (no repeaters or any active devices) point-tomultipoint design allows up to eight devices to be connected to a single NT on a bus length that can be up to 200 m (667 ft). The extended bus supports up to eight devices clustered together at the end of the passive bus and can be up to 1 km (3300 ft) apart from the NT. The sections that follow discuss all three ISDN layers in greater detail.
Layer 1: BRI
ISDN standards require the availability of three types of services for end-to-end connections by the local exchange carrier (LEC):
Circuit-switched services on B channels Circuit-switched or packet-switched services on D channels Packet-switched services on B channels
238
To use them, the ITU-T dened BRI and PRI access interfaces, and the operation speed and the number and type of channels. The BRI is also referred to as 2B+D, and typically operates over two 64-kbps B channels and one 16-kbps D channel. It can also be provisioned as 1B+D, and even 0B+D for low speed (9.6 kbps) data. As you can see, the D channel in BRI operates at 16 K, but in its S/T implementation, the speed is 192 Kbps. It looks like we are losing 48 Kbps. Were actually not. The remaining 48 Kbps can be used for out-of-band forward error correction (OOB FEC). The following sections cover the elements of a typical ISDN BRI architecture:

ISDN Devices
Devices Reference points Interfaces BRI initialization
The hardware that is part of an ISDN service includes the following:
TE1A device compatible with an ISDN network and that connects to NT type 1 or 2 devices. TE1 devices include ISDN routers, modems, and ISDN phones. TE2A device not compatible with an ISDN network and that requires a terminal adapter to connect, such as a regular telephones old-time terminal and other nonISDN devices. Terminal adapter (TA)Converts non-ISDN signaling to ISDN signaling. NT1Connects four-wire ISDN subscriber line wiring to the conventional two-wire local loop facility. In North America, it is common to nd an NT1 at a users location inside of a networking device (router or modem). In Europe and Asia, NT1 is not part of the ISDN device at the users location because it belongs to the LEC. NT2Directs trafc from different subscriber devices and from the NT1. The device performs switching and concentrating, and similar to the NT1, it converts wiring within the telephone carrier (four-wire) network to the (two-wire) local loop. The NT2 adds data link layer and network layer functionality to a NT1, and it is usually used with connecting private branch exchange (PBX) devices. CPE can be considered an NT2 device. Local Exchange (LE)Includes Local Termination (LT) and Exchange Termination (ET) on the providers site.
In the CPE site, the local loop is terminated by using an NT1, which is responsible for performance monitoring, timing, physical signaling, protocol conversion, power transfer, and multiplexing of the D and B channels, as shown in Figure 9-2. The NT1 devices in Europe and Asia belong to the LEC. It is an external device for the router.
239
Figure 9-2
ISDN Devices and Access Points
TE1 ISDN Device, Phone, Terminal (TE1) TE2 R Non-ISDN Terminal (TE2)
Local Loop Customer Premises Cisco ISDN Router in U.S. and Canada S U.S. and Canada 2-Wire, Twisted Pair 4-Wire,Twisted Pair NT2 T TA PBX, LAN Terminal Controller S Usually Referred to as S/T Interface Cisco ISDN Router Europe and Asia S/T Interface NT1 4-Wire, Twisted Pair U NT1 LT
Central Office (CO) ET ISDN Cloud
ISDN Switch
LT (LE) V
ET (LE)
R, S, T, U, V: ISDN Reference Points
ISDN Local Loop Reference Points: ISDN Interfaces

ISDN service providers (those providing the last mile or the local loop of the ISDN connection) refer to reference points when troubleshooting parts of the local loop. To connect devices that perform specic functions, the devices need to support specic interfaces, which can vary from CPE to CPE. As a result, the ISDN standards do not dene interfaces in terms of hardware, but refer to them as reference points. However, for troubleshooting purposes, it is more reasonable to refer to interfaces. Every ISDN compatible router provides information about the type of connection or interface; and Cisco 77x, 80x, 25xx, and 40xx series routers are examples. These interfaces are as follows:
R-reference point, or R-interfaceThis is between the non-ISDN device (TA2) and the TA. The TA allows the TE2 to appear to the ISDN network as an ISDN device. S/T reference point or S/T interfaceThis is usually considered together, where the S-reference point is between the TE1 and NT2, or between the TA and the NT2. The T-reference point is the four-wire (one pair for transmit and one for receive) interface between the customer site switching equipment (NT2) and the local loop termination (NT1). If theres no NT2 equipment, which is common, the UNI is usually called the S/T reference point. S/T is typical for Europe and Asia. U-reference point or U-interfaceThis is a two-wire facility that uses frequencydivision multiplexing (FDM) and echo cancellation. It is typical for the U.S. and Canada, and the routers produced for these countries, to have a built-in U-interface. The NT1 device converts the four wire S/T interface to a two-wire U-interface. In Europe and Asia, the NT1 device is in the providers central ofce (CO). V-reference pointThis denes the interface in the LE between the LT and the ET.
240
The real structure of every ISDN design includes numerous implementations. For troubleshooting purposes, it is preferable to simplify the diagram of reference points and interfaces to the illustration (refer to Figure 9-2). In most common cases, consider the simpler structure. For residential and Centrex applications, the NT2 is absent.
NOTE
The book Analyzing Broadband Networks, now in its third edition, provides some excellent examples of ISDN architecture and design.
Both the S/T and U-interfaces achieve full-duplex connections. The current wiring rules follow the ISO 8877 standard. RJ-45 is an 8-pin connector. Table 9-2 shows the wiring rules for the S/T interface and Table 9-3 shows the U-interface wiring rules. The polarity is important only for the S/T interface.
Table 9-2 ISDN RJ-45 Pins for the S/T Interface Pin 1 2 3 4 5 6 7 8 Table 9-3 TE Pin Power source 3(+) Power source 3(-) Transmit (+) Receive (+) Receive (-) Transmit (-) Power sink 2 (-) Power sink 2 (+) NT Pin Power sink 3 (+) Power sink 3 (-) Receive (+) Transmit (+) Transmit (-) Receive (-) Power source 2 (-) Power source 2 (+) Required No No Yes Yes Yes Yes No No
ISDN RJ-45 Pins for the U-Interface Pin 1 2 3 4 5 6 7 8 Function Not used Not used Not used U interface network connection (Tip) U interface network connection (Ring) Not used Not used Not used
241
Chapter 3 covers the S/T interface and U-interface line codes and frame formats in greater detail. Table 9-4 describes the physical characteristics of both interfaces and their differences.
Table 9-4 Standards Dening the Physical Characteristics of the S/T and U-Interfaces Reference Point Dening standard Devices Distance Physical conguration Bit rate User data rate Line code Signaling rate Maximum voltage Timing source Number of wire pairs Full-duplex method Interleaving scheme Number of bits per frame* S or T or S/T Interface CCITT I.430 TE1/TA to NT 1 km Point-to-point or point-to-multipoint 192 kbps 144 kbps Pseudo-ternary 192 Kbaud +- 750 mV NT 2 One pair for each direction B18 D1B28 D1 48 36 12 4000 U-Interface ANSI T1.601 NT1 to LE 5.5 km Point-to-point 160 Kbps 144 Kbps 2B1Q 80 Kbaud +- 2.5 V LE 1 Echo cancellation B18B28 D2 240 216 24 666.666
Number of bitsuser data Number of bitsoverhead Number of frames per second
*Referring to frames in the physical layer is not ISO compliant and could be confusing for network engineers; however, to be consistent with the ISDN standard, the adopted terminology is preferred for this and any other technology.
For more information, see ISDN Concepts, Facilities, and Services, Third Edition (McGraw-Hill, 1996).
Initializing BRI
Activation of the BRI is based on the exchange of INFO messages and on the performance of a straightforward handshake mechanism. I.430 denes 5 INFO (0-4) messages that perform different roles in the activation process.
242
As Figure 9-3 shows, the process starts with the TE sending INFO1 to the LE. The A bit thats set to 1 indicates that the line is activated. The INFO0, which is not shown in this gure, indicates no signal.
Figure 9-3 Initializing the Physical Link
TE
INFO 1 First Power_Up, First Connection, Alignment Lost 192-kbps Signal with +0,-0, and six 1 INFO 2 Sent by Network Will Provide TE with Appropriate Frame Synchronization B, D, A, E Set to 0 INFO 3 Indicated that TE Has Frame Alignment Established Operational B and D Channels INFO 4 The Service Is Activated and Operational I.430 Frame with Operational B and D Echoes D Channel. A Bit Set to 1
ISDN Switch LE
The Layer 2 D Channel: LAPD

As discussed previously, on the second layer of the layered model, ISDN uses a protocol called LAPD. The protocols general principles are dened in the Q.920 (I.440) and the Q.921 (I.441) standards. The following is a discussion of Layer 2 frame formats, logical link establishment, and logical link parameter negotiation, which are related to Layer 2 troubleshooting later in this part.
LAPD Frame Formats (A and B)

Two formats, A and B, are dened in LAPD. Format A differs from B, and it is used where the information eld is not necessary. Because Format A is a subset of Format B (Format B is identical to Format A with the addition of an Information eld), the following explanation will apply to both. Figure 9-4 shows the format of every transmission unit (frame). The rst row represents the number of octets, and the second row the actual elds. Unlike other frame types, the low-order bit of each octet is transmitted rst. In this case, it is the last bit (0) in the Flag eld, the last bit of the rst octet of the Address eld, and so forth.
243
Figure 9-4
LAPD Format B Frame
1 Flag 01111110
2 Address
1(2) Control
2 FCS
1 Flag 01111110
Data
Flag Field
The Flag eld has a standard value of 0x7E(01111110) and indicates the beginning and the end of the frame. The combination 0x7F(01111111) represents the abort signal, and the combination 0xFF (11111111) represents an idle channel. The Flag begins and ends the frame.
Address Field
The Address eld identies the user device and protocol, and it plays a signicant role in the troubleshooting process. It is always two octets. The structure is shown in Figure 9-5. Note that the remaining 13 bits represent the data-link connection identier (DLCI)a combination of the TEI and service access point identier (SAPI) elds. The terminal endpoint identier (TEI) is designed to maintain a separate logical link over the D channel with the peer process in the LE.
Figure 9-5 The Structure of the Address Field. The TEI and SAPI Fields Represent a 13-Bit DLCI
6 SAPI TEI
2 C/R
1 EA0 EA1
The Address eld has the following subelds:
TE is a 7-bit subeld of the Address eld that can be in the range of 0127. Three types of TEs exist: 063 range is allocated for non-automatic TE assignment. 64126 range is randomly and automatically assigned value by the LE. A TE equal to 127 is a broadcast.
244
The maximum number of TEs per BRI is limited to eight by the ITU-T.
Table 9-5
SAPI is a 6-bit subeld. Table 9-5 shows the SAPI values.
The SAPI Values SAPI Value 0 115 16 1731 3261 63 All others Layer-3 Management Entity Call control procedure Reserved for future standardization Packet mode, used by X.25 Reserved for future standardization Frame Relay communications Layer 2 management procedure Not available for Q.921
Table 9-6
C/R is the Command/Response eld bit. It is dened in Table 9-6.
The C/R Filed Values Command/Response Command Direction Network -> User User -> Network Response Network -> User User -> Network C/R Value 1 0 0 1
EA0 and EA1 is the Address eld extension bit.
Control Field
The Control eld of LAPD is used for frame identication. The eld can be one or two octets, and provides messages that perform some of the typical functions for the Transmission Control Protocol (TCP), such as ACK and SEQ#. The Control eld uses three frame formats, which are indicated by the rst two bits of the eld: Information, Supervisory and Unnumbered. Information (I) is a two-octet frame eld that carries signaling or user data information from higher ISDN layers. Supervisory (S) is also a two-octet eld format that controls the exchange of the I-frames. When troubleshooting, it is not easy to recognize the message types. The following descriptions help with the identication.
245
NOTE
Every message is either a command or a response (R), based on its purpose. P/F is a poll/ nal bit, S is S-frame type, and M is U-frame type.
Based on the content of messages in the Control eld of LAPD, three categories of messages exist:
Information transfer messages are command messages, where C and R refer to command and response (R) messages. Information transfer messages consist of the following: N(S) (Send sequence number)This message contains 7 bits with 0 at the end. N(R) (Receive sequence number)This message contains 7 bits and a P bit at the end.
Supervisory messages consist of two bytes where the second byte is N(R), and whose last bit is a P/F bit. These messages can be command or response (R). Supervisory messages consist of the following: RR (Receive Ready)The message can be C or R type. The message means Ready for more frames. RNR (Receive not ready)This message can be C or R type and means Busy for more I-frames. REJ (Reject)The message can be C or R, and can be seen when an Iframe is received and not expected and rejected as a result.
Unnumbered messages. These messages are one byte in length and they can be both C and R types: SABME (Set Asynchronous Balance Mode Extended)This message is only type C and means Establishes the logical link = Xmod(128). DM (Disconnected Mode)This message shows error condition and can be only R type. UI (Unnumbered Information)This message can be only C type and means Transfers Layer 3 management information. DISC (Disconnect)This is only a C type message and means Terminates the logical link. UA (Unnumbered Acknowledgment)This is a response (R) message and indicates The Unnumbered (U) frame eld is establishing and terminating the logical connection.
FRMR (Frame Reject)This is a response (R) type of message, which indicates that Error condition and frame is rejected. XID (Exchange Identication)The message can be C or R type and it links control parameters for negotiation.
246
Data Field
The Data eld contains Q.931 messages, user data, or LAPD management information. The Data eld has a variable, octet-aligned length, and it might not exist in all frames.
FCS Field
The frame check sequence (FCS) eld is two bytes and it is used for bit error detection.
Logical Link Establishment

The next step of achieving full functionality of ISDN service, immediately after the activation of the physical link, is the logical link establishment. Here, LAPD ensures the TEI and SAPI assignments, which are the core of the logical link establishment, as shown in Figure 9-6. The gure represents another handshake link procedure.
Figure 9-6 Logical Link Establishment Sequence
TE
UI (SAPI=63, TE=127) in the Address Field; TEI Request in Data Field
ISDN Switch LE
UI (SAPI=63, TE=127) in the Address Field; TEI=84 in Data Field
SABME (SAPI=0, TEI=84) in the Address Field
UA (SAPI=0, TEI=84) in the Address Field
You can distinguish two main phases in the process:
First phaseAs soon as the physical link is activated, it sends two broadcast messages in the Address eld: SAPI = 63 (broadcast) and TEI=127(broadcast). The ISDN switch responds with randomly and automatically assigned TEI = 84, and repeats the broadcast messages with SAPI = 63 and TEI = 127. Second phaseThe router sends a SABME message, indicating the purpose with SAPI = 0 (third layer data), and conrms the assigned TEI = 84. The ISDN switch then sends a Unnumbered Acknowledgment (UA) frame for SAPI = 0 (call establishment can start) and TEI = 84 to indicate the end of the process.
247
In the most common 2B+D design of a BRI, this procedure executes twice, once for each B channel. Therefore, by the end of the exchange, every B channel has an assigned TEI = xx and SAPI = 0.
Logical Link Parameter Negotiation

The logical link establishment is more complicated than a physical connectivity establishment. One of the reasons is that the router and the ISDN switch need to negotiate some parameters. There is a mechanism to negotiate some timers values and counters values to adjust the service to the line parameters. In LAPD, the parameters negotiation function is accomplished through a system of timers and parameters that are exchanged between parties with a U-type XID frame. One device sends the XID frame with its parameters, and if the other device does not respond with another XID, the rst one considers the negotiation complete by using the default parameters. Some of the system parameters and their default values are listed here:
N200Maximum number of times to retransmit the frame. The default value is 3. N201Maximum length of an Information eld. The default value is 260 octets. N202Maximum number of times to request TEI assignment. The default is 3. KMaximum number of unacknowledged I-frames. The default is 1 for SAPI = 0 and 3 for SAPI 0. T200Reply timer. The default is 1s. T201Minimum time between TEI identity check messages. The default is 1s. T202Minimum time between TEI identity request messages. The default is 2s. T203Maximum time without frame exchange. The default is 10s.
Some of the system timers and their parameters are as follows:
In addition to the perfect scheduling mechanism for the LAPD layer mentioned earlier, another mechanism makes sure that no TE has full control over the D channel. This technique is based on analyzing the SAPI content and creating a priority mechanism based on classes. In this case, the signaling SAPI = 0 messages are class 0, and non-zero SAPIs are class 2. Both normal and low priority classes exist, which are based on the number of consecutive 1s in the frame. Using ISDN in an IP environment is usually related to the PPP and to one of the phases of the PPP protocol, called the Link Control Protocol (LCP), which are discussed in detail in Chapter 5, Dial Technology Background, and Chapter 13, Troubleshooting Scenarios for ISDN BRI. It is important to know that LCP does not replace, but works together, with parameter negotiation mechanisms of ISDN. RFC 1618 was created to ensure this feature.
248
Layer 3 in the D Channel: Q.931 and Message Format

The term Layer 3 protocols comes from the network layer in OSI, and the Q.931 recommendations provide call routing and congestion control for calls between a users TE and the network (between the terminal endpoint and the local ISDN switch). However, this protocol does not impose an end-to-end recommendation, and various ISDN providers and switch types use various implementations of Q.931. Also, some switch types were developed before the standards groups nalized this standard. For these reasons, the proper specication of the switch in Cisco routers is important. The recommended Q.931 message formats represent data blocks, called information elements. SS7 provides telephone switches with the out-of-band signaling capabilities for telephone trunks (switch-to-switch 64-kbps connections). Unlike old in-band signaling standards, out-of-band Signaling System 7 (SS7) provides reduced call setup time, 64-kbps data, caller ID, dialed number information (DNIS), bearer capability, and other progress indicators. The Q.931 protocol typically provides the information shown in Figure 9-7. ISDN Layer 3 messages are carried in the Information eld of LAPD I-frames. Q.931 messages are used in the debugging process with Cisco routers and deserve detailed attention.
Figure 9-7 Message Format of the Q.931 Protocol
Protocol Discriminator 0 Flag 0 0 0 0 Call Reference Length
Call Reference Message Type Information Elements
Protocol Discriminator Field

The rst eld of the Q.931 message format depicted in Figure 9-7 is the Protocol Discriminator eld. It identies the protocol type such as Q.931, X.25, and others. The protocol discriminator has a few values that are used by ISDN:
0x00 through 0x03Assigned in Q.931 for user-user information 0x04Q.931 user-network call control message 0x10 through 0x3FReserved for other Layer 3 protocols
249
Call Reference Field

The second eld is the Call Reference (CR). It identies the relationship between the call and the message, where the number identies the active calls. CR or the Call Reference Value (CRV) is a per-session/per-connection value that is assigned at the beginning of the call, and remains the same until the call is completed. Often the only indicator of whether or not the call goes through is tracing the call and testing with the LEC. Typically, a BRI uses one octet CR length, and a PRI uses two. The high-end bit of the second octet is called a Flag. To prevent the assignment of one CR to two different calls, the Flag is set as follows:
0From call originator 1To call originator (destination)
A special CR is dened with 0 value to indicate a broadcast, which is assigned to all active calls in the user-network interface.
Message Type Field

The Message Type value indicates the type of Layer 3 message that the transmission represents. Call establishment message types in Q.931 are as follows:
SETUPInitial call request SETUP_ACKSetup received, more information required CONNECTCall establishment phase completed CONNECT_ACKAcknowledges CONNECT CALL_PROCShows the call is proceeding ALERTINGRing indication
Figure 9-8 shows the process of connecting a call. The initiator of the call (the router) sends a SETUP message, and usually provides the bearer capability, the calling party number, and the number of the B channel that is starting the call. The bearer capability denes the type of service requested, such as 64-kbps data, 56-kbps data, or 56-kbps voice. The SETUP message also contains the channel identication element, which is designed to be negotiated with the switch, depending on where the call hits the network. After this is completed, both parties know each others per-session numbers. After receiving the SETUP message and checking for correctness, the LE usually requests any missing information with the SETUP_ACK. Then, the router provides this information (see the arrow INFORMATION in the gure). If the information is correct and sufcient, the LE responds with CALL_PROC (call proceeding). So according to Figure 9-8, it should be read as either of the following:
SETUPCALL_PROC SETUPSETUP_ACK INFORMATIONCALL_PROC
250
Figure 9-8
The Call Setup Procedure: The Switch Handles Both Directions

ISDN Switch LE
TE
Recipient
SETUP
SETUP
_ACK
SETUP
INFOR MATIO N
PROC CALL_
C _PRO CALL
ALERT
ALERT
CONN ECT
CONNE CT
K T_AC NEC CON
ACK ECT_ CONN
The LE generates a different SETUP message and sends it to the Recipient, which can be thought of as a PRI connecting to the core router. If the Recipient cannot accept the call, it sends an ALERT to the LE, which in turn generates another ALERT message from the LE to the CPE. When the Recipient accepts the call, it sends a CONNECT to the LE and the LE responds with a CONNECT_ACK. In turn, the LE generates a CONNECT message, which informs the router that the call is accepted and the router responds with a CONNECT_ACK. The call clearing messages are as follows:
DISCONNECTHangs up the call RELEASEReleases the call
251
RELEASE_COMPAcknowledges completion of the RELEASE RESTARTRestarts Layer 3 protocol RESTART_ACKAcknowledges RESTART
The call clearing can be started by any party by sending a DISCONNECT message. Figure 9-9 shows the call clearing procedure, where the DISCONNECT is initiated by the router. After the router sends the DISCONNECT, it disconnects itself from the B channel. The LE returns a RELEASE and in turn, sends a DISCONNECT message to the Recipient. While the Initiator completes the process by sending RELEASE_COMP, the LE releases the B channel. On the other side, after the LE and the Recipient exchange RELEASE and RELEASE_COMP messages, the facility is released for new calls.
Figure 9-9 The Call Clearing (Tear Down) Process
ISDN Switch LE
TE
Recipient
DISCO
NNECT SE
DISCO
NNECT SE
RELEA
RELEA
RELEASE_COMP
RELEASE_COMP
Information Elements Field

As previously mentioned, the data is carried in the Information Elements (IE), which are the Q.931 parameters. Unlike other protocols, Q.931 does not dene a xed length for this eld that reects the actual length of the eld. Different content and different length works with different LECs. For this reason, this eld might contain a length indicator, dened as Type 1 and Type 2 IE. The Type 1 IE denes a 3-bit identier and 4 bits for the content of IE, and Type 2 contains a 7-bit IE identier. The most common IEs are listed here and more are described in Q.922:
0x04Bearer capability 0x2CKeypad facility (used to send on 5ESS and NI switches) 0x6CCalling party number
252
0x70Called party number 0x3AService prole identier (SPID)
Layer 3 Summary
The Layer 3 procedures are designed to provide the full functionality of handling the calls, including establishing, connects and disconnects, releasing the facilities for the next calls, and so forth. As discussed earlier, all these functions are performed between two or more parties, but the main role always belongs to the ISDN switch, which naturally leads to the topic of the next section.
ISDN Switch Types

There are many standards for switches because most standards were released during or after the deployment of most ISDN switches. Therefore, a variety of ISDN switch manufacturers pose different requirements for conguring CPE. In Table 9-7, the Cisco supported switches from the latest IOS release are listed.
Table 9-7 ISDN Switch Types Switch Type basic-1tr6 basic-5ess basic-dms100 basic-net3 basic-ni1 basic-qsig basic-ts013 ntt vn3 Description 1TR6 switch type for Germany Lucent 5ESS switch type for the U.S. Northern Telecom DMS-100 switch type for the U.S. NET3 switch type for UK, Europe, Asia, and Australia National ISDN switch type for the U.S. QSIG switch type TS013 switch type for Australia (obsolete) NTT switch type for Japan VN3 and VN4 switch types for France
In the U.S. and Canada, two settings have high importance when you are trying to set up the switch-BRI interoperations: SPID, and Local Directory Numbers (LDNs). The SPID represents a subscriber number and subscriber address. Although the number is dened as a regular phone number with format xxx-xxx-xxxx, the addresss purpose is to assign a unique number to the endpoint (such as a terminal). The service provider assigns the SPIDs and they must be congured on the router in exactly the same way as the LEC provides them. Depending on the switch type connected to the CPE, SPIDs might not be necessary.
Review Questions
253
In the U.S., National ISDN-1 and DMS-100 ISDN switches require SPIDs to be congured, but the AT&T 5ess switch does not. If they are required, the SPID number is usually a ten-digit telephone number plus two or four extra digits, for example, SPID = 40847647400100 and 40847647410200 represent the following:
408Area code 476CO (exchange) code 4740 and 4741Station IDs for each B channel 01 and 02Terminal identiers
Another part of the setting is the LDN. The LDN is congured to receive incoming calls. For example, LDN1 = 4764740 and LDN2 = 4764741, represent the following: 476Exchange code 4740 and 4741Station ID
With AT&T switch-type 5ESS, only one LDN is necessary to identify the service. For more information about switch settings, see Chapter 10, ISDN Design Solutions.
Summary
The importance of this chapter is based on the fact that in ISDN some technical solutions were implemented during or even before some standards were available. Thats why for the troubleshooting engineer the information about standards, switches, settings, and providerspecics is helpful. At the same time, the detailed description of ISDN architecture, reference points, devices, and interfaces in this chapter provides the necessary minimum to ensure that you are familiar with the technology basics of one of the most complicated technologies in todays market.
Review Questions
1 What is the scope of the I.431 and I.432 standards? 2 Where does the name D channel come from? What are the operational speeds of the
D channel for BRI and PRI?

3 What is a V-reference point in ISDN? 4 What are the important pins in a S/T interface? 5 What is the modulation of the ISDN U-interface?
254
6 What is the bit rate of the S/T interface and U-interface? 7 How many INFO messages participate in the BRIs Layer 1 initialization? What does
INFO0 mean?
8 Which bit in the ISDN frame indicates line activation? 9 What makes up DLCI in ISDN? What is the length of DLCI, TE, and SAPI? 10 What are the two indicators that Layer 2 is active? 11 What does TE = 127 mean? 12 What is the dynamic range of TEI? 13 What does SAPI = 0 indicate? 14 How do you distinguish an incoming from an outgoing call? 15 Which ISDN protocol provides information about Bearer capability. Name three basic
types of Bearer capabilities.
CHAPTER
10
ISDN Design Solutions

Typically, the hub and spoke design is the most commonly used in remote access solutions. The hub and spoke terminology can be used for ISDN design solutions; however, it is more common for designers to use network access server (NAS) and remote node as typical terms that describe the design. Typically, the hub site is referred to as the core or core router, and the spoke side is referred to as the end-user router, or remote user. The objectives of this chapter are to give you more information about the typical ISDN design solutions. The main topics of the chapter can be summarized as follows:
Enterprise and Internet service provider (ISP) design Setting the ISDN switch type, service prole identiers (SPIDs) and local directory numbers (LDNs) Network address translation (NAT) and Port Address Translation (PAT) Per-user (per function) design, virtual templates, and proles Multilink Point-to-Point Protocol (MLP) Multichassis Multilink PPP (MMP)
Hub and spoke design, typical for remote access ISDN (see Figure 10-1), is benecial because of increased manageability and the capability to apply policies to the environment. In this design, the core router is usually connected to two switches that provide the necessary redundancy for remote users who are accessing the companys intranet. At the same time, the core router can be a single point of failure, which raises questions about availability and scalability, and bandwidth aggregation.
258
Chapter 10: ISDN Design Solutions
Figure 10-1 Hub and Spoke Design for a Remote Access Environment
LAN Switches NAS Cisco NAS Routers 5x00, 36x0, 720x
ISDN Switch CO
Long Distance Provider
(ISDN Cloud)
Local Loop
CO Local Loop Cisco 77x Cisco 804 CO
Local Loop Laptop Computer
Local Loop
CO
Cisco 1604 Cisco 77x IP Phone
Laptop Computer Desktop Computer
Laptop Computer
Laptop Computer Desktop Computer Laser Printer
Enterprise and ISP Designs

From an application point of view, you can break down ISDN into the following main categories. Based on the structure of the core side, you can recognize a separate enterprise design and an ISP design in these categories:
ISPs, more often than enterprises, use the MMP, which is not mandatory for an enterprise solution.
259
ISPs often use a pool of IP addresses, whereas enterprises often assign an IP subnet from their routable or private address space for remote users based on their needs. ISPs use NAT/PAT techniques or assign a subnet for an extra charge, and an enterprise, using NAT/PAT, assigns a /32, /30, /29, or even a /28 subnet to the remote user. NAT/PAT is more common on the end user side, performing the NAT/PAT on their customer premises equipment (CPE). ISPs rarely perform NAT/PAT for the remote user on their own routers. ISPs use one-way authentication so that they can troubleshoot the CPE remotely without conguring the Challenge Handshake Authentication Protocol (CHAP) host name of the core router on the remote users router. Enterprises use two-way authentication, or more sophisticated authentication schemes. ISPs do not make outgoing calls, and enterprises do allow outgoing calls. ISPs can apply a at rate fee for the service; however, enterprises usually pay usagebased charges with volume discounts and usually the charges are charged by the ISP to the enterprise.
Often, combinations of these categories exist in a design. You might want to review some of the basic design techniques, but before that, review the basic ISDN conguration of the ISDN switch type, SPID(s), and LDN(s). They might seem easy to congure, but the reality is that they can cause serious issues, especially when the service is a new-install. Each of these is discussed in the following sections.
Setting the ISDN Switch Type

The switch types supported in the latest versions of IOS (12.1.x. and later) are outlined in Example 10-1. The most commonly used types in the U.S. and Canada are basic-5ess, basic-dms100, and basic-ni1.
Example 10-1
Determining the ISDN Switch Type

804-isdn(config)#isdn basic-1tr6 basic-5ess basic-dms100 basic-net3 basic-ni basic-qsig basic-ts013 ntt vn3 switch-type ? 1TR6 switch type for Germany Lucent 5ESS switch type for the US Northern Telecom DMS-100 switch type for the US NET3 switch type for the UK, Europe, Asia and Australia National ISDN switch type for the US QSIG switch type TS013 switch type for Australia (obsolete) NTT switch type for Japan VN3 and VN4 switch types for France
Besides the listed switches, there is a category of custom design switches for the U.S. and Canada:
260
custom-5ess custom-dms100
Lucent 5ESS switch type for the US Northern Telecom DMS-100 switch type for the US
The custom design switches are point-to-point designs and usually do not require SPID and LDN information. It is common to dene only a phone number. The command and options for setting the switch types for 776 routers are as follows:
SEt SWitch 5Ess
DMS
NI-1
PERM64
PERM128
PERM2X64
If you dont specify any switch type, the routers default is 5Ess. In 77x routers the switch type 5Ess applies to all types of 5Ess switches. It is convenient when custom switch types need to be congured because all you need to know is that the switch is 5Ess. This setting is part of the general conguration of the router, which is called the system level in 77x terminology. For Cisco IOS Software scenarios, the conguration command for switch type National ISDN-1 (NI-1 or N11) is as follows:
804-isdn(config)#isdn switch-type basic-ni
You can congure more than one switch type in one router conguration by using Cisco IOS Software Release 12.0 and later. An example of a BRI0 interface conguration is as follows:
804-isdn(config-if)#isdn switch-type basic-5ess
The global conguration mode and the interface conguration mode settings work together and follow the logic that if an interface (BRI0, BRI1, BRI2, and so on) is congured for different switch types, it takes precedence over the settings in the global conguration mode. If not, the BRIx interface takes the switch type from the global conguration mode as a default one. Additionally, the switch type can be different from the prole that the LEC is using or emulating on the switch. You can have DMS100 running NI1 or any other combination. It is common to see the DMS and 5ess switches running in NI mode in North America. When using Cisco 77x routers, it is preferable to congure the router, based on the providers prole name, coded as NI or 5E, and if it does not work, congure the switch type. In the case of Cisco IOS Software, either set both global and interface congurations to the type of the local exchange carriers (LECs) prole (NI1), or set the switch type (DMS100) in the global conguration, and set the LECs prole type (NI1) under the Basic Rate Interface (BRI).
Setting SPIDs and LDNs

When an LEC installs the local loop (installing the ISDN service), there is always minimum information available to the user, including SPIDs, LDNs, and the switch type. The NI-1 and the DMS100 both require SPIDs. Basic-5ESS is a point-to-multipoint switch, which is capable of providing up to eight SPIDs per service. As previously mentioned, custom-5ESS
261
is point-to-point and does not require SPIDs, and by default, they do not provide a voice capability. When working with LECs, the network professional might see different settings for voice and data, such as the following:
A service might not be provided (voice or data). Calls might be restricted by rejecting the third call, if two channels are up and running. All incoming calls might be forwarded to let the router decide how to handle the priority of the call (voice and data).
The variety of settings and the use of different names by providers (for example, GTE has a setting called Umbrella or U setting) is a real challenge for network engineers, and requires maximum attention to the details of the conguration. The LDN is not a mandatory part of the conguration, unless the service is provisioned for both voice and data. Example 10-2, Example 10-3, and Example 10-4 provide examples of valid ISDN settings for 77x router images that use Software Version c760-in.r.US 4.4(2). Example 10-5 uses a Cisco IOS Software router, which is provisioned for voice and data.
Example 10-2
A Valid SPID Setting Example for 77x Router for Switch Type NI1
776-isdn>set 776-isdn>set 776-isdn>set 776-isdn>set 776-isdn>set 776-isdn>set 776-isdn>set switch ni1 1 spid 40857647400101 1 directorynumber 5764740 phone1 = 5764740 2 spid 40857647410101 2 directorynumber 5764741 phone2 = 5764741
Example 10-3
A Valid SPID Setting Example for 77x Router for Point-to-Point Switch Type 5ESS
776-isdn>set switch 5ess 776-isdn>set 1 directorynumber 4920672 776-isdn>set phone1 4920672
Example 10-4
A Valid SPID Setting Example for Point-to-Multipoint Switch Type 5Ess

776-isdn>set 776-isdn>set 776-isdn>set 776-isdn>set 776-isdn>set 776-isdn>set 776-isdn>set 776-isdn>set switch 5ess ppp multilink on 1 spid 0173125470 2 spid 0173125480 1 directorynumber 7312547 2 directorynumber 7312548 phone1 7312547 phone2 7312548
In the case of Cisco IOS Software Release 12.0 and later, under the BRIx interface, you usually see the conguration in Example 10-5.
262
Example 10-5
Cisco IOS SPID Settings for Interface BRI0

804-isdn(config-if)#isdn switch-type basic-ni 804-isdn(config-if)#isdn spid1 53075358360101 7535836 804-isdn(config-if)#isdn spid2 53075358600101 7535860
A relatively new feature of IOS (available in IOS 12.1(6), for example) sets the switch type, and not the SPIDs. A command available under the BRI0 interface is isdn autodetect, which enables the router to request the SPID assignment from the switch. The router reports no LDN, spid1 NOT sent, spid1 NOT valid, but the indicator state equals 8, which is a valid state (see Table 13-1). The router responds with MULTIPLE_FRAME_ESTABLISHED for both terminal endpoint identiers (TEIs), and the conguration is fully operational. The users router needs to be congured to meet the requirements of the core router. The end user requires the following minimum information to congure routers:
Host name. Password. Password Authentication Protocol (PAP) or CHAP host name password (depends on enterprises choice for authentication method). SPIDs, LDNs (optional), and switch type. DNS server IP address of the ISP and the domain name (optional). These settings are not relevant to ISDN connectivity, but to DHCP server settings in the conguration. NAT/PAT conguration or the subnet of addresses (optional). Another option here can be if the IP address is dynamically obtained (negotiated).
As mentioned, the IP address of the CPE can be statically or dynamically assigned, can be part of the enterprises IP range, or can be a NAT/PAT address. Some of the common techniques here are designing a pool of IP addresses, or performing PAT or NAT translation to assign an IP address to the remote user.
IP Pool Design
The purpose of the IP pool is to create and assign a group of addresses, so that when the remote user calls, after the user is authenticated, an IP address is provided from a predened set of IP addresses. The IP pool assignment in the core router is relatively simple to congure, as shown in Example 10-6.
Example 10-6
Conguration Setting for an IP Pool

<output omitted> interface Dialer1 description HOME_ISDN_USERS ip unnumbered Loopback0 encapsulation ppp no ip mroute-cache no keepalive
ch10.fm Page 263 Friday, October 11, 2002 12:38 PM
IP Pool Design
263
Example 10-6
Conguration Setting for an IP Pool (Continued)

dialer in-band dialer idle-timeout 3600 dialer-group 8 peer default ip address pool HOME_ISDN_USERS fair-queue ppp authentication chap callin ppp multilink ! ip local pool HOME_ISDN_USERS 20.18.15.1 20.18.15.62 <output omitted>
Under the dialer 1 interface, the denition for the IP address pool is specied. The denition is related to the last statement in the example, which denes the IP pool from 20.18.15.1 to 20.18.15.62 with 62 addresses, or a /26 subnet. The bold statements must match, and it is important not to oversubscribe. Because ISDN is still a dial-in service, expect both peak and non-used hours. It is common practice to use a 10:1 ratio of users to channels. In some cases when it makes business sense, it is better to use a lower ratio to increase the availability of the circuits.
NOTE
In the Cisco ISDN environment for home users, a ratio of 5:1 up to 7:1 works well and does not cause any disconnects or busy signals during peak hours.
To check the status of the pool, use the show ip local pool command, as shown in Example 10-7.
Example 10-7
Checking IP Pool Status

4500-isdn#show ip local pool Pool Begin HOME_ISDN_USERS 20.18.15.1 4500-isdn# End 20.18.15.62 Free 59 In use 3
To check on who the three users are who are currently connected, use the show users all command, as shown in Example 10-8.
Example 10-8
Determining the Users of the IP Pool

4500-isdn#show users all <output omitted> Interface User Vi13 804-isdn-56
Mode Virtual PPP (Bundle)
Idle 00:00:45
Peer Address 10.70.219.20
continues
264
Example 10-8
Determining the Users of the IP Pool (Continued)

Vi17 804-isdn-1 Vi19 776-isdn-3 <output omitted> Virtual PPP (Bundle) Virtual PPP (Bundle) 00:00:00 00:02:44 10.99.251.217 10.121.5.185
The command shows information about all users, including the information about incative ports. Another option here is to show detailed information about every multilink bundle with the show ppp multilink command, as shown in Example 10-9.
Example 10-9
Collecting Multilink Bundle Information

4500-isdn#show ppp multilink <output omitted> Virtual-Access17, bundle name is 804-isdn-1 Bundle up for 00:01:46 Dialer interface is Dialer1 0 lost fragments, 0 reordered, 0 unassigned 0 discarded, 0 lost received, 1/255 load 0x0 received sequence, 0x0 sent sequence Member links: 1 (max not set, min not set) Serial0:21, since 00:01:46 Virtual-Access19, bundle name is 776-isdn-3 Bundle up for 12:58:58 Dialer interface is Dialer1 0 lost fragments, 16 reordered, 0 unassigned 0 discarded, 0 lost received, 1/255 load 0x1AA3 received sequence, 0x5392 sent sequence Member links: 2 (max not set, min not set) Serial0:7, since 12:58:58 Serial0:22, since 00:00:31 Virtual-Access13, bundle name is 804-isdn-56 Bundle up for 1d11h Dialer interface is Dialer1 0 lost fragments, 864 reordered, 0 unassigned 0 discarded, 0 lost received, 1/255 load 0x300C received sequence, 0x6463 sent sequence Member links: 1 (max not set, min not set) Serial0:12, since 1d11h <output omitted>
To check which addresses are taken from the pool, use the show ip route command, as shown in Example 10-10.
NAT and PAT
265
Example 10-10 Determining Addresses Taken from an IP Pool

4500-isdn#show ip route <output omitted> C 20.18.15.3/32 is directly connected, Dialer1 ! This IP is taken D 10.18.15.0/26 is a summary, 00:09:45, Null0 C 20.18.15.51/32 is directly connected, Dialer1 ! This IP is taken C 20.18.15.37/32 is directly connected, Dialer1 ! This IP is taken C 20.18.254.131/32 is directly connected, Loopback0 D 20.85.130.72/32 [90/409600] via 161.68.99.1, 00:09:45, Ethernet0 S* 0.0.0.0/0 [1/0] via 161.68.99.1 4500-isdn#
A better option here is to use the show ip local pool name command, as shown in Example 10-11.
Example 10-11 Determining Addresses Within an IP Pool
4500-isdn#show ip local pool HOME_ISDN_USERS Pool Begin End HOME_ISDN_USERS 20.18.15.1 20.18.15.62 Available addresses: 20.18.15.3 Vi13 20.18.15.51 Vi19 20.18.15.37 Vi17 <output omitted> Free 59 In use 3 Cache Size 20
804-isdn-56 776-isdn-3 804-isdn-1
This command displays the available addresses in the pool. Also, the command shows the IP addresses that are currently in use and the virtual interface that is assigned to the user of that IP address.
NAT and PAT

NAT and PAT are design solutions that create private address space, in the sense that these addresses only exist inside the private network and not in the public address space. These techniques allow designers of future network implementations to achieve some important goals, including the following:
Conserve IP address space Provide scalability Provide a rewall technique Reduce time and cost by simplifying IP address management
In its simplest conguration, NAT operates on a router that connects two networks together. One of these networks (designated as inside or private) is addressed with either private or
266
obsolete addresses that must be converted into public addresses before packets are forwarded onto the other network (designated as outside or public). The translation operates in conjunction with routing, so that NAT can simply be enabled on a customer-side Internet access router when translation is desired.) PAT is a conguration with a subset of features from the NAT technique, and it is available in later versions of Cisco IOS Software Release 11.2. Both PAT and NAT are discussed in more detail in the sections that follow.
PAT
Several internal addresses can be NATed to only one or a few external addresses by using a feature called overload, which is also referred to as PAT. PAT is a subset of NAT functionality, where it maps several internal addresses (up to about 4000) to a single external address. PAT statically uses unique port numbers on a single outside IP address to distinguish between the various translations. The total number of these ports is theoretically 216, or 65,536. PAT-only enabled Cisco IOS Software images do not support full NAT functionality that is required where one-to-one static or dynamic translations are required. Example 10-12 shows a simple PAT conguration for a 77x router, where a private address space type /28 has to be assigned and ports from 60006005 have to be mapped to one IP address (in this case, 10.0.0.2).
Example 10-12 Simple PAT Conguration
under user Internal, type set ip netmask 255.255.255.240 set ip address 10.0.0.1 ! If the core routers chap hostname is gateway, then the user will need ! to be name gateway as well. set user gateway set ip pat on
Assign the ports and private IP addresses as in Example 10-13.

Example 10-13 Assigning Ports/Private IP Addresses
set set set set set set set set set dhcp address 10.0.0.2 13 dhcp netmask 255.255.255.240 dhcp gateway primary 10.0.0.1 ip pat porthandler 6000 10.0.0.2 ip pat porthandler 6001 10.0.0.2 ip pat porthandler 6002 10.0.0.2 ip pat porthandler 6003 10.0.0.2 ip pat porthandler 6004 10.0.0.2 ip pat porthandler 6005 10.0.0.2
NAT and PAT
267
NOTE
In Example 10-13, ports 60006005 are assigned to PAT transformation statically.
Use the show ip pat command to check or troubleshoot the PAT functions on a 77x router, as shown in Example 10-14.
Example 10-14 Determining PAT Functions for Troubleshooting Purposes
776-isdn> show ip pat Dropped - icmp 0, udp 15, tcp 0, map 0, frag 0 Timeout - udp 5 minutes, tcp 30 minutes Port handlers [no default]: Port Handler Service ------------------------------------21 10.0.0.2 FTP 6000 10.0.0.2 6001 10.0.0.2 6002 10.0.0.2 6003 10.0.0.2 6004 10.0.0.2 6005 10.0.0.2 23 Router TELNET 67 Router DHCP Server 68 Router DHCP Client 69 Router TFTP 161 Router SNMP 162 Router SNMP-TRAP 520 Router RIP Translation Table - 16 Entries. Inside Outside Orig. Port/ID Trans. Port/ID Timeout ------------------------------------------------------------------------10.0.0.2 161.68.235.228 0x89c3 0xfff9 1 10.0.0.2 161.69.2.87 0x89cb 0xfff2 2 10.0.0.2 161.68.235.228 0x89cb 0xfff5 2 10.0.0.2 161.69.2.87 0x89cd 0xffee 3 10.0.0.2 161.68.235.228 0x89cd 0xffef 2 10.0.0.2 161.68.222.255 0x9b1 0x9b1 4
NAT
NAT was initially described in RFC 1631. In its simplest conguration, it operates on a router that connects two networks together, where one of these networks is designated as inside or private, and the other is outside or public. As part of a global address plan, each of these networks can use either unique addresses, private addresses (RFC 1918), or addresses that have been ofcially assigned to some other organization as their private addresses. One of these networks is addressed with addresses that must be translated before
268
packets are forwarded onto the other network. If required, NAT can also perform bidirectionally, translating both the source and destination addresses. Full NAT functionality is required where one-to-one static and dynamic translations are required. Both static and dynamic address translations are supported by Cisco IOS Software NAT, alone or in conjunction with one another. Static address translations require an administrator to explicitly map an external address to an internal address. Dynamic translations use an allocated IP pool, and each new IP address to be translated is dynamically mapped to another IP address from the pool in a round-robin fashion. Static translations generally allow access to a particular device through the NAT. For example, if a network has an internal Domain Name System (DNS) server that needs to communicate with an external DNS server, one congures a static translation to enable connectivity. The NAT then allows trafc to be passed between these statically known, but translated addresses. Addresses in static translations must explicitly be omitted from the dynamic translation pool. An IP packet that traverses a NAT can have both its source and destination addresses translated by the NAT. RFC 1918 denes the address space to be allocated for private Internets. The documents state: The Internet Assigned Numbers Authority (IANA) has reserved the following three blocks of the IP address space for private internets:
10.0.0.0 - 10.255.255.255 (10/8 prefix) 172.16.0.0 - 172.31.255.255 (172.16/12 prefix) 192.168.0.0 - 192.168.255.255 (192.168/16 prefix)
NOTE
The IANA is now called the American Registry for Internet Numbers (ARIN).
The rst block is referred to as the 24-bit block, the second as the 20-bit block, and the third as the 16-bit block. The rst block is nothing but a single class A network number, the second block is a set of 16 contiguous class B network numbers, and the third block is a set of 256 contiguous Class C network numbers. The full document can be found in the available literature or at www.faqs.org/rfcs/rfc1918.html. Under the Ethernet0 interface, a sample cong of Cisco IOS Software NAT requires the conguration in Example 10-15.
Example 10-15 Cisco IOS Software NAT Conguration
! interface Ethernet0 <output omitted> ip nat inside no shutdown
Under the Dialer 1 interface:
NAT and PAT
269
Example 10-15 Cisco IOS Software NAT Conguration (Continued)

<output omitted> ip nat outside <output omitted>
Example 10-16 shows the conguration in global conguration mode.

Example 10-16 Cisco IOS Software NAT Conguration: Global Conguration Mode
ip nat inside source list 111 interface Dialer1 overload access-list 10 permit ip any any access-list 111 deny udp any eq netbios-dgm any access-list 111 deny udp any eq netbios-ns any access-list 111 deny udp any eq netbios-ss any access-list 111 deny tcp any eq 137 any access-list 111 deny tcp any eq 138 any access-list 111 deny tcp any eq 139 any access-list 111 permit ip any any time-range TIME dialer-list 1 protocol ip permit <output omitted>
TIP
Before starting the troubleshooting process, use the command clear ip nat translations, which is helpful in the NAT debug process.
To troubleshoot the solution, you can use the debug in Example 10-17.
Example 10-17 Debug for NAT
804-isdn#debug ip nat *Mar 1 00:03:43.065: *Mar 1 00:03:44.565: *Mar 1 00:03:49.065: *Mar 1 00:03:50.565: NAT: NAT: NAT: NAT: o: o: i: i: icmp (10.0.0.1, 5574) -> (10.0.0.2, 5574) [0] icmp (10.0.0.1, 5575) -> (10.0.0.2, 5575) [1] udp (10.0.0.2, 137) -> (161.68.235.228, 137) [18082] udp (10.0.0.2, 137) -> (161.68.235.228, 137) [18083]
The rst two lines show that the default gateway 10.0.0.1 is exchanging Internet Control Message Protocol (ICMP) packets with the newly assigned 10.0.0.2. The second two lines show 10.0.0.2 using port 18082, and exchanging udp port 137 packets with an IP address. To check the arp-cache transactions, use the debug in Example 10-18. As soon as the ip nat debug is turned on, you can see the standard data exchange and NAT in action.
270
Example 10-18 Example of Debugging NAT

804-isdn#show ip nat translations 804-isdn#debug arp804-isdn #debug ip nat IP NAT debugging is on ARP packet debugging is on 804-isdn# *Oct 105 01:15:19.198: IP ARP: rcvd req src 10.0.0.2 0050.dabb.c887, dst 10.0.0.2 Ethernet0 ! IP ARP request from an IP source with MAC address 0050.dabb.c887. *Oct 105 01:15:20.166: IP ARP: rcvd req src 10.0.0.2 0050.dabb.c887, dst 10.0.0.2 Ethernet0 ! Again the same request *Oct 105 01:15:21.166: IP ARP: rcvd req src 10.0.0.2 0050.dabb.c887, dst 10.0.0.2 Ethernet0 ! and again *Oct 105 01:15:23.178: IP ARP: creating entry for IP address: 10.0.0.2, hw: 0050.dabb.c887 ! The entry in the ARP-cache is created to map IP 10.0.0.2 to MAC 0050.dabb.c887. *Oct 105 01:15:23.182: IP ARP: sent rep src 10.0.0.1 00b0.64ba.2c81, dst 10.0.0.2 0050.dabb.c887 Ethernet0 A confirmation (replicate) is sent to confirm the assignment. 804-isdn#show arp Protocol Address Age (min) Hardware Addr Type Interface Internet 10.0.0.2 1 0050.dabb.c887 ARPA Ethernet0 Internet 10.0.0.1 00b0.64ba.2c81 ARPA Ethernet0
See Example 10-19 to see negotiations of the IP and related ports.

Example 10-19 Negotiations of the IP and Related Ports in Cisco IOS Software
Oct 105 04:30:31.837: NAT: i: tcp (10.0.0.2, 4734) -> (141.68.235.244, 139) [17225] *Oct 105 04:30:31.885: NAT: o: tcp (141.68.235.244, 139) -> (141.70.209.81, 4734) [45847] ! Outside source is sending TCP 139 data to the public address of the user 141.70.209.81. *Oct 105 04:30:32.029: NAT: i: tcp (10.0.0.2, 4734) -> (141.68.235.244, 139) [17226] *Oct 105 04:30:42.873: NAT: o: udp (192.168.165.15, 496) -> (230.0.1.39, 496) [38427] *Oct 105 04:30:42.889: NAT: o: udp (192.168.165.15, 496) -> (230.0.1.39, 496) [38426] *Oct 105 04:30:57.593: NAT: o: udp (141.69.10.13, 496) -> (230.0.1.40, 496) [19018] *Oct 105 04:30:57.609: NAT: o: udp (141.69.10.13, 496) -> (230.0.1.40, 496) [19016] *Oct 105 04:30:58.097: NAT: o: tcp (141.68.235.244, 139) -> (141.70.209.81, 4734) [53804] *Oct 105 04:30:58.265: NAT: i: tcp (10.0.0.2, 4734) -> (141.68.235.244, 139) [17227] *Oct 105 04:31:04.645: NAT: i: tcp (10.0.0.2, 4734) -> (141.68.235.244, 139)
NAT and PAT
271
Example 10-19 Negotiations of the IP and Related Ports in Cisco IOS Software (Continued)
[17228] *Oct 105 04:31:04.693: NAT: o: tcp (141.68.235.244, 139) -> (141.70.209.81, 4734) [24625] *Oct 105 04:31:04.877: NAT: i: tcp (10.0.0.2, 4734) -> (141.68.235.244, 139) [17229] *Oct 105 04:31:12.017: NAT: i: udp (10.0.0.2, 4796) -> (141.68.10.70, 53) [17230] *Oct 105 04:31:12.017: NAT: ipnat_allocate_port: wanted 4796 got 4796 *Oct 105 04:31:12.021: NAT: i: udp (10.0.0.2, 137) -> (141.68.235.228, 137) [17231] *Oct 105 04:31:12.073: NAT: o: udp (141.68.10.70, 53) -> (141.70.209.81, 4796) [44539] ! The DNS server is sending DNS confirm UDP 53 to the public IP of the ! user 141.70.209.81 *Oct 105 04:31:12.077: NAT: i: icmp (10.0.0.2, 512) -> (141.68.222.155, 512) [17232] *Oct 105 04:31:12.081: NAT: ipnat_allocate_port: wanted 512 got 512 ! Port 512 allocation example. *Oct 105 04:31:12.117: NAT: o: icmp (141.68.222.155, 512) -> (141.70.209.81, 512) [5514] *Oct 105 04:31:12.121: NAT: i: tcp (10.0.0.2, 4795) -> (141.68.222.155, 445) [17233] *Oct 105 04:31:12.121: NAT: ipnat_allocate_port: wanted 4795 got 4795 ! Port 4795 allocation example. *Oct 105 04:31:12.157: NAT: o: tcp (141.68.222.155, 445) -> (141.70.209.81, 4795) [5534] *Oct 105 04:31:12.585: NAT: i: tcp (10.0.0.2, 4795) -> (141.68.222.155, 445) [17234] *Oct 105 04:31:12.621: NAT: o: tcp (141.68.222.155, 445) -> (141.70.209.81, 4795) [5722] *Oct 105 04:31:13.089: NAT: i: tcp (10.0.0.2, 4795) -> (141.68.222.155, 445) [17235] *Oct 105 04:31:13.121: NAT: o: tcp (141.68.222.155, 445) -> (141.70.209.81, 4795) [5816] *Oct 105 04:31:13.517: NAT: i: udp (10.0.0.2, 137) -> (141.68.235.228, 137) [17236]
In this example, the information in the rst line reads this way: Inside IP 10.0.0.2, using TCP port 4734, is requesting TCP port 139 service from 141.68.235.244, and the I-O transformation uses port 17225. The number of simultaneous NAT translations supported on a given platform is bounded by the amount of available dynamic random-access memory (DRAM) in the router. Each NAT translation consumes about 160 bytes of memory. When using the overload function, each time a different stream (identied by an IP address, protocol, and Transmission Control Protocol (TCP) or User Datagram Protocol (UDP) port number) passes through the NAT router, a new entry is created in the table. If traditional address translation is used, each IP address matches to only one IP address and creates a single table entry. Not all trafc is supported by NAT/PAT, which can create an issue for some protocols.
272
Some of the protocols supported by Cisco IOS Software NAT include HTTP, TFTP, Telnet, Archie, Finger, Network Time Protocol (NTP), Network File System (NFS), rlogin, remote shell (rsh), remote copy (rcp), and any TCP/UDP trafc that does not carry source or destination IP addresses in the application data stream. Unsupported trafc includes routing table updates, DNS zone transfers, Bootp, talk, ntalk, Simple Network Management Protocol (SNMP), and NetShow. See Cisco.com for the full description of protocols.
Per-User (Per Function) Conguration

The per-user conguration is one of the most advanced Cisco IOS Software features that is related to the scaling techniques. This concept is based on virtuality, where physical and virtual interfaces are related to each other, but the virtual ones do not have permanent physical interfaces associated with them. A virtual conguration uses physical interfaces, but it is exible, dynamic, and per-function oriented. This Cisco design technique improves scalability and management, and increases router operation efciency. These techniques are transparent to the design differences and can be used in any environment. From a remote access perspective, two virtual conguration techniques exist, where the rst one is a subset of the second one:

NOTE
Virtual interface template service Virtual proles
The per-user conguration information can supplement or override the generic conguration on a virtual interface.
The sections that follow discuss the two virtual conguration techniques in greater detail.
Virtual Interface Templates

Virtual interface templates are used when the generic interface conguration and routerspecic conguration information are combined. These templates provide a certain functionality. For example, when the router receives calls from a remote user, the template applies the predened settings, such as type of authentication, speed, and IP address from a local pool, to the user. This creates a per-user, per-session (call) conguration. With the remote user call-in, the same template applies with a different IP and when the rst user disconnects the call, the template is released and applied to another user request. The advantages for the ISP design are obvious:
Scalability, because interface congurations can be separated from physical interfaces.
MLP
273
Function-based, which makes the conguration short and easy to read. Efcient router operation and easier management, maintenance, and dynamic conguration assignment.
Virtual Proles
A virtual prole is another instance of virtuality, which is intended to overcome the limitations of network scalabilty. It is based on the same functionality-specic technique, where the user-specic conguration information can be applied to any remote user. The conguration information for virtual proles can come from either a virtual interface template, or per-user conguration information that is stored on an access control server (ACS), or both, depending on how the router and ACS are congured. When a user dials in, the virtual prole applies the generic interface conguration and then applies the per-user conguration to create a unique virtual access interface for that specic user. The concept of virtuality has a signicant impact on two of the most commonly used Cisco dial concepts: dial-on-demand routing (DDR) and dialer proles. In the case of legacy DDR, both parties learn the routes after the connection, but they dont delete them after they are disconnected. In the case of virtual interfaces, because of their dynamic nature, the route is removed as soon as the connection is dropped. Besides, the number of virtual interfaces is not limited by the number of physical interfaces. For example, the Cisco 4500 IOS 12.1 (7) allows 300 dialer proles, the Cisco 5300 IOS12.0 (7) allows 800 proles, and the Cisco 7206VXR allows 2896. The number depends on interface descriptor blocks (IDBs).
NOTE
You can nd out more about IDBs at the following site: www.cisco.com/warp/public/63/idb_limit.html or in the following Cisco Press book: Inside Cisco IOS Software Architecture
MLP
The MLP is relatively complex and is designed to solve several problems that are related to load balancing multilink wide-area network (WAN) links. The problems it solves include the following:
Multivendor interoperability, as specied by RFC 1717 Packet fragmentation, improving the latency of each packet
274
Packet sequence Load calculation
Cisco IOS Software supports MPPP and takes advantage of ISDNs access technology to split a single connection across two separate circuits. Originally dened in RFC 1717 of the Internet Engineering Task Force (IETF), and updated by RFC 1990, MLP was initially developed to assist emerging ISDN deployments. It is designed to fragment packets and transmit them over parallel connections such as ISDN BRI and Primary Rate Interface (PRI) access lines. This feature provides load balancing over dialer interfaces, including ISDN synchronous and asynchronous interfaces, improving throughput, and reducing latency between systems. Starting with a relatively simple conguration command, such as ppp multilink, the feature includes endpoint denitions for the multilink bundle (a multilink logical grouping is called a bundle), fragmentations, interleave, and threshold features. Figure 10-2 provides an example of how incoming (IN) packets are divided up into fragments, and sent over two separate ISDN lines (or two separate B channels). At the destination, another MLP peer receives the fragments and reassembles them back into the correct order.
Figure 10-2 Multilink Point-to-Point Protocol (MLP)
IN Packets E D C B A A B D
B1 B2
A B D
B1
OUT Packets E D C B A Sequencing and Reassembly
ISDN Cloud
B2
Sequencing and Fragmentation
C E
C E
MLP is suitable for a small ofce/home ofce (SOHO) environment because of the dynamic nature of bandwidth requirements, and because MLP works over any interface that supports DDR rotary groups and PPP. Multilink systems must do the following:
Receive protocol data units (PDUs) of a negotiated size Combine multiple physical links into one logical link (bundle) Receive and reassemble upper-layer PDUs
The MLP feature negotiates the Maximum Received Reconstructed Unit (MRRU) option during the Link Control Protocol (LCP) negotiation, to indicate to its peer that it can combine multiple physical links into a bundle. Also, to indicate that it is willing to multilink by sending the MRRU option as part of the initial LCP option negotiation. In Example 10-20, I and O are input and output messages of the LCP stage of PPP, and MRRU is the negotiated parameter.
MLP
275
Example 10-20 Negotiation of MRRU

*Mar 2 06:56:14.744: BR0:1 LCP: O CONFREQ [Closed] id 29 len 30 *Mar 2 06:56:14.744: BR0:1 LCP: MagicNumber 0xB765FD17 (0x0506B765FD17) *Mar 2 06:56:14.748: BR0:1 LCP: MRRU 1524 (0x110405F4) *Mar 2 06:56:14.748: BR0:1 LCP: EndpointDisc 1 Local (0x131001706E6564656C74632D6973646E) *Mar 2 06:56:14.776: BR0:1 LCP: I CONFREQ [REQsent] id 249 len 32 *Mar 2 06:56:14.776: BR0:1 LCP: AuthProto CHAP (0x0305C22305) *Mar 2 06:56:14.776: BR0:1 LCP: MagicNumber 0x2101ED36 (0x05062101ED36) *Mar 2 06:56:14.780: BR0:1 LCP: MRRU 1524 (0x110405F4) *Mar 2 06:56:14.780: BR0:1 LCP: EndpointDisc 1 Local (0x130D016163636573732D677731) *Mar 2 06:56:14.784: BR0:1 LCP: O CONFACK [REQsent] id 249 len 32 *Mar 2 06:56:14.784: BR0:1 LCP: AuthProto CHAP (0x0305C22305) *Mar 2 06:56:14.788: BR0:1 LCP: MagicNumber 0x2101ED36 (0x05062101ED36) *Mar 2 06:56:14.788: BR0:1 LCP: MRRU 1524 (0x110405F4) *Mar 2 06:56:14.788: BR0:1 LCP: EndpointDisc 1 Local (0x130D016163636573732D677731) *Mar 2 06:56:14.792: BR0:1 LCP: I CONFACK [ACKsent] id 29 len 30 *Mar 2 06:56:14.792: BR0:1 LCP: MagicNumber 0xB765FD17 (0x0506B765FD17) *Mar 2 06:56:14.796: BR0:1 LCP: MRRU 1524 (0x110405F4)
After the LCP negotiation has completed successfully, the remote destination must be authenticated, and a dialer map with the remote system name must be congured. The authenticated username (804-isdn) or callerID determines which bundle to add the link to. In Example 10-21, one-way authentication with host name authentication is used, where the line *Mar 2 06:56:15.628: BR0:1 PPP: Phase is VIRTUALIZED shows that the process is complete, and it starts a new phasevirtualization and MLP is ON.
Example 10-21 One-Way Authentication of the Remote User Preceding the MLP
*Mar 2 06:56:14.796: BR0:1 LCP: EndpointDisc 1 Local (0x131001706E6564656C74632D6973646E) *Mar 2 06:56:14.800: BR0:1 LCP: State is Open *Mar 2 06:56:14.800: BR0:1 PPP: Phase is AUTHENTICATING, by the peer *Mar 2 06:56:14.816: BR0:1 CHAP: I CHALLENGE id 130 len 31 from gateway *Mar 2 06:56:14.820: BR0:1 CHAP: O RESPONSE id 130 len 34 from 804-isdn *Mar 2 06:56:15.628: BR0:1 CHAP: I SUCCESS id 130 len 4 *Mar 2 06:56:15.628: BR0:1 PPP: Phase is VIRTUALIZED
To check if MLP is up and running, use the show ppp multilink command, as shown in Example 10-22.
276
Example 10-22 Determining if MLP Is Up and Running

804-isdn#show ppp multilink Virtual-Access1, bundle name is access-gw1 Bundle up for 00:00:18 Dialer interface is Dialer1 1 lost fragments, 1 reordered, 0 unassigned 0 discarded, 0 lost received, 1/255 load 0x7 received sequence, 0x0 sent sequence Member links: 2 (max not set, min not set) BRI0:1, since 00:00:18 BRI0:2, since 00:00:04 804-isdn#
The last two lines show two MLP members. Example 10-23 shows the output from the show negotiation command.
Example 10-23 Output from the show negotiation Command for 776 Router
776-isdn> show negotiation System Parameters PPP Negotiation Parameters Integrity Interval 10 Retry Count 10 Retry Interval 3000 Terminate Count 2 Multilink ON ! Profile Parameters Compression STAC BACP ON Address Negotiation Local OFF ! Negotiated Parameters Connection 1 Virtual Connection 2 PPP IPCP MLCP Connection 3 Virtual
In the global conguration, MLP supports two functions:

multilink bundle-name {authenticated multilink virtual-template 1-25
endpoint
both}
The virtual-template function is known to networkers; however, the multilink bundlename endpoint is relatively unknown. This feature was introduced in Cisco IOS Software Release 12.0. During the LCP negotiation of PPP, the endpoint discriminator (ED) option can be negotiated, but it is not required. As previously mentioned, after the LCP negotiation is complete, the remote destination must be authenticated, and a dialer map with the remote system name has to be congured. The dialer maps are not the only solution. See Chapter 11, Cisco ISDN Conguration Solutions, for more detail. The authenticated username or callerid determines which bundle to add the link. Its primary use is to make a MLP bundle
MLP
277
that is unique among different attached users. MLP bundles are either created or supplemented, based on the following four scenarios, and using the ED option in conjunction with an authenticated username. Refer to the output in Example 10-20:
*Mar *Mar *Mar *Mar 2 2 2 2 06:56:14.744: 06:56:14.744: 06:56:14.748: 06:56:14.748: BR0:1 BR0:1 BR0:1 BR0:1 LCP: O CONFREQ [Closed] id 29 len 30 LCP: MagicNumber 0xB765FD17 (0x0506B765FD17) LCP: MRRU 1524 (0x110405F4) LCP: EndpointDisc 1 Local:
Scenario 1: In the rst scenario, there is no discriminator, and no authentication; all new links must be joined into one bundle. This scenario is not a good idea for any dial service platform where users are not congured to authenticate nor to send an ED. The only time that this is likely to be used is between two xed systems, where links from an outside device cannot be physically introduced. The debug ppp negotiation output shows that EndpointDisc is missing. Cisco IOS Software uses the Calling Line ID (CLID) to identify the MLP bundle.
Scenario 2: In the second scenario, there is a discriminator, but no authentication. A discriminator match must join a matching bundle, and a discriminator mismatch must establish a new bundle. The debug ppp negotiation command shows the endPoint discriminator (EndpointDisc) negotiation:
Se3/0:2 LCP: EndpointDisc 1 804-isdn (0x1308013137323061) <-- ED negotiated with Class 1 (Locally Assigned Address), value = Hostname (804-isdn)
Scenario 3: In the third scenario, there is no discriminator, but there is authentication. The authenticated match must join the matching bundle, and the authenticated mismatch must establish a new bundle. The debug ppp negotiation will show that the EndpointDisc is missing again.
Scenario 4: In the last scenario, there is a discriminator and user authentication. The discriminator match and authenticated match must join the bundle, and either a discriminator mismatch or authenticated mismatch must establish a new bundle. Again, the command debug ppp negotiation command shows that the EndpointDisc is negotiated:
Se3/0:2 LCP: EndpointDisc 1 804-isdn (0x1308013137323061) <-- ED negotiated
You can nd more detailed information about MLP at Cisco.com.
278
MMP
With Cisco IOS Software Release 11.2, Cisco provided support for MMP. MLP is enhanced in MMP to enable different MLP links to terminate on different NASs. This enables ISPs and enterprises to design multiple network access servers that process calls for one single phone number, which is usually a telephone company (telco) hunt group, or for the leading phone number of the group of circuits. MMP also allows the network administrator to specify a router with greater CPU capacity to handle the reassembling and resequencing of the MLP packets, while leaving the routers with less CPU capacity to handle the call terminations. Another advantage of this design is scalability because a new NAS can be added to the existing environment to meet user demand, with minimal changes required to the existing design and conguration. Ciscos Stack Group Bidding Protocol (SGBP) is designed to enable MMP features. As only one router can handle the reassembling and resequencing of MLP packets for any given bundle, a mechanism is required to determine which router in the group (stack) owns the master bundle (also called the call master) to perform the tasks for that bundle. SGBP is used between all members (peers) of the stack group to determine the call master when any PPP link is connected. Each routers seed-bid can be manually congured from 0 to 9999 with the higher number winning the bid to be the call master. If theres a tie, the router that has the physical link is selected as the call master. If neither router has the physical connection, SGBP randomly picks one to be the call master for that user. After a router wins the bid for a specic user, it changes its bid for that user to 10,000, so it is guaranteed that it will win the bid for all subsequent calls from that user. SGBP uses UDP port 9900 to communicate. When a second call comes in from the same user and is terminated on a different router, a Layer 2 Forwarding (L2F) tunnel is built between the two routers, and the raw PPP data is forwarded over this tunnel from the call terminator to the call master. This is called projecting the PPP link to the call master. Eventually, this will be changed to use L2TP, which is an industry standard. Figure 10-3 shows an example of how SGBP works where RouterA, RouterB, and RouterC are in a stack group with equal seedbids, and UserA is connecting. As shown in Figure 10-3, the following 13 steps show the steps which Routers A, B, and C, with no off-load server, bid to be the call-master for UserAs PPP bundle:
1 UserA places the rst call. This is Call 1. 2 RouterB answers a call. 3 RouterB negotiates LCP up to the authentication challenge and identies the caller as
UserA.
4 RouterB informs the stack group of a call from UserA. 5 Group members bid for the call, and because all seed-bids are equal, RouterB wins
because RouterB terminates the call.
MMP
279
6 RouterB nishes authentication of UserA and nishes PPP negotiation. 7 UserA places a second call. This is Call 2. 8 The new MLP link connects to RouterC. 9 RouterC negotiates LCP up to the authentication challenge and identies the caller as UserA. 10 RouterC informs the stack group of a call from UserA. 11 The group bids for the call, and because RouterB is already the call master for UserA,
RouterB wins.
12 RouterC creates a L2F tunnel to RouterB and projects the PPP link to RouterB. 13 RouterB reassembles and resequences the MPPP packets. Figure 10-3 SGBP with No Off-Load Server
Router A Router B L2F Tunnel
Call 1 Router C Call 2
ISDN Switch
ISDN Cloud
ISDN Switch ISDN Switch
ISDN Switch
Call 1
Call 2
User A
280
The default seed-bid is 50. A more powerful router can also be congured as an ofoad server with the seed-bid value, depending on the platform. (For example, a 7200 has a value of 2620, a 3600 has a value of 1050, and a 2500 has a value of 80.) Conguring a seed-bid on a router for forwardonly causes the router to never bid for a call. It even hangs up the call rather than win the bid. Figure 10-4 shows an example of SGBP where RouterA, RouterB, and RouterC are in a stack group and RouterA is the off-load server that does not terminate any calls, and UserA is connecting.
Figure 10-4 SGBP with an Off-Load Server
L2F Tunnel
Router A
L2F Tunnel
Router B Call 1 Call 2 Router C
ISDN Switch
ISDN Cloud
ISDN Switch ISDN Switch
ISDN Switch
Call 1
Call 2
User A
Referring to Figure 10-4, the following 14 steps show the steps that Routers A, B, and C, with A as the off-load server bid, follow to be the call-master for UserAs PPP bundle:
1 UserA starts the rst call. This is Call 1. 2 RouterB answers the call. 3 RouterB negotiates LCP up to the authentication challenge and identies the caller as
UserA.
4 RouterB informs the stack group of a call from UserA.
MMP
281
5 Group bids are made for the call, and because RouterA is the off-load, RouterA
becomes the call master.

6 RouterB creates a L2F tunnel and forwards the raw PPP data to RouterA. 7 RouterA nishes authentication of UserA and nishes PPP negotiations. 8 UserA starts a second call. This is Call 2. 9 New MLP links connect to RouterC. 10 RouterC negotiates LCP up to the authentication challenge and identies the caller as
UserA.
11 RouterC informs the stack group of a call from UserA. 12 Group bids are made for the call, and because RouterA is already the call master,
RouterA wins.
13 RouterC creates a L2F tunnel and forwards the raw PPP data to RouterA. 14 RouterA reassembles and resequences the MLP packets.
All described operations and the protocol interactions are transparent to the end user. From the users debug information, it is impossible to determine if the other party is using MLP or MMP.
MMP Conguration
Example 10-24 shows the SGBP-related conguration items for each router in Figure 10-4.
Example 10-24 SGBP-Related Conguration for RouterA, RouterB, and RouterC in Figure 10-4
hostname routerA ! username dialin-group password cisco ! sgbp group dialin-group sgbp seed-bid offload sgbp member routerB 192.168.0.2 sgbp member routerC 192.168.0.3 sgbp source-ip 192.168.0.1
hostname routerB ! username dialin-group password cisco username userA password knockknock ! sgbp group dialin-group
continues
282
Example 10-24 SGBP-Related Conguration for RouterA, RouterB, and RouterC in Figure 10-4 (Continued)
sgbp member routerA 192.168.0.1 sgbp member routerC 192.168.0.3 sgbp source-ip 192.168.0.2
hostname routerC ! username dialin-group password cisco username userA password knockknock ! sgbp group dialin-group sgbp member routerA 192.168.0.1 sgbp member routerB 192.168.0.2 sgbp source-ip 192.168.0.3
Authentication of the SGBP group, and of the individual users, can be done through Terminal Access Controller Access Control System (TACACS).
NOTE
Each member is authenticating the stack group rather than each other. Also, each router does not specify itself as a member of the stack group, but does need to specify all other members in the stack group to create a fully meshed group.
There is nothing to congure to enable the L2F tunnels. If no dialer interfaces are dened, a virtual template and a virtual template interface must be congured, so that when a virtual access interface needs to be created for each bundle, there is a template to clone.
MMP Sample Implementation

In the sample implementation shown in Example 10-25, you need a solution for a company with thousands of telecommuters across the U.S. who want to connect to the corporate network through an ISDN BRI from each of their homes. You are going to use two 7200 routers (7200-isdn-a and 7200-isdn-b) to terminate the ISDN calls with no ofoad server.
Example 10-25 MMP Sample Implementation
hostname 7200-isdn-a ! username isdnservers password cisco username user1-isdn password user1 username user2-isdn password user2 ! sgbp group isdnservers sgbp member 7200-isdn-b 172.30.253.253
MMP
283
Example 10-25 MMP Sample Implementation (Continued)

sgbp source-ip 172.30.253.254 ! ! many T1 controllers ! controller T1 2/0 framing esf linecode b8zs pri-group timeslots 1-24 ! ! a Serial interface for each T1 ! interface Serial2/0:23 no ip address encapsulation ppp dialer rotary-group 1 isdn switch-type primary-4ess no cdp enable ! interface Dialer1 bandwidth 128 ip unnumbered Loopback0 encapsulation ppp dialer in-band dialer hold-queue 20 dialer-group 1 peer default ip address pool ISDN-POOL fair-queue no cdp enable ppp authentication chap isdn ppp chap hostname 7200-isdn ppp multilink !
hostname 7200-isdn-b ! username isdnservers password cisco username user1-isdn password user1 username user2-isdn password user2 ! sgbp group isdnservers sgbp member 7200-isdn-a 172.30.253.254 sgbp source-ip 172.30.253.253 ! ! many T1 controllers ! controller T1 2/0 framing esf linecode b8zs pri-group timeslots 1-24 !
continues
284
Example 10-25 MMP Sample Implementation (Continued)

! a Serial interface for each T1 ! interface Serial2/0:23 no ip address encapsulation ppp dialer rotary-group 1 isdn switch-type primary-4ess no cdp enable ! interface Dialer1 bandwidth 128 ip unnumbered Loopback0 encapsulation ppp dialer in-band dialer hold-queue 20 dialer-group 1 peer default ip address pool ISDN-POOL fair-queue no cdp enable ppp authentication chap isdn ppp chap hostname 7200-isdn ppp multilink !
The T1 controller conguration, along with the serial and dialer interface conguration, are standard ISDN and PPP congurations. The MMP-specic commands are the username and passwords for the SGBP group, and the three lines that start with sgbp commands.
Verifying MMP
The show sgbp command displays the status of the stack group members, as shown in Example 10-26.
Example 10-26 Displaying Stack Group Member Status
7200-isdn-b#show sgbp Group Name: isdnservers Ref: 0xC973B000 Seed bid: default, 50, default seed bid setting Member Name: 7200-isdn-a State: active Id: 1 Ref: 0x8ECD9400 Address: 172.30.253.254
The output includes the name of the stack group, the locally congured seed-bid, and each peer and its status. The ve possible states for a peer are as follows:
IDLE CONNECTING
Summary
285
WAIT_INFO AUTHOK ACTIVE
In Example 10-26, if the state is IDLE, it means that the stack group isdnservers cannot detect 7200-isdn-a as a peer. The other three states are transition states from IDLE to ACTIVE. ACTIVE indicates a fully functional peer. If problems or miscongurations exist on the local router, all congured peers might be in the IDLE state. Example 10-27 shows output from 7200-isdn-b, where the master bundle is owned by 7200-isdn-b, and one of the MLP links is connected to 7200-isdn-a. In show ppp multilink, the second member link is connected to 7200-isdn-a and is forwarded to the Virtual-Access 17 interface of 7200-isdn-b. In show users, that Vi17 is the L2F tunnel.
Example 10-27 Verifying Master Bundle Ownership, Stack Member Connection Information, and L2F Tunnel
Identication
7200-isdn-b#show ppp multilink | begin user2-isdn Virtual-Access76, bundle name is user2-isdn Bundle up for 00:06:35 Using relaxed lost fragment detection algorithm. Dialer interface is Dialer1 0 lost fragments, 1431 reordered, 0 unassigned 0 discarded, 0 lost received, 23/255 load 0x12CC received sequence, 0x8B8 sent sequence Member links: 2 (max not set, min not set) Serial3/3:20, since 00:06:35, last rcvd seq 0012CB 7200-isdn-a:Virtual-Access17 (172.30.253.254), since 00:06:25, last rcvd seq 0012C4, unsequenced 7200-isdn-b#show users | include user2 Vi17 user2-isdn Virtual PPP (L2F ) Vi76 user2-isdn Virtual PPP (Bundle) 00:00:00 10.70.200.137 Se3/3:20 user2-isdn Sync PPP Bundle: Vi76
On 7200-isdn-a, shown in Example 10-28, you see only the physical link, but nothing else.
Table 10-1 Output of the show users Command Reveals Only the Physical Link
7200-isdn-a#show users | include user2 Se5/0:8 user2-isdn Sync PPP -
Summary
The design solutions provided in this chapter are not the only possible design solutions, but they are the most common and established ones. The main topics here are to enhance knowledge of the troubleshooting engineer in industry-established enterprise and ISP
286
design solutions, ISDN switch types, SPIDs and LDNs, IP pool design, and NAT and PAT solutions. Detailed description for per-user design, virtual templates, and proles is also provided. Because of the signicance of MLP and MMP, a detailed explanation is also provided. This chapter contributes to the identication of the expected behavior of the system, where the routers are expected to perform according to the context of the particular design.
Review Questions
1 Name the most common ISDN switch types in the U.S. and Canada? 2 Type a command that sets up the switch-type NI1 for a Cisco IOS Software ISDN
router in global conguration mode.

3 Type a command to dene a local pool of 63 IP addresses for your core router, starting
with 20.18.15.1, if the pool name is LOCAL_POOL.

4 What is the theoretical maximum number of ports in PAT? 5 How much memory consumes one NAT translation? 6 Name at least ve protocols that are supported by Cisco IOS Software NAT. 7 In the case of the virtual interfaces, what happens with the route when the connection
is tear-down?
8 Name three main functions of multilink systems. 9 Why would you use multilink PPP between a remote ofce and corporate headquarters? 10 On which interface types can you use multilink PPP? 11 What does the MRRU stand for and at which stage of the PPP protocol is it used? 12 What is the purpose of using the endpoint discriminator (ED) option in MP? 13 What Cisco IOS Software command displays the status of the stack group members? 14 Name the ve possible states of the peer in the stack-group.
CHAPTER
11
Cisco ISDN Conguration Solutions

A wide variety of conguration solutions is available in the existing literature, comprising years of engineering experience. This chapter mainly covers the cost-effective solutions because they are the most common in the existing industry practices, and because Integrated Services Digital Network (ISDN), as a service, is under the pressure of other technologies because of its cost drawbacks in remote access solutions. Most network engineers distinguish the following conguration solutions of ISDN design implementations, and all of them are related to cost efciency or availability:
Spoong Snapshot routing Dial-on-demand routing (DDR) Callback solutions
This chapter provides additional information about some security features of ISDN and advanced phone settings because Voice over ISDN is a widely available service offered by local providers. It also is one of the appealing features of ISDN service.
Cisco ISDN Cost-Effective Solutions

ISDN is offered by most local exchange carriers (LECs). Its used for data, voice, and video exchange. Recently, the use of ISDN for offnet video-conferencing has increased. However, ISDN became less attractive as a cost-effective solution when compared to other emerging technologies, such as digital subscriber line (DSL), cable, wireless, and satellite. The cost of ISDN service is usually composed of an initial installation charge plus usage-based charges. In some cases, a LEC might differentiate pricing of the rst minute in comparison to the following minutes. However, all LECs base the per-usage charge on the number and duration of calls. Using special equipment, such as a Centrex, makes it possible to map the calls to other numbers with the same prex, which reduces the number of digits to dial (for example, ve instead of ten), and reduces the cost to a at-rate service. In some areas, ISDN is still the only alternative providing Basic Rate Interface (BRI) service with two data/voice channels for remote users. The following alternatives are cost-effective solutions that need to be considered.
290
Chapter 11: Cisco ISDN Conguration Solutions
Spoong
One of the most popular ISDN techniques is called spoong, which is where the router responds to keepalive packets instead of sending them to the remote party. If the spoong is up, the protocol layer is reporting up, as shown in Example 11-1. In order for any interface to report the protocol layer up, the other party must respond to keepalives, but in spoong, the router itself responds to keepalives. Spoong is also part of the troubleshooting technique to check the status of the dialer interface. Even when the router does not make a call, the dialer shows a spoong state.
Example 11-1
show interfaces dialer 1 Command Output Reveals Dialer1 is up (spoong), line protocol is up (spoong)
804-isdn# show interfaces dialer 1 Dialer1 is up (spoofing), line protocol is up (spoofing) Hardware is Unknown Interface is unnumbered. Using address of Ethernet0 (151.70.209.81) MTU 1500 bytes, BW 128 Kbit, DLY 20000 usec, reliability 255/255, txload 1/255, rxload 1/255 Encapsulation PPP, loopback not set Keepalive set (10 sec) DTR is pulsed for 1 seconds on reset Last input never, output never, output hang never Last clearing of show interface counters never Input queue: 1/75/0/0 (size/max/drops/flushes); Total output drops: 0 Queueing strategy: weighted fair Output queue: 0/1000/64/0 (size/max total/threshold/drops) Conversations 0/0/16 (active/max active/max total) Reserved Conversations 0/0 (allocated/max allocated) 5 minute input rate 0 bits/sec, 0 packets/sec 5 minute output rate 0 bits/sec, 0 packets/sec 112555 packets input, 102607119 bytes 77225 packets output, 9186472 bytes
If you monitor the 5 minute input rate and 5 minute output rate counters in Example 111, you dont see any activity. The spoong only imitates an active state of the dialer, but this does not mean that the router is connected, or makes a call. This is the cost-saving effect of the spoong because the router is not connected and there is no charge from the local provider. To clarify, the router makes a call only if the DDR conditions are met.
Snapshot Routing and OSPF Demand Circuits

Another innovative cost-effective ISDN conguration technique is called snapshot routing. Before snapshot routing became available in Cisco IOS Software Release 10.2, ISDN interfaces were congured using static routes, which prevent bandwidth from being consumed by routing updates. But, they are difcult to maintain as the network grows. Snapshot routing supports dynamic routes by allowing routing updates to occur during an
291
active period. It also reduces connection cost by suppressing routing updates during a quiet period; thus, snapshot routing is a way to reduce connection time in ISDN networks by suppressing the transfer of routing updates for a congurable period of time. In ISDN, snapshot routing is applicable for distance vector routing protocols, such as Routing Information Protocol (RIP) and Interior Gateway Routing Protocol (IGRP) for IP, RTMP for AppleTalk, RIP and SAP for IPX, and RTP for Vines. Heres why: As you know, the concept of distance vector protocols is based on triggered updates. The goal of snapshot routing is to allow distance vector routing protocols to exchange updates as they normally would. The nature of snapshot routing is based on the notion that the router learns of routing updates without periodic updates, thus reducing the number and duration of unnecessary calls and reducing cost. Snapshot routing denes active periods and quiet periods. The active period is a time slot that enables the routing updates to be sent over the DDR interface for a short duration of time. After the active periods expiration, the router alternates with a quiet period when the routing tables at both ends of the link are frozen. Snapshot is, therefore, a triggering mechanism that controls routing updates through a DDR exchange. Both periods can be congured based on the trafc, time of day, and cost-effective considerations. As soon as a call is triggered for any reason, such as interesting trafc in DDR or a DNS lookup, it triggers the active period timer, as shown in Figure 11-1. During that session, both parties update their routing tables. After the active periods expiration, which can be between 5 and 100 minutes, the update is frozen and both parties enter the quiet period. After the expiration of this time slot and if no calls were made, the router triggers another call, sets the timer, and starts another active period exchange. The quiet period can be congured in a large range, which can be between 5 minutes and 65 days. Because of this possible delay, the technique offers another congurable time slot called a retry period, where more updates can be exchanged if no other activity is on the link.
Figure 11-1 The Active, Quiet, and Retry Period Interaction in Snapshot Routing
Configurable Active Period

5 -100 Minutes
NonConfigurable Configurable Retry Period

8 Minutes
Configurable Quiet Period

5 Minutes - 65 Days
Configurable Active Period

5 -100 Minutes
Active Period
5 -100 Minutes
Time
Example 11-2 shows the conguration options for snapshot routing for the dialer 1 interface.
292
Example 11-2
Snapshot Routing Options of Cisco IOS Software

804-isdn(config-if)#dialer map snapshot 1 ? WORD Dialer string broadcast Broadcasts should be forwarded to this address class Dialer map class modem-script Specify regular expression to select modem dialing script name Map to a host spc Semi-permanent connections speed Set dialer speed system-script Specify regular expression to select system dialing script
Another application for the same command line redenes the default speed and then applies the map class to the dialer interface:
804-isdn(config-if)#dialer map snapshot 1 class class-name speed [56 | 64] It is almost mandatory to congure the next line under the BRI or dialer interface: 804-isdn(config-if)#snapshot [client | server] active-time quiet-time [suppress-statechange-updates][dialer]
The [client | server] option must be dened as client on the spoke side and server on the hub side of the connection. The active-time variable species the amount of time, in minutes, that routing updates are regularly exchanged between the client and server routers. This can be an integer in the range 5 to 100. There is no default value. A typical value is 5 minutes. The quiet-time variable species the amount of time, in minutes, that routing entries are frozen and remain unchanged between active periods. Routes are not aged during the quiet period, so they remain in the routing table as if they were static entries. This argument can be an integer from 8 to 100,000. There is no default value. The minimum quiet time is generally the active time plus 3. The snapshot command ensures that, if any other event triggers the call out, the snapshot algorithm starts the active period timer and the routing updates will take place.
NOTE
Always start the monitoring of snapshot connections and routing by clearing the appropriate interfaces. clear dialer or clear counters [bri | dialer] clears the interface or the previous diagnostic statistics.
Use the following commands to monitor snapshot connections and routing:
show dialer [interface type number]Displays general diagnostics about the interface show interfaces bri 0Displays information about the ISDN D-channel
293
clear snapshot quiet-time interfaceTerminates the snapshot routing quiet period on the client router within two minutes show snapshot [type number]Displays information about snapshot routing parameters
Information about snapshot routing is relatively new. You can nd more information about periodic updates at Cisco.com. The key advantages of the snapshot technique are easy evolution, scalability, and manageability. Snapshot routing is applicable, but not limited, only to ISDN networks. The leased lines can benet from the reduction of periodic updates that snapshot routing provides. Snapshot routing is applicable for hub-and-spoke topologies; its not recommended for meshed topologies. In meshed topologies, conguring static routes is more efcient than conguring snapshot routing. The link-state protocols, such as Novell Link Services Protocol (NLSP), Open Shortest Path First (OSPF), and Intermediate System-to-Intermediate System (IS-IS) depend on the frequent sending of Hello messages in a short period of time (ve or ten seconds) to neighboring routers in order to discover and maintain routes. This fact makes them not suitable for this technique. For OSPF, which belongs to the family of link-state routing protocols, the ospf demand circuit can be thought of as the equivalent to snapshot routing, but with a link-state protocol. The demand circuit options were introduced for OSPF in Cisco IOS Software Release 11.2 in response to the OSPF (RFC 1793). OSPF sends Hellos every 10 seconds and refreshes its link-state advertisements (LSAs) every 30 minutes. These functions, which maintain neighbor relationships and ensure that the link-state databases are accurate, use far less bandwidth than similar functions in RIP and IGRP. However, even this amount of trafc is unwanted on demand circuits. By using the OSPF demand circuit options, which suppresses Hello and LSA refresh functions, OSPF can establish a demand link to form an adjacency and perform initial database synchronization. The adjacency remains active even after Layer 2 of the demand circuit goes down. The two main features of OSPF over demand circuits are
Suppressed periodic Hellos Suppressed periodic LSA refresh
You can nd more information about this topic at www.cisco.com/univercd/cc/td/doc/ product/software/ios120/12cgcr/np1_c/1cprt1/1cospf.htm.
DDR
DDR is the most common cost-effective technique used in ISDN router congurations. With DDR, all trafc is classied as either interesting or uninteresting. Regardless of the advantages of using dynamic versus static routing, static routing is still a viable solution for
294
a remote access environment and it is commonly used in DDR. One of the reasons is that the dynamic routing updates can trigger the router to call out every time the routing update is necessary. There are two main options for implementing DDR for routers with ISDN BRIs:
Dialer maps (sometimes referred to as legacy DDR), which are available for Cisco IOS Software Releases prior to 11.2. Dialer proles, which are available in Cisco IOS Software Release 11.2 and all subsequent versions.
The DDR features discussed in this chapter can be used over ISDN or other dial-up media, as well as over any asynchronous lines.
NOTE
The existence of the dialer interface in the conguration does not necessarily classify it as a dialer prole conguration. The key difference is the mapping and rotary group elements for the legacy DDR versus dialer proles and pools.
The general concept and function of DDR can be narrowed to the following steps:
1 When the router receives some trafc, it performs a table lookup to determine whether
there is a route to the desired destination. Based on the conguration, the outbound interface is identied.
2 If the identied outbound interface is congured for DDR, the router does a lookup to
determine whether the trafc is interesting based on the dialer list statement of the conguration.
3 The router then identies the next hop router and locates the dialing information based
on dialer map or dialer proles conguration.

4 In the case of dialer proles, the router checks if the dialer is currently connected to
the desired remote destination. If so, the trafc is sent and the idle timer is reset to the maximum congured value every time the interesting packet crosses that dialer.
5 In the case of dialer proles, if the dialer is not currently connected to the desired
remote destination, the router determines which physical interfaces are in its dialer pool, borrows an interface, makes a call out, applies the map class (if it exists) and dialer interface conguration, establishes a connection, and sets the idle timer to its maximum congured value.
6 After the link is established, the router transmits both interesting and uninteresting
trafc. Uninteresting trafc can include data and routing updates.
295
7 When the time duration between any two consecutive interesting events is greater than
the idle timer value, or the idle timer expires, the call is disconnected. In the case of dialer proles, the physical interface is released and goes back to the dialer pool.
NOTE
DDR is not a trafc lter solution, but a mechanism to force a call setup and call teardown. The moment the interesting trafc triggers a call, the router resets the idle timer to the maximum congured value each time the interesting trafc crosses the interface. As long as the interface is up, however, all trafc is forwarded over that interface. Remember that only the interesting trafc can set or reset the idle timer; otherwise, the idle timer, ticking down by default, expires.
For troubleshooting purposes, refer to one simple procedure, provided in Chapter 7 of Building Cisco Remote Access Networks by Catherine Paquet (Cisco Press, 1999). Obviously, if all trafc is interesting, the router constantly keeps the line up 24 hours a day. This raises questions about how to dene interesting trafc and what are the techniques to distinguish it from non-interesting trafc in order to make DDR a cost-effective solution, reducing the up time and, as a result, the duration of the calls. Both legacy DDR and dialer proles solutions work simultaneously in existing Cisco production environments. For CPE signicance, they are local. As a result, you might have a dialer proles on the spoke side and legacy DDR on the hub side, or any other combination. In general, the legacy DDR requires the following steps:
1 Specify interesting trafc. What trafc type should enable the link? 2 Dene static routes. What route do you take to get to the destination? 3 Congure the dialer information. What number do you call to get to the next hop
router? What service parameters do you use for the call? The key for this conguration is mapping the protocol, address, the remote address name and the phone number with the following command:
dialer map ip 161.30.253.254 name gateway broadcast 14085265555
These steps can be performed when conguring the dialer proles, but the content of the dialer information differs. You can nd additional information about legacy DDR at Cisco.com, but for the sake of a complete explanation, here are some of the specics and limitations of legacy DDR:
There is one congured interface per ISDN interface. Before dialer proles, all ISDN B channels inherited the physical interfaces conguration.
296
Before dialer proles, one dialer map was required per dialer per protocol, making multiprotocol congurations very complex. When a PRI is used to back up an interface, all B channels are down and the entire interface is idle. In a packet-switched environment in which many virtual circuits might need to be backed up individually and oating static routes are not desirable, the one-to-one relationship between interfaces and backup interfaces does not scale well. Using the concept of rotary groups makes the conguration inexible and restrictive because the physical interface participates in only one rotary group.
NOTE
The following section focuses on dialer proles, which conceptually are based on creating virtual interfaces and allow the physical interfaces to belong to many different pools.
When reviewing router hardware, you will not nd a physical interface called a dialer. The dialer prole feature enables you to congure dial-on-demand capabilities (in a dialer interface) separate from the physical interface. Because of this separation, the BRI and PRI interfaces can be shared by multiple dialer prole congurations, and the number of dialer proles can be signicantup to 300 for Cisco 4500 and more than 2800 for Cisco 7206VXR. (See more about this topic in the section, Virtual Proles, in Chapter 10, ISDN Design Solutions.) Dialer proles enable logical and physical congurations to be bound together dynamically on a per-call requirements basis. Dialer proles can dene encapsulation, access control lists (ACLs), minimum or maximum calls, and turn on and off a variety of features. With dialer proles, the physical interfaces become members of a dialer pool, which is congurable and represents a set of interfaces that can be used on an on-demand basis. When a call must be made, the dialer pool borrows a physical interface for the duration of the call, based on the dialer interface conguration. After the call is complete, the physical interface is returned to the dialer pool. Dialer proles enable BRIs to belong to multiple dialer pools. This eliminates wasting ISDN B channels. Multiple destinations can be bridged to avoid split horizon problems. Remote routers or users access can be controlled or customized through independent dialer proles. The list of features can be extended. The dialer proles perform the same cost-effective feature of DDR, achieving more exibility and scalability of the conguration. The main elements of the dialer prole include the following:
Dialer interfacesLogical entities used for a per-destination dialer prole. Any number of dialer interfaces can be created in a router. All conguration settings specic to the destination are congurable in the dialer interface conguration. Dialer poolRepresents a group of physical interfaces associated with a dialer prole. A physical interface can belong to multiple dialer pools. Contention for a specic physical interface is resolved by conguring the optional priority command.
297
Physical interfacesCongured for encapsulation parameters. The interfaces are congured to identify the dialer pools to which the interfaces belong. Dialer map class (optional)The dialer map-class command denes specic parameters, such as speed, timers, and so on, and can be applied to different dialer interfaces.
Typically, dialer proles support PPP and high-level data link control (HDLC) encapsulation. To congure the dialer proles for DDR, perform the following steps:
Step 1 Congure the dialer interface. Step 2 Make every physical interface a member of a dialer pool. Step 3 Specify the interesting trafc. Step 4 Dene the static route. Step 5 Optionally, you can dene the map class.
The following sections cover each step in detail.
Step 1Conguring the Dialer Interface

As previously mentioned, the dialer interface is a non-physical interface. It denes the call destination. As is usual for every interface conguration, you have to rst congure the interface, its type, and its number. Figure 11-2 shows the network setup and conguration information.
Figure 11-2 Conguring the Dialer Interface for Cisco IOS-Based ISDN Router on the Remote Users Side and on the Core Routers Side
Remote User
Host name - 804-isdn ISDN switch-type NI ISDN SPID1 40857647400101 5764740 ISDN SPID2 40857647410101 5764741 POTS2 POTS1 Dialer 1 Default-Gateway IP 161.70.209.81 Laptop Computer Description of Dialer 1 - Spoke site ip address negotiated IP Subnet 161.70.209.80/29 ip access-group 101 in ip nat outside encapsulation ppp dialer remote-name gateway dialer string 5265555 class DialClass dialer pool 1 dialer-group 1 ppp chap hostname 804-isdn ppp chap password ENS ppp multilink IP Phone Phone 408 526 5555 ISDN Cloud Chap host name - gateway Dialer 1- IP address 161.30.253.254
Core Router
Description of Dialer 1 - Hub site bandwidth 128 ip unnumbered Loopback0 encapsulation ppp dialer idle-timeout 900 either dialer wait-for-carrier-time 100 dialer hold-queue 20 dialer pool 1 dialer-group 1 ppp chap hostname gateway ppp multilink
298
The following text examines some of the more signicant aspects of the dialer interface conguration. For the encapsulation type command, type is typically ppp. For the ppp authentication type command, type can be pap, chap, or both in specic order. The chap type involves conguration of the host name of the other party. Generally speaking, PPP does not need authentication to connect. It requires two conditions to connect:
A host name PPP conguration
As soon as two-way CHAP authentication is dened, however, you must congure the remote hosts CHAP name. There are two different options (keep in mind that the remote name is case sensitive):
Case 1
804-isdn(config-if)#dialer remote-name username
username, which is the CHAP name of the hub side, is dened as gateway in Figure 11-2. The remote users side is congured under the dialer 1 interface with the following:
804-isdn(config-if)#ppp chap hostname 804-isdn 804-isdn(config-if)#ppp chap password ENS
where 804-isdn is the spoke CHAP name and ENS is the spoke password.
Case 2 The remote name can be dened in the global conguration mode with the following commands:
804-isdn(config)#hostname 804-isdn 804-isdn(config)#username gateway password ENS
The parameter gateway matches the CHAP name or the host name of the remote party. Enable the multilink feature of the PPP protocol with PPP multilink. The string in the following command represents a phone number:
dialer-string string class DialClass
In the case of Figure 11-2, the phone number is 526-5555, because the user is calling from the same area. In general, the string includes 1 + area code + 7-digit number of the remote party. In this command, class represents the name of the map class, which will apply (map) to this dialer interface. In the dialer pool number command, the number parameter represents with which pool the dialer interface is associated.
299
In the dialer pool-member number priority number command, which must be congured for each physical interface, number refers to which pool member this physical interface belongs and the second number parameter species the priority that can fall in the range of 1255. The dialer-group number command assigns the interesting trafc denition to the dialer interface. When applying this line to the dialer interface, ensure that the number matches that of the dialer-list command.
Step 2Dening a Physical Interface as a Member of the Dialer Pool

The dialer pool is a set of physical interfaces used when a dialer interface needs to make a call. As previously mentioned, for the physical interface making a call, you can never expect the B channel to make a call. Call establishment, call clearance, and other signaling functions are the prerogative of the D channel in the 2B+D or 23B+D conguration. In general, you must enable in-band dialing to ensure the specied channel makes the call. However, this line is not necessary for the BRI interface because BRI uses out-of-band dialing through the D channel. The D channel can be assigned to more than one pool, and can be prioritized within each pool to avoid contention. It is more common to assign the D channel of the BRIs (if there are more than one) to different pools, when considering capacity issues or other trafcdependant issues. In the case of an 804 ISDN router, there is only one BRI interface. For routers with more than one BRI interface, you must dene each of them as a member of any pool with the following command:
804-isdn(config-if)# dialer pool-member 4 priority 255
NOTE
The number 4 (from the range of 1255) is the number of the dialer pool to which the physical interface is assigned. The priority (0255) is also assigned, where 255 is the highest priority and indicates the dialer interface will choose this physical interface rst. The priority parameter is optional. If it is not used and several physical interfaces are members of the same pool, the interface with the lowest port number will be selected rst. If that interface is busy, the next lowest port number is selected. The next important step in Cisco IOS Software-based ISDN BRI0 conguration is to dene the encapsulation and authentication under the physical interface, as follows:
encapsulation ppp ppp authentication chap [pap callin] enable ppp multilink
300
As you can see, this step differs from the legacy DDR, where only the command
804-isdn(config-if)#encapsulation ppp
is required under the physical interface. The reason for conguring the authentication and PPP multilink for dialer proles DDR is because, based on the authentication information, that is how the router knows which dialer prole to switch the call to. As a result, the authentication must be set on the physical interface as well. If the dialer interface is congured for PPP multilink, it is recommended under the physical interface as well. If the remote users CPE is a Cisco 77x router, the role of the interface is performed by a conguration term called user. The user gateway is congured, as shown in Example 11-3.
Example 11-3
The User Gateway in 77x ISDN Router Performs the Role of Dialer Interface
776-isdn>upload cd set user gateway set ip routing on set ip framing none set speed 64 set number 5265555 set ip rip update off set encapsulation ppp set ip route destination 0.0.0.0 gateway 0.0.0.0 cd set ppp authentication incoming chap set ppp authentication outgoing chap set ppp secret client <password> <password> set ppp secret host <password> <password> <output omitted>
There is a partial analogy to the legacy DDR because all the elements of the DDR are available. The ACL option is discussed in the section, Step 3Specifying the Interesting Trafc. Example 11-4 shows the distribution of dialer pools for a Cisco 3640 router (core side), where interfaces Serial1/0:23 and Serial1/1:23 are members of dialer group 1, while Serial2/0:23 and Serial3/0:23 are members of dialer pools 2 and 3, respectively.
Example 11-4
The Dialer Pool Member Conguration in the Core Router

3600-isdn#show running-config interface Serial1/0:23 description PRI Slot 1:Serial0: D-channel configuration; 408-526-5555 no ip address
301
Example 11-4
The Dialer Pool Member Conguration in the Core Router (Continued)

encapsulation ppp ip tcp header-compression passive dialer pool-member 1 priority 1 isdn switch-type primary-5ess <output omitted> ! interface Serial1/1:23 description PRI Slot 1:Serial1: D-channel configuration; 408-526-5555 no ip address encapsulation ppp ip tcp header-compression passive dialer pool-member 1 priority 255 isdn switch-type primary-5ess <output omitted> ! interface Serial2/0:23 description PRI Slot 2:Serial0: D-channel configuration; 408-526-6666 no ip address encapsulation ppp ip tcp header-compression passive dialer pool-member 2 isdn switch-type primary-5ess <Output omitted> ! interface Serial3/0:23 description PRI Slot 3:Serial0: D-channel configuration; 408-526-7777 no ip address encapsulation ppp ip tcp header-compression passive dialer pool-member 3 isdn switch-type primary-5ess <Output omitted>
In this conguration, the Serial1/0:23 and Serial1/1:23 are members of pool 1, but Serial1/ 1:23 has the highest, whereas Serial1/0:23 has the lowest priority.
Step 3Specifying the Interesting Trafc

As you already know, the dialer-list command and its denition distinguish the interesting from the non-interesting trafc. The dialer list can use ACLs and the associated security mechanisms and techniques for this purposes as well. ACLs can be referred to as standard, extended, named, and temporary. You can nd a multitude of resources about ACLs at Cisco.com. Example 11-5 shows a sample ACL for the remote users side of the connection, based on Cisco IOS ISDN 804 router, where dialer-list 1 uses ACL 101 to dene the interesting trafc.
302
Example 11-5
dialer-list 1 Uses ACL 101 to Dene the Interesting Trafc in DDR

access-list access-list access-list access-list access-list access-list access-list access-list access-list access-list access-list access-list access-list dialer-list 101 deny icmp any any echo-reply 101 deny icmp any any host-unreachable 101 deny udp any any eq ntp 101 deny igmp any any 101 deny ip any host 230.0.0.13 101 deny ip any host 230.0.1.39 101 deny ip any host 230.0.1.40 101 deny ip any host 230.2.127.253 101 deny ip any host 230.2.127.254 101 deny ip any host 230.2.127.255 101 deny ip any host 10.68.235.228 101 deny ip any host 11.68.235.229 101 permit ip any any 1 protocol ip list 101
In Example 11-5, the ACL denies the following:
Some of the ICMP messages (lines 1 and 2). UDP messages exchanging Network Time Protocol (line 3). Internet Group Management Protocol (line 4). A group of multicast source addresses (lines 510). Two WINS servers (lines 11 and 12). Line 13 permits everything else. Line 14 is the dialer-list 1 denition, using ACL 101.
Step 4Dening the Static Route

The static route can be congured using the following command syntax: | interface} The following is an example for setting the default route:
804-isdn(config)#ip route prefix mask {address 804-isdn(config)# ip route 0.0.0.0 0.0.0.0 161.68.26.1 [distance] [permanent]
If the router needs to redistribute IP addresses in the dened range, on the hub side, they need to be redistributed with the appropriate set of commands. You can nd additional discussions related to routing protocols at Cisco.com.
Step 5 (Optional)Dening the Map Class

Dening the map class is optional, but it is recommended because it creates scalable congurations. Assume the map class is called DialClass and denes the following parameters:
303
A class name with a name parameter The time to wait before terminating the link when another call must be made The amount of time to wait after there is no interesting trafc to send, before terminating the link The amount of time to wait for a carrier to pick up the call after dialing the dial string The dialer speed that assigns the desired speed to the ISDN line. A short conguration of map class, dening the desired speed, could be the following:
804-isdn(config)#map-class dialer DialClass 804-isdn(config-map-cla)#dialer isdn speed 56
Then, this map class has to be associated with the dialer-string command, discussed in Step 1. For more detailed conguration rules and explanations, visit Cisco.com.
PPP Callback for ISDN

The PPP LCP Extensions in FRC 1570 denes a callback function, which is negotiated during the LCP phase of PPP. The callback function of PPP for ISDN interfaces allows a Cisco router using a DDR mechanism and PPP encapsulation to initiate a link to another device and request a callback. A Cisco ISDN router responds to a callback request from a remote device. The process uses the Point-to-Point Protocol (PPP) and the LCP extension specications in RFC 1570. The callback feature of PPP (introduced in Cisco IOS 11.0) enables the remote user to place a call to the NAS and request the core router to call the remote user back. A typical negotiation would proceed as follows:
1 The remote users router establishes a connection to the core router. 2 The remote users router and the core router negotiate PPP Link Control Protocol
(LCP) with the remote users router requesting callback.

3 Both routers authenticate each other using PPP, PAP, or CHAP protocols. It is typical
that the initiator of the call to be requested to authenticate itself. In this scenario, this is the remote users router. The core routers authentication is optional.
4 After authentication, the core router disconnects the call. 5 The core router calls out and establishes a connection with the remote users router.
The cost-saving effects of an ISDN Cisco IOS Software callback occurs when a difference exists between the usage-based costs associated with the remote users service and the core routers service. Usually, the corporate site obtains higher discounts from providers because of the expected call volume.
304
The next example shows how to congure the dialer interfaces of both sites to perform the callback function of PPP for ISDN.
Remote User Router Conguration

Example 11-6 shows a remote users router conguration.
Example 11-6
PPP Callback for ISDN: Remote User Router Conguration

804-isdn(config)#interface dialer 1 804-isdn(config-if)#ppp callback request ! If the following line does not exist, configure: 804-isdn(config-if)#dialer hold-queue 100 timeout 20
The ppp callback request line species that when the interface places a call, it requests a callback. The dialer hold-queue 100 timeout 20 species that up to 100 packets can be held in a queue until the core router returns the call. If the core router does not return the call within 20 seconds, plus the length of the enable timeout (congured on the central site router), the packets are dropped.
Core Router Conguration

Conguring the core router for PPP callback for ISDN involves two separate congurations:

Example 11-7
Dening and naming the map class Dening PPP callback for ISDN under the dialer interface
Example 11-7 and Example 11-8 demonstrate these two steps.

PPP Callback for ISDN: Core Router CongurationDening and Naming the Map Class
7206-isdn(config)#map-class dialer CALLBACK 7206-isdn(config-map-class)#dialer callback-server username
Example 11-8
PPP Callback for ISDN: Core Router CongurationDening PPP Callback for ISDN Under the Dialer Interface
7206-isdn(config)#interface dialer 1 7206-isdn(config-if)#ppp callback accept 7206-isdn(config-if)#dialer callback-secure 7206-isdn(config-if)#dialer enable-timeout 5 ! If the following line does not exist already, configure: 7206-isdn(config-if)#dialer hold-queue 100 ! This is the phone number of the remote user: 7206-isdn(config-if)# dialer map ip 10.19.241.1 name 804-isdn speed 56 class CALLBACK 14085764740
ISDN Security
305
TIP
The dialer re-enable time must be greater than the serial pulse time.
The map-class dialer establishes a quality of service (QoS) parameter that is associated with a static map. The dialer keyword species that the map is a dialer map. The CALLBACK parameter is a user-dened value (you can name it something other than CALLBACK) that creates a map class to which subsequent encapsulation-specic commands apply. The dialer callback-server username enables the interface to return calls when callback is successfully negotiated. The keyword username species that the interface is to locate the dial string for making the return call. This is done by looking up the authenticated host name in a dialer map command. All phases of PPP must complete successfully. In ppp callback accept, the keyword accept enables the interface to accept the callback requests that come into the interface. The request is considered complete if all phases of PPP are successful. The dialer callback-secure command species the router will disconnect the initial call and callback only if the dialer map is properly dened for callback with a dened class for the remote router. If the dialer callback-secure command is not present, the core router will not drop the connection. The dialer enable-timeout 5 species the interface is to wait ve seconds after disconnecting the initial call before making the return call. The dialer map ip 10.19.241.1 name 804-isdn speed 56 class CALLBACK 14085764740 was modied to include the class keyword and the name of the class, as specied in the map-class command. The keyword name is required so that when the remote user dials in, the interface can locate this dialer map statement in the core router conguration and obtain the dial string for calling back the remote users router. You can nd an example of checking the functionality of the callback feature in Chapter 12, ISDN BRI Troubleshooting.
ISDN Security
ISDN technology provides some limited security features and, as previously mentioned, SS7 Q.931s frame provides caller ID information and the dialed number identication service (DNIS). Based on this information, two security solutions are available:
306
Caller ID screeningBy using the isdn caller interface command, you can dene a set of caller telephone numbers that are eligible to make calls to the router. IOS provides additional features, such as exact match and prex match, where wildcard x can also be used. Unmatched calls are rejected. Called-party number vericationThe router can be congured to verify the called-party number and the subaddress provided by the switch as part of the SETUP message by using one of the following congurations:
804-isdn(config-if)#isdn answer 1 804-isdn(config-if)#isdn answer 2
Conguration commands for the BRI interface enable you to congure the calledparty number, subaddress number, or both. If these numbers are not dened, the router accepts all incoming calls. This feature ensures that for one local loop with multiple ISDN devices, the correct ISDN device accepts and handles the call. For more details, visit Cisco.com.
Conguring the POTS (Telephone) Interfaces

Plain old telephone service (POTS) functionality refers to the use of the voice capabilities of the ISDN routers. The ringer equivalent number (REN) consists of a number and a letter that indicates the frequency response of that telephones ringer. The term telephone port refers to the physical port on the router back panel. The telephone interface refers to a logical interface that you have to congure to make an analog telephone, fax, or modem connected to the router port (phone 1 and 2) work properly as touch-tone devices. The set of conguration commands related to the conguration of the physical ports includes the country, resistance of the line, dialing method, disconnect supervision, encoding, and ringing frequency. Most of the default settings are for the U.S. The rst thing to check in the global conguration mode of the router is who is providing the tones and how the following command is set up: | remote} This command sets who supplies dial, ring back, and busy tones for telephones, fax machines, or modems connected to a Cisco IOS-based ISDN router. The keywords are as follows:
804-isdn(config)# pots tone-source {local
local (by default)Species that the router supplies the tones remoteSpecies that the ISDN switch supplies the tones
Specically for supplying the dial tone, another global conguration command is available with same local and remote options:
804-isdn(config)#pots dial-tone {local
remote}
307
In the global conguration command, another command species the delay after which a telephone port can be rung after a previous call is disconnected:
804-isdn(config)#pots distinctive-ring-guard-time milliseconds
The milliseconds argument is the number of milliseconds of the delay and ranges from 0 to 1000. The default depends on the chosen country. You can connect multiple devices (analog telephones, fax machines, and modems) to a router telephone port. The number you can connect depends on the REN of the telephone port (ve) or the REN of each device that you plan to connect. If you have ve devices and all of them have REN 1, you can connect all of them to the POTS port.
Creating Dial Peers

Dial peers determine the routing of incoming calls to the telephone ports. You can create a total of six dial peers for the two telephone ports. Example 11-9 lists some of the relevant Cisco IOS Software conguration commands.
Example 11-9
A Common Procedure for Dial Peers Conguration

! This command sets up a tag number (1 to 6): 804-isdn(config)#dial-peer voice tag pots ! This command assigns a local directory number: 804-isdn(config-dial-pe)#destination-pattern ldn ! The number of the port is defined using the following command: 804-isdn(config-dial-pe)#port port-number ! The following command disables call waiting (optional): 804-isdn(config-dial-pe)#no call-waiting ! This command (optional) sets a custom ring. Any call coming to that port will ! use that ring. The cadence-number can be 0,1, or 2: 804-isdn(config-dial-pe)#ring cadence-number
The conguration is displayed if you type show dial-peer voice 5, as shown in Example 11-10.
Example 11-10 Displaying the Conguration of dialer-peer 5
804-isdn#show dial-peer voice 5 VoiceEncapPeer5 tag = 5 destination-pattern = 3335555 voice-port = 2 ring cadence = 0 call-waiting disabled forward_to_unused_port disabled
308
The local directory number (LDN) must be associated with a service prole identier (SPID). If you do not assign LDN to both SPIDs, you cannot make voice calls simultaneously. If the dial peers are not created, all voice calls are routed to port 1. To ensure you allow incoming and outgoing voice calls under a BRI interface, congure the following command:
804-isdn(config-if)#isdn incoming-voice modem
The simple congurations enable the basic POTS functionality of the voice portion of ISDN service. There are some advanced features, and their number is continuously changing and growing. Some of them are discussed in the next paragraph.
Advanced Telephone Features

This section provides coverage of some of the more advanced features provided by Cisco IOS Software-based ISND conguration, including the following:
Setting voice priority Enabling supplementary phone services
ISDN Voice Priority

The voice priority feature of IOS handles the data and voice priority. Depending on the user preferences, voice could take precedence over data and vice versa. There are three options:
AlwaysAlways bumps the data call if an outgoing or incoming voice call is initiated. Conditional (by default)Voice call bumps data call only if the user has two data connections in the same direction; otherwise, the calling party receives a busy signal. Never/OffVoice callers always receive a busy signal.
In Cisco 700 series routers, a set of commands handles the process, as displayed in Example 11-11.
Example 11-11 Voice Priority Settings for 77x Router
776-isdn>SET 776-isdn>SET 776-isdn>SET 776-isdn>SET 776-isdn>SET 776-isdn>SET 776-isdn>SET 776-isdn>SET 776-isdn>SET 776-isdn>SET VOICEPRIORITY INCOMING INTERFACE VOICEPRIORITY OUTGOING INTERFACE CALLWAITING INTERFACE PHONE1 ON VOICEPRIORITY INCOMING INTERFACE VOICEPRIORITY OUTGOING INTERFACE CALLWAITING INTERFACE PHONE2 ON CALLTIME VOICE INCOMING OFF CALLTIME VOICE OUTGOING OFF CALLTIME DATA INCOMING OFF CALLTIME DATA OUTGOING OFF PHONE1 CONDITIONAL PHONE1 CONDITIONAL PHONE2 ALWAYS PHONE2 ALWAYS
309
The result of this conguration for a Cisco 700 series router is displayed in Example 11-12.
Example 11-12 Verifying Voice Priority Settings on the 776 Router
776-isdn>show voice Interface VoicePriority In PHONE1 CONDITIONAL PHONE2 ALWAYS DOV N/A UNSPECIFIED N/A VoicePriority Out CONDITIONAL ALWAYS N/A N/A Call Directory Waiting Number ON 5764740 ON 5764741 N/A N/A Ring Cadence
For IOS-based routers, the commands are | out} {always | conditional | off} The pots dialing-method {overlap | enblock} command affects the way you receive a busy signal. With the overlap option, you hear a fast busy signal. With enblock, you initially hear a dial tone followed by a busy signal.
804-isdn#isdn voice-priority ldn {in
If you cannot make the conguration settings work correctly, its possible that the LEC is blocking voice calls, the line was provisioned without additional call offering (ACO), or the router is rejecting voice calls due to an incorrect conguration.
Supplementary Phone Services

Cisco supports some supplementary phone services that are available in Cisco IOS Software. Use of these services is possible, but not mandatory; it depends on the way the line is provisioned. Some of the phone services might include the following, depending on the LEC settings:
Call holding and retrievingBy default, this option is set to **number,number #, but it depends on the LEC settings. Call waitingBy default, it is enabled with no call-waiting. To disable it, enter **number,number#. Three-way call conferencingIf the LEC switch type is NI1 or DMS-100 custom, you can activate this feature by using isdn conference-code range, where range is 0 to 999 and the default is 60. Call transferTo use this feature, you must request it when you order the line. The feature can then be activated with the command isdn transfer-code range, where range is 0 to 999 and the default code is 61. Call forwardingThis feature must also be requested from the LEC when you order the line. There are four ways of forwarding available in Cisco routers: Call forwarding unconditional (CFU) forwards all incoming calls unconditionally to another telephone number.
310
Call forwarding no reply (CFNR) forwards incoming calls that are not answered within a dened period to another telephone number. Call forwarding busy (CFB) forwards incoming calls that get a busy signal to another telephone number. The LEC must provide a number for each forwarding feature such as #number#. Call forwarding variable (CFV) is available only in the U.S. for NI1 ISDN switch types, and can be turned on or off using numbers provided by the LEC.
Summary
This chapter represented, in reasonable details, the different congurations for Cisco 77x and Cisco IOS-based ISDN routers, including spoong, snapshot routing, DDR, and callback solutions. Some security features and voice features congurations are part of this chapter as well. There is another typical common solutionISDN backup, which is explained in the section, Frame Relay and ISDN Backup Conguration in Chapter 16, Basic and Advanced Frame Relay Congurations. The importance of this chapter is related to the so-called expected behavior, or the baseline of the system. It is valuable for the troubleshooting engineer to set up his expectations before starting the troubleshooting process.
Review Questions
1 Type a command to determine if the spoong is enabled in dialer interface in Cisco
IOS ISDN router.

2 Dene the active period in snapshot routing. Is it congurable? What is its duration? 3 In a snapshot routing conguration, use an IOS command to ensure termination of a
quiet period within two minutes.

4 What are the main elements of the dialer proles in DDR? 5 Use an IOS command to map the IP address 161.3.2.1 with the destination phone
number 773-5555.
6 Dene the Dialer1 as a member of pool number 3 with the highest priority. 7 Create an ACL to deny tcp trafc on port 8008. Type the appropriate IOS command. 8 Congure the users IOS router for callback with 200 packets in the queue and 20
seconds drop time. Explain.
Review Questions
311
9 In a callback conguration, type the IOS command, specifying that the core router
interface will wait ve seconds after disconnecting the initial call before making the return call.
10 Type the IOS command to bring the second B channel up after the inbound trafc
exceeds 20 percent.
11 What conditional priority means in voice features conguration of ISDN? 12 If the users router has two data calls in progress and it is congured with
Router(cong)#pots dialing-method enblock, what should you expect when making a voice call to any of his LDNs?
CHAPTER
12
ISDN BRI Troubleshooting

From a technology prospective, most of the ISDN fundamentals are covered in the previous chapters of this part. This chapter provides you with a systematic approach to ISDN troubleshooting and demonstrates the suggested layer-by-layer approach to ISDN problems. The approach requires you to start from the physical layer and go up, layer by layer and protocol by protocol, to identify potential issues. This chapter covers the following common issues:
Troubleshooting the physical layer Troubleshooting the data link layer Troubleshooting the network layer Troubleshooting the Point-to-Point Protocol (PPP), including link control protocol (LCP), authentication, Network Control Protocol (NCP), and the termination of connections Troubleshooting MLP, PPP, callback, and MMP Troubleshooting telephone interfaces
The layer-by-layer approach in Integrated Services Digital Network (ISDN) troubleshooting requires that you start at the physical layer. In the enterprise environment, its best to troubleshoot both ends of the connectionthe remote user side and the core side. Before starting the process, however, you need to ensure that you have basic connectivity to the router. See Chapter 4, Troubleshooting Approaches, Models, and Tools, for tools such as ping and trace. Telnet and SSH are another set of utilities to access the router and some Microsoft Windows-based tools and applications, such as WINIPCFG, IPCONFIG, and HyperTerm.exe can be used also. Most people prefer the console connection. When this is not possbile, just keep in mind that the IOS-based ISDN routers usually are congured for ve simultaneous Telnet sessions, whereas 77x routers allow only one by default. During the troubleshooting process, you might see a signicant amount of activity on the screen. This chapter focuses on showing you how to analyze that output. It is always good to know the exact or relative time of the events. This allows you to recreate the process and understand the chain of events, even if you need to manually set up the clock. One command to remember is service timestamps, which applies a timestamp to your log or debug information. It also provides information about when debug events
314
Chapter 12: ISDN BRI Troubleshooting
occurred, and it indicates the specic time and duration of an event. The service timestamps command has two options: the debug uptime and log datetime msec. The log datetime msec option is the more common of the two options because it logs the date and time in msecs. The following shows the timeservice command options:
804-isdn# configure terminal 804-isdn(config)#service timestamps debug uptime 804-isdn(config)#service timestamps log datetime msec
Another good practice is to turn on and off the following command when you are connected over a Telnet session to the router:
804-isdn#terminal monitor 804-isdn#teminal no monitor
This command enables you to see or not see the debug output on your screen when you have a Telnet session established with the remote router. If you are connected through the console port, use the options of the command 804isdn(cong)#logging console (described in Chapter 4). Another useful command, especially when you are monitoring certain events is logging buffered number debugging. To explain the reason, look to a typical case. The users router intermittently can make calls out in the late evening. Because it is not always possible to monitor the events in the middle of the night, especially when they are intermittent, one good approach is to congure the router with this command and add some issue-related debug commands. In this case, debug dialer is the rst one to consider. Then, the next morning, even if the end user is not available, you can review the events from the previous night with the show logging command. Before entering the layer-by-layer methodology, keep your main objectives in mind. Two things are important to keep in mind during the troubleshooting process of ISDN:
If the router can make outgoing calls If the router can pass data
Start with the rst feature. If the router can make or accept calls, its an indication that the router is functioning properly. Also, this indicates that the D channel is functional between the customer premises equipment (CPE) and the ISDN switch, and Layers 1, 2, and 3 of the D channel are set up correctly. If the router cannot pass data, this mainly concerns encapsulating protocols, such as PPP.
Troubleshooting the Physical Layer

The physical layer involves various components, but your main focus is the local loop wiring and clocking. If you have a physical loop, there is clocking, which refers to both timing and synchronization. It is important to understand whats required by the local exchange carrier (LEC) to provide a local loop to the user. Two wires from the line card in
315
the ISDN switch go to a bundle of pairs in the central ofce (CO) and might split many times into different media, conduits, directions, and multiplexers and/or demultiplexers before nally reaching the eld cabinet closest to the users home. From there, another bundle leads to the users minimum point of entry (MPOE) or single or split Demarcation Point (D-mark), which is usually a box or cabinet outside the house, in the basement, or in any other easily accessible and protected place. This is the D-mark of the providers responsibility. Sometimes, especially in rural or hard-to-reach areas, the LEC uses passive or active repeaters. From the MPOE, the CPE zone starts and includes internal wiring (IW) and outlets, such as RJ-11 and RJ-45 connectors. The set of devices and connectors might vary between homes. To verify the status of the physical layer, it is a good practice to start with the command #show isdn status (see Example 12-1).
Example 12-1
show isdn status Output

804-isdn#show isdn status Global isdn Switchtype = basic-ni ISDN BRI0 interface dsl 0, interface ISDN Switchtype = basic-ni Layer 1 Status: DEACTIVATED Layer 2 Status: Layer 2 NOT Activated
This command gives you a snapshot of all the layers of the ISDN service. If the rst layer is down, the ISDN service is not available. If you are connected to a U interface, the problem is most likely due to the LEC, NT1, or the cable. First, make sure that you are using the proper cable (always check the documentation) from the router to the wall. Look at the front of the router and if the NT1 light is off, the line is down. The same information is provided on the 700 series routers, as shown in Example 12-2.
Example 12-2
show status Output on the 700 Series Routers

776-isdn>show status Status 09/01/2000 09:34:30 Line Status Line DeActivated Terminal Identifier Unassigned Terminal Identifier Unassigned Port Status Ch: 1 Waiting for Call Ch: 2 Waiting for Call
Not Initialized Not Initialized Interface Connection Link
Both routers are reporting Layer 1 Status DEACTIVATED or Line DeActivated. The local loop appears to not be available, not installed correctly, or nonexistent.
316
One possible troubleshooting tool is to check the status of the Basic Rate Interface (BRI) controller of the router. The commands to do this, and the resulting output, are displayed in Example 12-3.
Example 12-3
show controllers bri0 Output

804-isdn#show controllers bri0 BRI unit 0:BRI unit 0 with U interface and POTS: Layer 1 internal state is DEACTIVATED Layer 1 U interface is DEACTIVATED. ISDN Line Information: Current EOC commands: RTN - Return to normal Received overhead bits: AIB=1, UOA=1, SCO=1, DEA=1, ACT=1, M50=1, M51=1, M60=1, FEBE=1 Errors: [FEBE]=0, [NEBE]=41 Errors: [Superframe Sync Loss]=2, [IDL2 Data Transparency Loss]=0 [M4 ACT 1 -> 0]=0,
Both Layer 1 internal state of the BRI controller and the Layer 1 U interface are deactivated. Another important point is to check the status of the Superframe errors. This value always needs to be 0. In this case, the router is reporting 2 Superframe Sync Losses. The next logical step is to determine if the LEC is not providing the service or if your equipment is malfunctioning. One sophisticated IOS debug command is recommended to answer the question:
804-isdn#debug bri
This debug command provides you with information that helps you distinguish between internal and external router problems. This command is the interface between IOS and the ISDN chipset in the router. The output of this command varies between versions of IOS. In some instances, write_sid is sent to the ISDN chipset, which always indicates that the router is trying to bring up the physical layer and set the activation bit (A bit) to 1. At the same time, write_sid instructs the ISDN chipset to generate HDLC ags. Different types of Cisco routers display values such as wrote = E, or wrote = 1B. These values indicate that the ISDN chipset sends HDLC ags. If you cannot see these ags were generated, obviously, you have an internal chipset problem with the router. The sequence of write_sid and wrote=xx, followed by interrupt status reg = C (sent by the chipset to IOS), indicates that the activation bit just turned from 0 to 1. If you type the #show isdn status command again, you see LAYER 1 ACTIVE.1 As previously mentioned, these indicators might vary from one IOS version or device to another. As shown in Example 12-4, the IOS version 12.0 5(T) for Cisco 804 and Cisco 1604, reports the following sequence.
317
Example 12-4
In IOS Version 12.0 5(T), This Is What You See During the Activation of Layer 1
804-isdn#debug bri *Apr 17 03:13:48.567: BRI0: MC145572 IRQ3: NR1=1 *Apr 17 03:13:48.571: BRI0:MC145572 state handler current state 1000 next state 2 ! The MC145572 (chipset) sends NR1=1 to CO *Apr 17 03:13:51.383: BRI0: MC145572 IRQ3: NR1=B *Apr 17 03:13:51.383: BRI0:MC145572 state handler current state 2000 next state 2 ! The MC145572 (chipset) sends NR1=B to CO - second attempt *Apr 17 03:13:51.395: BRI0: MC145572 IRQ2: r6=FFF *Apr 17 03:13:51.399: BRI0:MC145572 state handler current state A001 next state 3 ... *Apr 17 03:13:55.559: BRI0: MC145572 IRQ1: m4 bits=FF ! Request to set the higher bit to 1 - (A=1) *Apr 17 03:13:55.563: BRI0:MC145572 state handler current state A001 next state 3 ... *Apr 17 03:13:55.563: BRI0:M4: received 0xFF - changed bits ACT ! The switch sends confirmation of A=1 and as a result ! the status is set to ACTIVE *Apr 17 03:13:55.975: BRI0: MC145572 IRQ2: r6=F00 *Apr 17 03:13:55.975: BRI0:EOC HOLD
0 actions
2 actions
2 actions
3 actions
Example 12-5 shows the same procedure for IOS 12.1(4) and a 1604 router.
Example 12-5
IOS 12.1(4) and a 1604 Router

1604-isdn#debug bri *Mar 1 01:50:25.629: BRI0:sending C/I AI:Activation Indication ! Sending an activation request *Mar 1 01:50:25.633: BRI(0):ext ST new state 1 *Mar 1 01:50:25.637: BRI(0):C/I to 2081 AR:Activation Request *Mar 1 01:50:25.637: BRI0:Unexpected end of mon received data in state 1 *Mar 1 01:50:25.641: BRI(0):C/I from 2081 AR:Activation Request *Mar 1 01:50:25.645: BRI(0):C/I to 2081 AR:Activation Request ! Activation requests exchanged ... *Mar 1 01:50:31.637: BRI0:S2091 state handler current state 2 actions 1083 next state 3 *Mar 1 01:50:31.637: BRI0:receiving C/I AI:Activation Indication ! Here is the indication from the switch for the A=1 setting line ACTIVE. *Mar 1 01:50:31.641: BRI0:sending C/I AI:Activation Indication *Mar 1 01:50:31.645: BRI(0):C/I to 2081 AR:Activation Request *Mar 1 01:50:31.664: dchan tx start *Mar 1 01:50:31.668: dchan tx intr
Both of the examples distinguish internal from external issues. If the router sends requests to establish the activation bit and a response is not received, the problem is external, such
318
as the cabling, LEC, or NT1. In this case, your recommended action is to open a trouble ticket with your local provider and x the issue. If no request is made from the router, continue to analyze it because the problem might be related to a hardware failure or an IOS bug. One possible solution might be to power-cycle the router in order to force the router to resync with the ISDN switch and reset the BRI U MLT timers (TPULSE and T75S). Usually, the IOS-based timer reset is more typical for the PRIs than BRIs because of the simplicity of the latter. Another possible solution is to clear the D channel with the IOS command #clear interface bri0, which resets the BRI controller. You might want to ush the D channel and see if you can get the D channel to work. The interface BRI0 conguration command is isdn timeout-signaling. If none of these solutions work, consider another CPE. What you are trying to achieve is the activation of the physical layer (Layer 1). The expected result from the #show isdn status command is displayed in Example 12-6.
Example 12-6

804-isdn#show isdn status Global ISDN Switchtype = basic-5ess ISDN BRI0 interface dsl 0, interface ISDN Switchtype = basic-ni Layer 1 Status: ACTIVE ! As you can see the line is reported ACTIVE <output omitted>
In the case of a 77x router, the report is as displayed in Example 12-7.

Example 12-7
show status Output

776-isdn> show status Status 01/05/1995 02:36:52 Line Status Line Activated ! Here the line is reported as a Activated
Typically, to nd out if Layer 1 is active, an engineer checks the status of interfaces. If you apply the same approach here, you see the information displayed in Example 12-8.
Troubleshooting the Data Link Layer
319
Example 12-8
show interfaces bri 0 Output

804-isdn#show interfaces bri 0 BRI0 is up (spoofing), line protocol is up (spoofing) Hardware is BRI with U interface and POTS MTU 1500 bytes, BW 64 Kbit, DLY 20000 usec, reliability 255/255, txload 1/255, rxload 1/255 Encapsulation PPP, loopback not set DTR is pulsed for 1 seconds on reset Last input 00:01:26, output 00:01:26, output hang never <output omitted>
The BRI0 can be up and the line protocol can be spoong, but you wont be able to make calls out. As mentioned in Chapter 11, Cisco ISDN Conguration Solutions, spoong enables the ISDN router to imitate an active state. The ISDN conguration that follows includes spoong. However, DDR becomes active only when interesting trafc triggers a router to place a data call. The status of the D channel is shown in Example 12-9.
Example 12-9
show interfaces bri 0 Output

804-isdn#show interfaces bri 0 BRI0 is up/down, line protocol is up (spoofing/down) Hardware is BRI with U interface and POTS MTU 1500 bytes, BW 64 Kbit, DLY 20000 usec, reliability 255/255, txload 1/255, rxload 1/255 Encapsulation PPP, loopback not set
Spoong does not necessarily mean that the D channel is up and its not an indication of a properly functioning physical layer. In fact, there might be no line on the interface. Spoong just implies to the Layer 3 DDR that the routing entry will be maintained in the router, enabling DDR to wake up and make a call out when interesting trafc requires a network connection.

As previously mentioned, the second layer runs at least two protocolsLink Access Procedure on the D channel (LAPD) and PPP on the B channel. LAPD is also known as Q921; it is the focus of this section. LAPD is used between the Cisco router and the telco switch to provide a full-duplex errorfree link. This protocol is not end-to-end: It can be used only to troubleshoot the connection between the local router (CPE) and the local switch. The troubleshooting of both protocols (LAPD and PPP) must be done separately.
320
NOTE
Always keep in mind that LAPD (Q921) activation needs to occur before PPP because Q921 signaling is part of the D channel signaling. No data with any encapsulation (including PPP) can be passed if the D channel is not functioning properly.
Using the #show isdn status command immediately after Layer 1 activation displays the output shown in Example 12-10.
Example 12-10 show isdn status Output
804-isdn#show isdn status Global ISDN Switchtype = basic-ni ISDN BRI0 interface dsl 0, interface ISDN Switchtype = basic-ni Layer 1 Status: ACTIVATED Layer 2 Status: Layer 2 NOT Activated
An important part of the second layer activation is the negotiation of the terminal endpoint identier (TEI). In the BRI environment on a single S/T connection, a single BRI interface can connect up to 8 devices. Each device can have a unique TEI number thats assigned by the local switch. The switch recognizes the devices that are sending and receiving data, and negotiation starts with the router, which sends IDREQ. The switch responds with IDASSN. The IDREQ and IDASSN packets contain two important valuesthe activation indicator (AI) and the reference indicator (RI). The initial IDREQ sent to the switch is set to 127. This is a broadcast request that asks the switch to assign any TEI. Unlike Primary Rate Interfaces (PRIs), where only one device is connected to the switch and the TEI is always 0, the valid TEI for BRIs is between 64 and 126 (if they are dynamically assigned). The range from 0 to 63 is allocated for xed or statically assigned TEIs. The RI in the IDREQ packet is a random number that needs to always match an associated IDREQ and IDASSN packet. In Example 12-11, the router sends IDREQ with ri = 86 and broadcast ai = 127. The switch responds with the matching IDASSN ri = 86, and assigns ai = 80, which is a valid TEI. Further down in the output, you can see another IDREQ and IDASSN with ri = 1463 and assigned TEI = 89. Example 12-11 shows the recommended command for troubleshooting and the initialization of Layer 2.
Example 12-11 Activation of Layer 2 in a Cisco 804 ISDN Router
804-isdn#debug isdn q921 *Mar 1 00:01:14.995: ISDN BR0: TX -> *Mar 1 00:01:15.019: ISDN BR0: RX <*Mar 1 00:01:15.027: ISDN BR0: TX -> ! The following line and the preceding *Mar 1 00:01:15.043: ISDN BR0: RX <IDREQ ri = 86 ai = 127 ID request IDASSN ri = 86 ai = 80 ID assign SABMEp sapi = 0 tei = 80 line mean LAPD is OK for TEI=80 UAf sapi = 0 tei = 80
321
Example 12-11 Activation of Layer 2 in a Cisco 804 ISDN Router (Continued)

*Mar 1 00:01:15.047: %ISDN-6-LAYER2UP: Layer 2 for Interface BR0, TEI 80 changed to up *Mar 1 00:01:15.051: ISDN BR0: TX -> INFOc sapi = 0 tei = 80 ns nr = 0 i = 0x08007B3A0E3430383537363437343030313031 ! Layer 3 exchange *Mar 1 00:01:15.091: ISDN BR0: RX <- RRr sapi = 0 tei = 80 nr = *Mar 1 00:01:15.095: ISDN BR0: TX -> INFOc sapi = 0 tei = 80 ns nr = 0 i = 0x08010105040288901801832C0B3138303037373335303438 *Mar 1 00:01:15.139: ISDN BR0: RX <- INFOc sapi = 0 tei = 80 ns nr = 1 i = 0x08007B3B028081 *Mar 1 00:01:15.147: ISDN BR0: RX <- RRr sapi = 0 tei = 80 nr = *Mar 1 00:01:15.151: ISDN BR0: TX -> RRr sapi = 0 tei = 80 nr = *Mar 1 00:01:15.167: ISDN BR0: TX -> IDREQ ri = 1463 ai = 127 ! TEI request *Mar 1 00:01:15.175: ISDN BR0: RX <- INFOc sapi = 0 tei = 80 ns nr = 2 i = 0x08007B952A0480800150 *Mar 1 00:01:15.187: ISDN BR0: TX -> RRr sapi = 0 tei = 80 nr = *Mar 1 00:01:15.191: ISDN BR0: RX <- IDASSN ri = 1463 ai = 89 ! TEI assign *Mar 1 00:01:15.199: ISDN BR0: TX -> SABMEp sapi = 0 tei = 89 *Mar 1 00:01:15.219: ISDN BR0: RX <- UAf sapi = 0 tei = 89 ! The following line and the preceding line mean 89 OK *Mar 1 00:01:15.219: %ISDN-6-LAYER2UP: Layer 2 for Interface BR0, TEI 89 changed to up *Mar 1 00:01:15.227: ISDN BR0: TX -> INFOc sapi = 0 tei = 89 ns nr = 0 i = 0x08007B3A0E3430383537363437343130313031 ! Layer 3 *Mar 1 00:01:15.267: ISDN BR0: RX <- RRr sapi = 0 tei = 89 nr = *Mar 1 00:01:15.279: ISDN BR0: RX <- INFOc sapi = 0 tei = 89 ns nr = 1 i = 0x08007B3B028181 *Mar 1 00:01:15.287: ISDN BR0: TX -> RRr sapi = 0 tei = 89 nr = *Mar 1 00:01:15.311: ISDN BR0: RX <- INFOc sapi = 0 tei = 89 ns nr = 1 i = 0x08007B952A0480800150 *Mar 1 00:01:15.323: ISDN BR0: TX -> RRr sapi = 0 tei = 89 nr = *Mar 1 00:01:15.739: ISDN BR0: RX <- INFOc sapi = 0 tei = 80 ns nr = 2 i = 0x08018102180189 *Mar 1 00:01:15.747: ISDN BR0: TX -> RRr sapi = 0 tei = 80 nr = *Mar 1 00:01:17.039: ISDN BR0: RX <- INFOc sapi = 0 tei = 80 ns nr = 2 i = 0x08018107 *Mar 1 00:01:17.043: ISDN BR0: TX -> RRr sapi = 0 tei = 80 nr = *Mar 1 00:01:17.051: ISDN BR0: TX -> INFOc sapi = 0 tei = 80 ns nr = 4 i = 0x0801010F
= 0
1 = 1 = 0 2 1
= 1 2
= 0
1 = 0 1 = 1 2 = 2 3 = 3 4 = 2
If negotiation of Layer 2 doesnt occur, IDREQ is transmitted with different random RI and wildcard ri = 127, but you wont see an IDASSN. This indicates that the switch is not responding. Another problem scenario is an invalid TEI from the switch, which can indicate an LEC issuepossibly a malfunctioning switch.
322
The following message types can be checked during TEI identication:
ID Request ID Assigned ID Denied ID Check Request ID Check Response ID Remove ID Verify
The only way to change or remove the TEI assigned to the routers BRI interface is to reload the router. Then, the boot code forces the rst ISDN TEI rst-call ag to be reset. The rst call ag affects all switch types, thus forcing incoming and outgoing calls to activate the BRI interface. To enable the router to negotiate the TEI on the rst call, use the following conguration command:
804-isdn(config)#isdn tei-negotiation first-call
NOTE
Some European ISPs remove the TEI assignment during night hours. Then, the user who has a functioning connection during the day cannot make calls out and must power-cycle the router to make it operational during the day. This command is particularly useful for these cases because it allows the TEIs to be re-established during the rst call out.
The next step in the activation of Layer 2 is the HDLC connection with the switch. The router sends an asynchronous balance mode extended (SABME) message with TEI xx (in the example, its 73). In response to SABME, the local switch responds with a series of unnumbered acknowledgments (UAs). At this point, Layer 2 is ACTIVE. If you enter #show isdn status, you can see the second layer reported as ACTIVATED.
NOTE
Under normal circumstances, you should not see SABME messages. If you do see them, it is a clear indication that Layer 2 is trying to reinitialize. This is usually seen when transmitting poll requests (RRp) and not receiving a response from the switch (RRf), or vice versa.
After Layer 2 is activated, a sign of normal exchange is the exchange of INFO frames between the router and the local switch. Responses for the INFO messages are RR frames, as shown in Example 12-12.
323
Example 12-12 debug isdn q921 Output

804-isdn#debug isdn q921 *Mar 3 23:59:04.788: ISDN BR0: RX <*Mar 3 23:59:11.736: ISDN BR0: TX -> *Mar 3 23:59:11.752: ISDN BR0: RX <INFOc sapi = 0 tei = 80 ns=0 nr = 1 RRp sapi = 0 tei = 80 nr = 1 INFOc sapi = 0 tei =80 ns=0 nr = 1
NOTE
Under normal circumstances, you should not see the exchange of any negotiation messages, such as IDREQ or IDASSN, but you should see the exchange shown in the previous output. Also, note that a PRI always uses a Terminal Endpoint Identier (TEI) of zero because the link is point-to-point only. A TEI uniquely identies multiple clients on an ISDN bus, which is a BRI.
The INFO frames contain Q931 signaling information and they exchange NS (send sequence number) and NR (next expected sequence number) elds. It is similar to the myseen and yourseen messages on the serial lines. To understand this analogy, look at the idle BRI channel (no user data is exchanged) and you can see a keepalive mechanism, which is when both parties exchange RR frames every 10 to 30 seconds, depending on settings, as shown in Example 12-13.
Example 12-13 Keepalive Mechanism in debug isdn q921 Output
804-isdn#debug isdn q921 *Mar 4 00:39:11.671: ISDN *Mar 4 00:39:11.687: ISDN *Mar 4 00:39:19.675: ISDN *Mar 4 00:39:19.691: ISDN BR0: BR0: BR0: BR0: TX RX TX RX -> <-> <RRp RRf RRp RRf sapi sapi sapi sapi = = = = 0 0 0 0 tei tei tei tei = = = = 80 nr = 44 80 nr = 1 89 nr = 60 89 nr = 24
In active second-layer environments, you can see the messages in Example 12-13. They allow you to conclude that Layer 2 is functioning properly. The nal result of the successful establishment of the second layer is shown in Example 12-14s output.
Example 12-14 The Successful Establishment of the Second Layer
804-isdn#show isdn status Global ISDN Switchtype = basic-ni ISDN BRI0 interface dsl 0, interface ISDN Switchtype = basic-ni Layer 1 Status: ACTIVE Layer 2 Status: TEI = 64, Ces = 1, SAPI = 0, State = MULTIPLE_FRAME_ESTABLISHED TEI = 73, Ces = 2, SAPI = 0, State = MULTIPLE_FRAME_ESTABLISHED
continues
324
Example 12-14 The Successful Establishment of the Second Layer (Continued)

Spid Status: TEI 64, ces = 1, state = 5(init) spid1 configured, spid1 sent, spid1 valid Endpoint ID Info: epsf = 0, usid = 0, tid = 1 TEI 73, ces = 2, state = 5(init) spid2 configured, spid2 sent, spid2 valid Endpoint ID Info: epsf = 0, usid = 1, tid = 1,
In terms of a Cisco 77x series router, the expected output is displayed in Example 12-15.
Example 12-15 Cisco 77x Series Router Output
776-isdn> show status Status 01/03/1995 05:30:24 Line Status Line Activated Terminal Identifier Assigned Terminal Identifier Assigned Port Status Ch: 1 Waiting for Call Ch: 2 Waiting for Call
SPID Accepted SPID Accepted Interface Connection Link
NOTE
The output of an IOS command for the second layer must have TEIs in the expected range, SAPI = 0, and State = MULTIPLE_FRAME_ESTABLISHED for each B channel. If only one B channel has the MULTIPLE_FRAME_ESPABLISHED state, ISDN is still operational, but it will only have use of that channel.
After the rst and second layers on the D channel are established, you can approach Layer 3. Troubleshooting this layer should be attempted only after you verify that Layer 1 and Layer 2 are active.
Troubleshooting the Network Layer

The third layer protocol on the D channel, or Q.931 messaging, controls connections between various nodes on an ISDN network. These messages contain call setup, call clearing, and various status messaging. The rst Layer 3 activity occurs when the router sends the service prole identier (SPID) to the switch. Q.931 includes numerous options. You must ensure that you congure the exact type of switch and protocol. Many cases arise when the LEC uses 5ESS or DMS-100, and runs NI-1 protocol. There are other cases when DMS-100 is emulating 4ESS or 5ESS
325
using different proles. Q.931 has 37 different types of call setups. The SPIDs bind a specic TEI to a specic service prole. If you receive an Invalid IE contents or SPID.x rejected message, that means the handshake procedure between the local switch and the CPE was unsuccessful and the SPID was rejected (see Example 12-16).
Example 12-16 Handshake Procedure Between the Local Switch and the CPE Was Unsuccessful and the SPID Was
Rejected
804-isdn#debug isdn q931 *Mar 1 00:01:10.881: %ISDN-6-LAYER2UP: Layer 2 for Interface BR0, TEI 112 changed to up *Mar 1 00:01:10.885: ISDN BR0: TX -> INFORMATION pd = 8 callref = SPID Information i = 40857647400101 *Mar 1 00:01:10.925: ISDN BR0: RX <- INFORMATION pd = 8 callref = ENDPOINT Ident i = 0x8081 *Mar 1 00:01:10.933: ISDN BR0: Received EndPoint ID *Mar 1 00:01:10.953: ISDN BR0: RX <- INFORMATION pd = 8 callref = Locking Shift to Codeset 5 *Mar 1 00:01:10.957: Codeset 5 IE 0x2A i = 0x808001, P *Mar 1 00:01:10.985: %ISDN-6-LAYER2UP: Layer 2 for Interface BR0, TEI 65 changed to up *Mar 1 00:01:10.989: ISDN BR0: TX -> INFORMATION pd = 8 callref = SPID Information i = 40857647440101 *Mar 1 00:01:11.045: ISDN BR0: RX <- INFORMATION pd = 8 callref = Cause i = 0x82E43A Invalid IE contents *Mar 1 00:01:11.053: %ISDN-4-INVALID_SPID: Interface BR0, Spid2 was
(null) (null)
(null)
(null) (null) rejected
The negotiation begins with sending the rst SPID information. The SPID information can be in clear text, such as SPID Information i = 40857647400101, for IOS 12.0+, or in ASCII code, such as i = 3631234234545342, for older versions of IOS. The pd is the protocol descriptor. Another part of the setting is the local directory number (LDN), which is congured to receive incoming calls. If LDN is not congured on telcos switch, which is because either the switch does not support the voice feature or the ISDN service is not provisioned for voice, the router cannot receive voice calls. In the following examples, you can see the status of the ISDN layers after the second SPID is rejected. Example 12-17 shows the result from the unsuccessful SPID2 negotiation in 776 routers.
Example 12-17 Examples of SPID Negotiation in 776 Routers
776-isdn> 01/01/1995 00:00:26 L19 1 Terminal Identifier Unassigned 776-isdn> 01/01/1995 00:00:26 L19 2 Terminal Identifier Unassigned 776-isdn> 01/01/1995 00:00:26 L12 0 Disconnected Remotely 776-isdn> 01/01/1995 00:00:26 L18 1 Terminal Identifier Assigned 776-isdn> 01/01/1995 00:00:26 L22 1
continues
326
Example 12-17 Examples of SPID Negotiation in 776 Routers (Continued)

40857647400101 Sending SPID 776-isdn> 01/01/1995 00:00:26 L27 0 Disconnected 776-isdn> 01/01/1995 00:00:27 L18 2 Terminal Identifier Assigned 776-isdn> 01/01/1995 00:00:27 L23 1 40857647400101 SPID Accepted 776-isdn> 01/01/1995 00:00:27 L22 2 4085764744 Sending SPID 776-isdn> 01/01/1995 00:00:27 L24 2 SPID Rejected Cause 100 Invalid Information Element Contents
Finally, in terms of 77x router, Example 12-18 shows the status of the ISDN service, including Layer 3s status.
Example 12-18 The Status of the ISDN Service, Including Layer 3s Status
776-isdn> show status Status 09/01/2000 11:00:28 Line Status Line Activated Terminal Identifier Assigned Terminal Identifier Assigned Port Status Ch: 1 Waiting for Call Ch: 2 Waiting for Call 776-isdn>
SPID Accepted SPID Rejected Interface Connection Link
In terms of IOS, the same information about all layers, including Layer 3, is displayed in Example 12-19.
Example 12-19 show isdn status Output
804-isdn#show isdn status Global ISDN Switchtype = basic-ni ISDN BRI0 interface dsl 0, interface ISDN Switchtype = basic-ni Layer 1 Status: ACTIVE Layer 2 Status: TEI = 112, Ces = 1, SAPI = 0, State = MULTIPLE_FRAME_ESTABLISHED TEI = 65, Ces = 2, SAPI = 0, State = MULTIPLE_FRAME_ESTABLISHED Spid Status: TEI 112, ces = 1, state = 5(init) spid1 configured, spid1 sent, spid1 valid Endpoint ID Info: epsf = 0, usid = 0, tid = 1 TEI 65, ces = 2, state = 6(not initialized) spid2 configured, spid2 sent, spid2 NOT valid
327
At this point, it is a good idea to carefully review the provisioning information and, if this does not help, work with the service provider to resolve the SPID2 issue. So far, the information about Layer 3 in this section was about establishing the Layer 3 functionality. The following discussion is about the dynamics of the ISDN Layer 3, which is developed to handle the ISDN calls. First and foremost of course, you have to make sure that the router can make calls out. This can be done in two ways:
Generate interesting trafc to force the router to make a call Make a manual call out
To generate interesting trafc, you must connect a computer to the router and run an application or open a browser, which is usually congured to be interesting trafc for the router. Its much simpler to generate a manual call, especially when you are troubleshooting remotely, as follows:
For 77x routers, to make a data call from the rst channel, you type the following:
776-isdn> call 1 18007735555
For IOS ISDN routers, type the following:

804-isdn#isdn call interface bri0:1 18007735555
Another easy way to test the D channel functionality is to use the voice channels on the premise that the ISDN service is provisioned for voice and data. If this is the case, you can work with the remote user to connect a regular phone to the voice ports of the router and try to make a local or long-distance voice call. If theres a dial tone and the user can make calls out at all, the D channel is working properly. If not, you need more detailed troubleshooting. As previously mentioned, two types of protocols are running on Layer 3:
D channel protocols Q.931 and Q.932 (optional) Routed protocols such as IP, IPX, and AT and all the overhead of routing protocols
No denition of the Layer 2 B channel protocol is in the ISDN standard, but PPP or HDLC (by default) can be used. Q.931 denes a series of messages including the following: SETUP CONNECT RELEASE USER INFORMATION CANCEL STATUS CALL_PROC DISCONNECT
328
The router informs the switch that it wants to make a call. The switch transforms the Q.931 messages to SS7 and places a call to the remote switch. The remote switch translates the call to Q.931 signals and calls the remote router. Q.931 is not an end-to-end protocol, but in terms of troubleshooting, its more convenient to consider Q.931 as an end-to-end protocol, especially when the ISDN network belongs to a single provider. Layer 2 INFO frames transmit all Q.931 signals and, when the router places a data call, it sends a packet. The setup packet always has a protocol descriptor of pd = 8 and generates a random hex value for the call referencecallref=0x08. The callref is important when troubleshooting with the local or long-distance LEC because the carriers see the same callref and can easily track the call and its history. Also, from the handshaking of transmit (TX->) and receive (RX<-) messages, you can see what call is related to what user. In Example 12-20, you can see the call setup procedure.
Example 12-20 The Call Setup Procedure
804-isdn#debug isdn q931 *Mar 4 08:12:28.506: ISDN BR0: TX -> SETUP pd = 8 callref = 0x08 *Mar 4 08:12:28.510: Bearer Capability i = 0x8890 *Mar 4 08:12:28.510: Channel ID i = 0x83 *Mar 4 08:12:28.514: Keypad Facility i = 18007735555 *Mar 4 08:12:29.646: ISDN BR0: RX <- CALL_PROC pd = 8 callref = 0x88 *Mar 4 08:12:29.650: Channel ID i = 0x8A *Mar 4 08:12:31.930: ISDN BR0: RX <- CONNECT pd = 8 callref = 0x88 *Mar 4 08:12:31.938: ISDN BR0: TX -> CONNECT_ACK pd = 8 callref = 0x08 *Mar 4 08:12:31.942: %LINK-3-UPDOWN: Interface BRI0:2, changed state to up *Mar 4 08:12:31.958: %DIALER-6-BIND: Interface BRI0:2 bound to profile Dialer1 *Mar 4 08:12:31.958: %ISDN-6-CONNECT: Interface BRI0:1 is now connected to 18007735555 gateway
To assist with understanding the output from the router, refer to the format of Q.931 in Figure 9-7. From call information of pd = 8 and callref = 0xXX, you can trace the call history and see STATUS pd = 8, DISCONNECT pd = 8, and RELEASE pd = 8. A piece of important information is the Bearer Capability i = 8890, which indicates a 64-kbps data call. The 0x8890218F means it is a 56-kbps data call and the 0x8090A2 means that its a voice call. Channel ID i = 0x83 is a request from the router to the switch to assign an idle B channel. If the request is not allowed, you can see isdn_is_bchannel_available: No Free B-channels, which indicates a capacity issue or congestion in the LECs network. Keypad facility i = 18007735555 is the number called by the router. If it is an incoming call and the line is provisioned so the LEC provides caller_ID (Q.932), you see Called Party Number i=0x88 5764740. CALL_PROC , which indicates that the call is proceeding. To differentiate between TX and RX, callref uses different values for the rst digit after the 0x. (0x indicates a hexadecimal value.) Although the second digit is the same for the TX and RX values 0x88 and 0x08, the rst digit is different. This fact allows you to differentiate the callref if it is a TX or RX message. Channel ID i = 89 indicates the rst channel, and
329
the second channel is indicated as Channel ID i = 8A. The last stage is CONNECT, when the LEC assigns an idle B-channel to the router, and the router receives the following: ISDN BR0: RX <- CONNECT pd = 8 callref = 0x88, with calref = 0x88. The router responds to the same callref = 0x08 with acknowledgment: ISDN BR0: TX -> CONNECT_ACK pd = 8 callref = 0x08. If the call is unsuccessful, the order of the messages is different. If the router places a data call, you might see this message: ISDN BR0: TX -> SETUP pd = 8 callref = 0x08. Later in the Q.931 input, you might see a message RX<- RELEASE_COMP pd = 8 callref = 82. The RELEASE_COMP message is a clear indication that the call is refused.
NOTE
Sometimes, the TX-> release message and RX<- RELEASE_COMP messages can be misleading. The CPE tends to not understand that the call is terminated.
The provided approach for troubleshooting the functionality of the D channel is benecial when working with the service provider because the Cisco router provides for you the same visibility given to your provider about the details of Q.931 signaling. The simpler, but still recommended, approach to the D channel functionality is as follows, using another set of IOS debug commands, such as #debug dialer:
804-isdn#debug dialer ? events Dial on demand events packets Dial on demand traffic
In this command, you have two options: to debug the events or the trafc. It is recommended to turn the debug on and to make a data call out, generating interesting trafc. In Example 12-21, you see output from the command when you are debugging trafc and access list 101 denes the interesting trafc.
Example 12-21 debug dialer packets Output
804-isdn#debug dialer packets Mar 3 10:06:46.815: Dialer1 DDR: ip (s=10.19.250.248, d=10.19.92.149), 41 bytes, outgoing interesting (list 101) Mar 3 10:06:47.055: Dialer1 DDR: ip (s=10.19.250.248, d=10.19.92.149), 596 bytes, outgoing interesting (list 101)
The output displays the interesting trafc triggering the call, including the source and destination of the information and the TCP port, as well as the number of bytes and the ACL number. Similar information can be seen in Example 12-22 for a 770 series router, with the Software Version c760-in.r.US 4.4(2).
330
Example 12-22 show packets Output

776-isdn:gateway> show packets Packet Statistics for Connection 3 Filtered: 0 Forwarded: 9869 Received: 10773 Dropped: 373 Lost: 27 Corrupted: 0 Misordered: 30 Compression Ratio: 2.38:1 IP Packet that triggered last call Source Address: 10.0.0.1 Destination Address: 10.19.92.149 Protocol: TCP Source Port: 23 Destination Port: 3649,
For IOS-based ISDN routers, if you want to track the dialer events, use the alternative displayed in Example 12-23.
Example 12-23 debug dialer events Output
804-isdn#debug dialer events *Mar 3 10:02:07.699: BRI0 DDR: rotor dialout [priority] *Mar 3 10:02:07.699: BRI0 DDR: Attempting to dial 18007735555 *Mar 3 10:02:10.643: %LINK-3-UPDOWN: Interface BRI0:2, changed state to up *Mar 3 10:02:10.659: %DIALER-6-BIND: Interface BRI0:2 bound to profile Dialer1 *Mar 3 10:02:10.663: %ISDN-6-CONNECT: Interface BRI0:1 is now connected to 18007735555 gateway *Mar 3 10:02:10.667: isdn_call_connect: Calling lineaction of BRI0:2 *Mar 3 10:02:12.511: %LINEPROTO-5-UPDOWN: Line protocol on Interface BRI0:2, changed state to up!!!!!!! *Mar 3 10:02:16.663: %ISDN-6-CONNECT: Interface BRI0:1 is now connected to 18007735555 gateway!! Success rate is 100 percent (100/100), round-trip min/avg/max = 532/617/992 ms
Although the encapsulation discussion appears later in this chapter, it is important to distinguish between calls when they always fail (a Q.931 issue) and calls that might connect for a period of time and then disconnect due to a PPP issue. This is shown in Example 1224 for a 700 series router, where the rst channel has difculties operating the PPP protocol.
Example 12-24 show status Output
776-isdn>show status Status 09/01/2000 09:34:30 Line Status Line Activated Terminal Identifier Assigned Terminal Identifier Assigned Port Status Interface Ch: 1 64K Call In Progress Ch: 2 64K Call In Progress
SPID Accepted SPID Accepted Connection 18007735555 18007735555
Link DATA DATA
0 3
0 1
331
From the previous output, the rst channel drops because the PPP negotiation (LCP phase) is unsuccessful. In the Q.931 output, you see the reason for the call rejection and the following output messages: RX<- RELEASE_COMP pd = 8 callref = 82 and Cause i = 0x8295 Call Rejected. The cause for the rejection is i = 0x8295, and the assigned number (8295) is the hex value of this message. Usually, the messages from the switch are short decimal values. A brief description of some of the most common decimal values of Q.931, their description and possible cause, received from the NI-1 ISDN switch for 77x routers are provided in Table 12-1.
Table 12-1 77x ISDN BRI Cause Messages Received from the NI-1 ISDN Switch Decimal Value Description Cause Messages
Normal Events 1 Unassigned number The ISDN number was sent to the switch in the correct format, but the number is not assigned to any destination equipment. The ISDN exchange routed the call through an unrecognized intermediate network. The call was routed through an intermediate network that does not serve the destination address. The service quality of the specied channel is insufcient to accept the connection. The user was assigned an incoming call that was connected to an already established call channel. Normal call clearing occurred. The called system acknowledges the connection request, but is unable to accept the call because all B channels are in use. The connection cannot be completed because the destination does not respond to the call. The destination responds to the connection request, but fails to complete the connection within the prescribed time. The problem is at the remote end of the connection. The destination is capable of accepting the call, but rejected the call for an unknown reason. The ISDN number used to set up the call is not assigned to any BRI. Perhaps an alternate address is assigned to the called equipment.
2 3
No route to the specic transit network No route to the destination
6 7 16 17
Channel unacceptable Call awarded and delivered Normal clearing User busy; BUSY
18 19
No user responding; NO RESPONSE No answer from user (user alerted); NO ANSWER
21 22
Call rejected Number changed
continues
332
Table 12-1
77x ISDN BRI Cause Messages Received from the NI-1 ISDN Switch (Continued) Decimal Value 26 Description Non-selected user clearing Cause Messages The destination is capable of accepting the call, but rejected the call because it was not assigned to the user. The destination cannot be reached because the interface is not functioning correctly, and a signaling message cannot be delivered. The connection cannot be established because the destination address was presented in an unrecognizable format. The network cannot provide the facility requested by the user. The status message is generated in direct response to the prior receipt of a status enquiry message. Reports the occurrence of a normal event when no standard cause applies. No action required.
27
Destination out of order
28
Invalid number format (incomplete number) Requested facility rejected Response to STATUS Enquiry Normal, unspecied
29 30 31
Network Congestion 34 35 38 41 42 43 44 No circuit/channel available Call queued Network out of order Temporary failure Network congestion Access information discarded Requested circuit/channel not available No appropriate channel/circuit is available to take the call. The call is waiting to be performed. The destination cannot be reached because the network is not functioning correctly. The network is temporarily not functioning correctly. The network switch is temporarily overloaded. The network cannot provide the requested access information. The remote equipment cannot provide the requested channel for an unknown reason. It might be temporary.
Service or Option Not Available 47 49 50 Resources unavailable, unspecied Quality of service unavailable Requested facility not subscribed The requested channel or service is unavailable for an unknown reason. QoS is not available. This could be a subscription problem. The remote equipment supports the requested supplementary service, but only by subscription.
333
Table 12-1
77x ISDN BRI Cause Messages Received from the NI-1 ISDN Switch (Continued) Decimal Value 52 54 57 58 63 Description Outgoing calls barred Incoming calls barred Bearer capability not authorized Bearer capability not presently available Service or option not available Cause Messages The outgoing calls are blocked in the conguration. The incoming calls are blocked in the conguration. The user requested bearer capability but is not subscribed to use it. The requested bearer capability is not currently available. The network or remote equipment cannot provide the requested option for an unspecied reason.
Service or Option Not Provisioned or Implemented 65 66 69 70 79 Bearer service not implemented Channel type not implemented Requested facility not implemented Only restricted digital information bearer is available Service or option not implemented, unspecied The network cannot support the requested bearer capability. The network or the destination equipment does not support the requested channel type. The remote site does not support the requested supplementary service. The network is unable to provide unrestricted digital bearer capability. The service or option cannot be provided for an unspecied reason.
Invalid Messages 81 Invalid call reference value The remote equipment received a call with a call reference that is not currently in use on the usernetwork interface. The receiving equipment requested to use a channel that is not activated for calls on the interface. The network received a call resume request. It contains call identity information that indicates the call identity is being used for a suspended call. The network received a call resume request, containing call identity information that indicates it is in use for a suspended call. The network received a call resume request, when there was not a suspended call pending.
82 83
Identied channel does not exist A suspended call exists but this call identity does not Call identity is use
84
85
No call suspended
continues
334
Table 12-1
77x ISDN BRI Cause Messages Received from the NI-1 ISDN Switch (Continued) Decimal Value 86 Description Call that requested call identity has been cleared Cause Messages The network received a call resume request. It contains call identity information that identies the suspended call and then clears the call either by timeout or by the remote user. Indicates an attempt to connect to non-ISDN equipment (an analog line). The ISDN exchange was asked to route the call through an unrecognized intermediate network. An invalid message was received, and no standard cause applies. This is usually due to a D channel error.
88 91
Incompatible destination Transit network does not exist/Invalid transit network specied Invalid message, unspecied
95
Protocol and Internetwork Errors 96 97 Mandatory information element is missing Message type non-existent or not implemented This is a D channel error because the Q.931 element is missing. A D channel error where either the message received is invalid or is valid but not supported. Error 97 is either a remote equipment error or a D channel error. A D channel error where the remote side receives an invalid message or no standard cause applies. A D channel error where the remote side receives an information element that cannot be recognized. A D channel error due to invalid information received in the information element. A D channel error where the remote equipment receives an unexpected message that does not correspond to the current state of the connection. An error-handling (recovery) procedure was initiated by a timer expiry. The network signals a protocol error and the precise cause is not known. The network signals a protocol error and the precise cause is not known. The error is registered, but the cause and reason are unknown.
98
Message not compatible with call state or message type non-existent Information element nonexistent or not implemented. Invalid information element contents Message not compatible with call state Recovery on timer expiry Protocol error, unspecied Internetworking, unspecied Cause nnn/ Unknown or local error
99
100 101
102 111 127 ALL others/ UNKNOWN
Troubleshooting PPP
335
As previously mentioned, your second objective is ensuring that the router can pass data. This feature is closely and mainly related to the following discussion about encapsulation options, PPP protocol suite, and its phases.
Troubleshooting PPP
PPP provides a standard method for transporting multiprotocol packets over point-to-point links. Regardless of the PPP denition as a rst- and second-layer protocol, for practical purposes, it is more convenient to consider PPP as a third-layer protocol, because the Q.931 negotiation must happen before PPP starts. It is easy to think about ISDN and PPP protocols as a pyramid. For troubleshooting purposes, its easier to consider the PPP protocol as having four phases: LCP negotiation, authentication, NCP, and termination. As discussed in Chapter 5, Dial Technology Background, PPP encapsulates the data over the B channels. Most of the information about PPP settings can be seen in the PPP negotiation process, where the protocol eld indicates the upper-layer protocols carried in the information eld. Some of the examples of protocol eld values are
0x0021IP 0x0029AT 0x002BIPX 0x003DMultilink 0x0201802.1d hellos 0x8021IPCP 0x8029ATCP 0x802BIPXCP 0xC021LCP 0xC023PAP 0xC025LQR (link quality report) 0xC223CHAP
After assessing that the line is active, the next phase of PPP is the Link Establishment Phase, which is controlled by link control protocol (LCP).
Troubleshooting PPP LCP

PPP LCP provides a method of establishing, conguring, maintaining, and terminating the point-to-point connections. LCP goes through four distinct phases:
Link establishment and conguration negotiation Link-quality determination
336
Network-layer protocol conguration negotiation Link termination
First, link establishment and conguration negotiation occurs before any network layer datagrams (IP, AT, and IPX) are exchanged. LCP rst opens the connection and negotiates conguration parameters. At this point, the Layer 2 framing is Layer 2 Generic HDLC. This phase is complete when a conguration-acknowledgment frame is both sent and received. The following parameters and options can be negotiated:
Maximum Receive/Transmit Unit (MRU/MTU)The default is 1500 bytes. Async Control Character MapThe control and escape characters on async links. Authentication protocolPAP (0xC023) or CHAP (0xC223). Quality protocolThe process for data-link monitoring. Magic-NumberThe technique to detect loopbacks. MRRUThe maximum received reconstructed unit. ReservedIt is reserved for future use. Protocol Field CompressionCompression of the PPP protocol eld. Address and Control Field CompressionCompression of the PPP address and control eld.
The link-establishment and conguration-negotiation phase is followed by link-quality determination, which is an optional phase. In this phase, the link is tested to determine whether the quality is sufcient to bring up the network-layer protocols. LCP can delay transmission of network-layer protocol information until this phase is complete. Next, network layer protocol conguration negotiation occurs. After LCP nishes the linkquality determination, network-layer protocols can be congured separately by the appropriate NCP and can be brought up and taken down any time. If LCP closes the link, it informs the network-layer protocols so they can take appropriate action. At this point, PPP framing is being used. Finally, link termination occurs. LCP can terminate the link at any time and it usually is done at the request of a user, but can happen because of a physical event, such as the loss of the carrier or the expiration of the idle-period timer. Three classes of LCP frames exist: link-establishment frames are used to establish and congure the link; link-termination frames are used to terminate a link; and link-maintenance frames are used to manage and debug a link. For practical purposes, it is better to know the order of the phases. For the Cisco remote access environment, the right procedure is as follows:
1 Q.931 places a data call. 2 The connection is successful. 3 LCP PPP starts and establishes the connection parameters. 4 One- or two-way authentication occurs. 5 The virtual interface is created.
Troubleshooting PPP
337
6 The number of the virtual interface (Vix) is assigned. 7 The bundles for IP, CP, and CDP are built. 8 Data transfer occurs.
The sequence is reversed to terminate the call. During the LCP negotiations, the O CONFREQ proposes certain options. If all options are acceptable, the remote party returns I CONFACK. You should see this procedure twice because all handshaking procedures are two-way negotiations. Turning on some Cisco IOS debug commands displays the real-time negotiation. The O represents outgoing, and I signies an incoming message. A detailed description of the rst phase is described next. In order to display both Q.931 and PPP negotiation processes together, it is recommended to use the following:
804-isdn#debug isdn q931 804-isdn#debug ppp negotiation
In Example 12-25, you can see the BR0:1 LCP: State is Open message.
Example 12-25 LCP Negotiation Process
! Initiation of the call - Q931 Mar 2 04:03:47.900: ISDN BR0: Outgoing call id = 0x8060, dsl 0 Mar 2 04:03:47.904: ISDN BR0: Event: Call to 18007735555 at 64 Kb/s Mar 2 04:03:47.904: ISDN BR0: process_bri_call(): call id 0x8060, called_number 18007735555, speed 64, call type DATA Mar 2 04:03:47.908: CC_CHAN_GetIdleChanbri: dsl 0 Mar 2 04:03:47.908: Found idle channel B1 Mar 2 04:03:48.884: ISDN BR0: received HOST_PROCEEDING call_id 0x8060 Mar 2 04:03:50.152: ISDN BR0: received HOST_CONNECT call_id 0x8060 Mar 2 04:03:50.156: %LINK-3-UPDOWN: Interface BRI0:2, changed state to up Mar 2 04:03:50.172: %ISDN-6-CONNECT: Interface BRI0:2 is now connected to 18007735555 ! Starting PPP protocol Mar 2 04:03:50.180: BR0:1 PPP: Treating connection as a callout Mar 2 04:03:50.180: BR0:1 PPP: Phase is ESTABLISHING, Active Open Mar 2 04:03:51.139: BR0:2 LCP: O CONFREQ [Closed] id 16 len 33 Mar 2 04:03:51.143: BR0:2 LCP: AuthProto CHAP (0x0305C22305) Mar 2 04:03:51.143: BR0:2 LCP: MagicNumber 0x081C8F7E (0x0506081C8F7E) Mar 2 04:03:51.143: BR0:2 LCP: MRRU 1524 (0x110405F4) Mar 2 04:03:51.147: BR0:2 LCP: EndpointDisc 1 Local (0x130E01706D6172656B2D6973646E) Mar 2 04:03:51.227: BR0:2 LCP: I CONFREQ [REQsent] id 93 len 32 Mar 2 04:03:51.231: BR0:2 LCP: AuthProto CHAP (0x0305C22305) Mar 2 04:03:51.231: BR0:2 LCP: MagicNumber 0xB699FF25 (0x0506B699FF25) Mar 2 04:03:51.231: BR0:2 LCP: MRRU 1524 (0x110405F4) Mar 2 04:03:51.235: BR0:2 LCP: EndpointDisc 1 Local (0x130D016163636573732D677731) Mar 2 04:03:51.239: BR0:2 LCP: O CONFACK [REQsent] id 93 len 32
continues
338
Example 12-25 LCP Negotiation Process (Continued)

Mar Mar Mar Mar Mar Mar Mar Mar Mar Mar 2 04:03:51.239: BR0:2 LCP: AuthProto CHAP (0x0305C22305) 2 04:03:51.239: BR0:2 LCP: MagicNumber 0xB699FF25 (0x0506B699FF25) 2 04:03:51.243: BR0:2 LCP: MRRU 1524 (0x110405F4) 2 04:03:51.243: BR0:2 LCP: EndpointDisc 1 Local (0x130D016163636573732D677731) 2 04:03:51.243: BR0:2 LCP: I CONFACK [ACKsent] id 16 len 33! 2 04:03:51.247: BR0:2 LCP: AuthProto CHAP (0x0305C22305) 2 04:03:51.247: BR0:2 LCP: MagicNumber 0x081C8F7E (0x0506081C8F7E) 2 04:03:51.247: BR0:2 LCP: MRRU 1524 (0x110405F4) 2 04:03:51.251: BR0:2 LCP: EndpointDisc 1 Local (0x130E01706D6172656B2D6973646E) 2 04:03:51.251: BR0:2 LCP: State is Open
The information about LCP state is available in the output shown in Example 12-26.
Example 12-26 Information About LCP State
804-isdn#show interface bri 0 1 BRI0:2 is up, line protocol is up Hardware is BRI with U interface and POTS MTU 1500 bytes, BW 64 Kbit, DLY 20000 usec, reliability 255/255, txload 1/255, rxload 1/255 Encapsulation PPP, loopback not set Keepalive set (10 sec) Interface is bound to Dialer1 (Encapsulation PPP) LCP Open, multilink Open Last input 00:00:00, output 00:00:00, output hang never Last clearing of show interface counters never Queuing strategy: fifo <output omitted>
If LCP is closed, the PPP options are mismatched on both sides. For any negotiation, the LCP can fail, but there are different conguration commands in a 77x series router that reduce the chance of failure:
776-isdn>set ppp nego count 20Number of negotiation attempts (default = 10). 776-isdn>set ppp nego integrity 5Time between two integrity packets in seconds (default = 10). 776-isdn>set ppp nego retryTime between negotiation attempts in milliseconds (default = 5000).
Usually for long-distance connections, the calls are 56 Kbps and the high-order bit of the data is overwritten by the signaling information, causing the called party to possibly report errors. In some solutions, due to the lack of information that the call is 56 Kbps (an old version of SS7), the receiving site treats the call as 64 Kbps, resulting in a common symptom of CRC errors, or probably even runts or aborts. The dialer map or map-class dialer statement enables you to specify the speed of the outgoing call. If the connection is
Troubleshooting PPP
339
successful and if #debug isdn q931 is turned on, you can see a message similar to called_number 18007735555, speed 64, call type DATA. In some cases, you need to dene the call as not-end-to-end ISDN, as shown in Example 12-27.
Example 12-27 This Call Is Not End-to-End ISDN
Mar Mar Mar Mar Mar Mar Mar Mar Mar Mar Mar Mar 1 1 1 1 1 1 1 1 1 1 1 1 04:50:50.316: 04:50:50.320: 04:50:50.320: 04:50:50.324: 04:50:51.448: 04:50:51.452: 04:50:55.220: 04:50:55.220: 04:50:55.224: 04:51:05.704: 04:51:05.708: 04:51:05.720: ISDN BR0: TX -> SETUP pd = 8 callref = 0x3B Bearer Capability i = 0x8890 Channel ID i = 0x83 Keypad Facility i = 18007735555 ISDN BR0: RX <- CALL_PROC pd = 8 callref = 0xBB Channel ID i = 0x89 ISDN BR0: RX <- PROGRESS pd = 8 callref = 0xBB Progress Ind i = 0x8A81 - Call not end-to-end ISDN Signal i = 0x01 - Ring back tone on ISDN BR0: RX <- DISCONNECT pd = 8 callref = 0xBB Cause i = 0x839F08 - Normal, unspecified or Speci ISDN BR0: TX -> RELEASE pd = 8 callref = 0x3B
If the call hits voice trunks, the output displays Destination address is not_ISDN, which indicates that you must add the following statement under your BRI interface:
804-isdn(config-if)#isdn not-end-to-end
NOTE
How do you use the magic numbers for troubleshooting? Part of the LCP negotiation denes the so-called magic numbers. The conguration option of PPP provides a method to detect looped-back links and other Layer 2 anomalies. By default, the magic number is not negotiated. Zero is inserted where a magic number might otherwise be used. Before the conguration option is requested, the calling party must choose its magic number based on an algorithm for random numbers. When a Congure-Request is received with a magic number, the received magic number is compared with the magic number from the last Congure-Request sent to the peer. If the two magic numbers are different, the link is not looped back and the magic number needs to be acknowledged. If the two magic numbers are equal, its possible that the link is looped back and the Congure-Request is actually the one last sent. To conrm this, a Congure-Nak must be sent with a different magic number value. Reception of a Congure-Nak with a magic number different from the last Congure-Nak proves the link is not looped back. If the magic number is equal to the one sent in the last Congure-Nak, the probability of a looped-back link is increased, and a new magic number must be chosen. If the link is indeed looped back, the same sequence (transmit Congure-Request, receive Congure-Request, transmit CongureNak, receive Congure-Nak) will repeat continually. If the link is not looped back, the sequence might occur a few times, but it is extremely unlikely to repeatedly occur.
340
Troubleshooting PPP Authentication

The next phase of PPP protocol is the authentication phase. By default, PPP authentication is optional and should only be congured after the circuit is known good and IP connectivity has been established. This reduces the number of variables that have to be dealt with in case of a problem. Usually, the protocol number C023- Password Authentication Protocol (PAP) or C223-Challenge Handshake Authentication Protocol (CHAP) is used. If you enter the debug ppp authentication command, you can see the next phase of the PPP negotiation, as shown in Example 12-28. (The authentication command is a subset of ppp negotiation command.)
Example 12-28 debug ppp authentication Output
804-isdn#debug ppp authentication Oct 106 06:33:50.248: BR0:1 PPP: Phase is AUTHENTICATING, by both Oct 106 06:33:50.248: BR0:1 CHAP: O CHALLENGE id 42 len 33 from 804-isdn" Oct 106 06:33:50.272: BR0:1 CHAP: I CHALLENGE id 218 len 31 from gateway" Oct 106 06:33:50.276: BR0:1 CHAP: O RESPONSE id 218 len 33 from 804-isdn" Oct 106 06:33:50.308: BR0:1 CHAP: I SUCCESS id 218 len 4 Oct 106 06:33:50.312: BR0:1 CHAP: I RESPONSE id 42 len 31 from gateway Oct 106 06:33:50.316: BR0:1 CHAP: O SUCCESS id 42 len 4
Its important to make sure the type of the authenticationeither PAP or CHAPis the same on both sides of the connection. It is also important that authentication be congured under the physical interface, even when using dialer proles, because it is the authentication phase that ultimately determines which dialer prole will be used.
NOTE
If you receive cong-nack during the authentication negotiation, it means that one side is congured for PAP and the other is congured for CHAP password authentication.
Most ISPs will use PAP authentication. Also, it is probably going to be one-way PAP using the callin option of Cisco IOS routers, which can be seen in Chapter 11. The preferred PPP authentication choice is CHAP because all parts of the password are encrypted, and it supports the MD5 hash function. CHAP also uses three-way handshaking (as shown in the earlier example with three pairs of I and O messages) and avoids sending the password in clear text on the PPP link. You can see encrypted passwords in the conguration of both routers and in the exchange frame. For these reasons, consider CHAP as the superior authentication protocol. To connect using PPP, both parties do not necessarily require authentication, but if it is required, conrm the following:
The passwords congured on both the local and remote routers are identical. The local and remote router names are congured correctly.
Troubleshooting PPP
341
Dont forget that the passwords are case sensitive. If, after authentication, you see the following: BR0:1 CHAP: O SUCCESS, the authentication was successful. If you enter 804-isdn#sh dialer, you will see the name of the calling party at the end of the screen. The PPP authentication operates with names instead of numbers and makes ISDN troubleshooting much easier. As previously mentioned, when you try to trace the call working with your provider, your preferred option is to use calling_party_number, provided by Q.931. Tracing calls with a LEC isnt easy because you dont always know how the line is provisioned. Sometimes, in the router output, you cannot see the calling party number because the LEC might either use prexes, remove prexes, or replace the number with dialed number identication service (DNIS) information. Another option is to match the parameter call_ref, which requires your timing to be precisely synchronized with the LEC equipment. The PPP authentication allows you to operate with names, such as gateway or 804-isdn, instead of a numbers. This allows you to trace the call from the core router by using IOS-based search and nd features.
Troubleshooting PPP Network Control Protocols

NCPs are a set of protocols that negotiate the upper-layer protocols. Every negotiation is a series of requests and acknowledgmentsVi1 IPCP: I CONFREQ and Vi1 IPCP: I CONFACK [REQsent]. During the negotiation process, you can see IPCP, IPXCP (these are not included in Example 12-29), CDPCP, and CCP negotiating IP, IPX, CDP, and COMPRESSION, respectively. The negotiation depends on the conguration and the process starts by establishing the virtual connection, which is a bundle of channels called Multilink PPP (MLP). Next, LCP negotiates the parameters for the virtual connection. In the next example, you see the building of the bundle for IPCP, the negotiation of CCP, the setting of the LZSDCP history, and the CDPCP rejection.
Example 12-29 After PPP Is Up, You Can See Part of NCP with IPCP and CCP Negotiation
Oct 106 06:33:50.316: BR0:1 PPP: Phase is VIRTUALIZED Oct 106 06:33:50.328: %LINK-3-UPDOWN: Interface Virtual-Access1, changed state to up Oct 106 06:33:50.344: Vi1 PPP: Treating connection as a callout Oct 106 06:33:50.344: Vi1 PPP: Phase is ESTABLISHING, Active Open Oct 106 06:33:50.348: Vi1 LCP: O CONFREQ [Closed] id 1 len 34 Oct 106 06:33:50.348: Vi1 LCP: AuthProto CHAP (0x0305C22305) Oct 106 06:33:50.352: Vi1 LCP: MagicNumber 0xCEC4C1DA (0x0506CEC4C1DA) Oct 106 06:33:50.352: Vi1 LCP: MRRU 1524 (0x110405F4) Oct 106 06:33:50.352: Vi1 LCP: EndpointDisc 1 Local (0x130F01727363686966662D6973646E) Oct 106 06:33:50.356: Vi1 PPP: Phase is UP Oct 106 06:33:50.360: Vi1 CDPCP: O CONFREQ [Closed] id 1 len 4 Oct 106 06:33:50.360: Vi1 IPCP: O CONFREQ [Closed] id 1 len 10 Oct 106 06:33:50.364: Vi1 IPCP: Address 10.19.230.89 (0x03060A13E659) ! Building the multilink PPP bundle for IP
continues
342
Example 12-29 After PPP Is Up, You Can See Part of NCP with IPCP and CCP Negotiation (Continued)
Oct 106 06:33:50.368: BR0:1 IPCP: MLP bundle interface is built, process packets now Oct 106 06:33:50.368: BR0:1 IPCP: Redirect packet to Vi1 Oct 106 06:33:50.368: Vi1 IPCP: I CONFREQ [REQsent BR0:2 PPP: Phase is VIRTUALIZED!!!] id 1 len 10 Oct 106 06:33:50.372: Vi1 IPCP: Address 151.70.196.1 (0x0306AB46C401) Oct 106 06:33:50.372: Vi1 IPCP: O CONFNAK [REQsent] id 1 len 10 Oct 106 06:33:50.372: Vi1 IPCP: Address 151.68.26.1 (0x0306AB441A01) ! Building the multilink bundle for stac compress Oct 106 06:33:50.376: BR0:1 CCP: MLP bundle interface is built, process packets now Oct 106 06:33:50.376: BR0:1 CCP: Redirect packet to Vi1 Oct 106 06:33:50.380: Vi1 CCP: I CONFREQ [Not negotiated] id 1 len 10 Oct 106 06:33:50.380: Vi1 CCP: LZSDCP history 1 check mode SEQ process UNCOMPRESSSED (0x170600010201) Oct 106 06:33:50.384: Vi1 LCP: O PROTREJ [Open] id 2 len 16 protocol CCP (0x80FD0101000A170600010201) Oct 106 06:33:50.400: BR0:1 LCP: I PROTREJ [Open] id 1 len 10 protocol CDPCP (0x820701010004) ! CDPCP rejected Oct 106 06:33:50.404: Vi1 CDPCP: State is Closed Oct 106 06:33:50.404: Vi1 IPCP: I CONFACK [REQsent] id 1 len 10 Oct 106 06:33:50.408: Vi1 IPCP: Address 10.19.230.89 (0x03060A13E659) Oct 106 06:33:50.408: Vi1 IPCP: I CONFREQ [ACKrcvd] id 2 len 4 Oct 106 06:33:50.412: Vi1 IPCP: O CONFACK [ACKrcvd] id 2 len 4 Oct 106 06:33:50.412: Vi1 IPCP: State is Open Oct 106 06:33:50.420: Di1 IPCP: Install route to 151.68.26.1 Oct 106 06:33:51.316: %LINEPROTO-5-UPDOWN: Line protocol on Interface BRI0:1, changed state to up
When troubleshooting the higher-layer protocols, it is important to know which protocol and which port or application is open in the router. One important feature that enables you to nd this out is the command #show tcp brief all, which shows you what TCP sessions are open to a router. Sometimes, you need to nd out if the utilization of the routers processor is high. Some processes are not running and some use most of the router resources. A fast tool to nd this out is
804 -isdn#show processes cpu
exclude 0.00
This command excludes the processes with utilization 0.00 from the output. Another important question to answer is which protocol and which port or application is consuming most of the bandwidth. You can nd out relatively quickly by using the Cisco IP NetFlow Accounting feature, which makes it possible to quickly identify trafc ows and applications by source and destination port number(s). To do this, you need version 12.2+ of Cisco IOS Software. Follow this procedure:
Troubleshooting PPP
343
1 Type #ip route-cache ow under the dialer interface. 2 Wait a few minutes and execute the #show ip cache ow command.
The detailed output provides you with the following information:
IP packet size distribution and the total number of packets. IP ow switching cache, total number in bytes. Protocol, type (UDP/TCP) distribution. Source and destination IP address of the trafc.
As discussed in Chapter 10, Cisco ISDN Conguration Solutions, the MLP is a feature providing multivendor interoperability and packet fragmentation, improving the latency of each packet and load calculation. The MLP issues are discussed in the following paragraph.
Troubleshooting MLP
MLP denes a method for sequencing and transmitting packets over multiple physical interfaces. To reduce potential latency issues, MLP denes a method of fragmenting and reassembling large packets. When a packet arrives at an MLP master interface, it is fragmented and transmitted on each physical link in the MLP bundle. Reassembly of the packets occurs on the other side of the connection. MLP is supported, as long as all devices are members of the same rotary group or pool. Usually, designers use load thresholds to dene when and for how long MLP will add or remove additional links to the connection. (See Chapters 10 and 11 for more information.) The easiest way for IOS-based ISDN routers to verify the threshold values of the router is to check the conguration of the IOS ISDN router and look for the value under the command dialer load-threshold, or type #show dialer and look for load threshold for dialing additional calls is x. A fragment of the output from the second command is shown in Example 12-30.
Example 12-30 show dialer Output
804-isdn#show dialer BRI0 - dialer type = ISDN Rotary group 1, priority = 0 0 incoming call(s) have been screened. 0 incoming call(s) rejected for callback. <output omitted> Di1 - dialer type = IN-BAND SYNC NO-PARITY Load threshold for dialing additional calls is 20 Idle timer (60 secs), Fast idle timer (20 secs) Wait for carrier (30 secs), Re-enable (15 secs) Number of active calls = 0
344
For a 77x router, the output is displayed in Example 12-31.

Example 12-31 show timeout Output
776-isdn> show timeout Demand Calling Parameters Link 1 Connection Type Auto ON Permanent OFF Threshold 5 kbs Duration 1 sec Source LAN Timeout (call tear down) Parameters Threshold 5 kbs Duration 60 sec Source LAN Link 2 Auto ON OFF 48 kbs 1 sec BOTH 48 kbs 60 sec BOTH
These commands provide the necessary information on how MLP and the thresholds are set. Keep in mind that, for an 800 series router, the threshold value is a fraction of 255, while for a 700 series router, the value is measured in Kbps. It is important to dene not only the conditions of the threshold (level and duration), but also the destination. There are three major options of IN, OUT, or EITHER for IOS-based routers, and LAN, WAN, or BOTH, for 77x series routers. To set MLP, enter the following:
804-isdn(cong-if)#ppp multilinkFor IOS-based routers 776-isdn> set ppp multilink on | offFor 700 series routers 804-isdn#show ppp multilink 7206-isdn#show ppp multilink | incl name 776-isdn>show negotiationFor 77x routers
To check your MLP, you can use one of the following commands:
Troubleshooting PPP Callback for ISDN

As described in Chapter 11, this PPP feature provides a method for an implementation to request a dial-up peer to call back. When callback is successfully negotiated at the LCP phase and the authentication phase of PPP is complete, instead of going to the NCP phase, PPP disconnects the link. A sample of checking the functionality of the callback feature is shown in Example 12-32.
Troubleshooting PPP
345
Example 12-32 ISDN Callback Output From the debug isdn 931 Command
804-isdn#debug isdn q931 ! The remote user requests a connection: *Oct 10 04:03:00.914: ISDN BR0: TX -> SETUP pd = 8 callref = 0x0A *Oct 10 04:03:00.918: Bearer Capability i = 0x8890 *Oct 10 04:03:00.918: Channel ID i = 0x83 *Oct 10 04:03:00.922: Keypad Facility i = 5261783 *Oct 10 04:03:01.250: ISDN BR0: RX <- CALL_PROC pd = 8 callref = 0x8A *Oct 10 04:03:01.250: Channel ID i = 0x89 *Oct 10 04:03:01.270: ISDN BR0: RX <- CONNECT pd = 8 callref = 0x8A *Oct 10 04:03:01.278: ISDN BR0: TX -> CONNECT_ACK pd = 8 callref = 0x0A ! Incoming and outgoing CONNECT messages the BRI0:1 is up. *Oct 10 04:03:01.282: %LINK-3-UPDOWN: Interface BRI0:1, changed state to up *Oct 10 04:03:01.302: %ISDN-6-CONNECT: Interface BRI0:1 is now connected to 5261783 *Oct 10 04:03:01.798: %LINK-3-UPDOWN: Interface Virtual-Access1, changed state to up ! The fact the virtual-access1 interface is up shows that the authentication ! phase was successful. Now the core disconnects the connection: *Oct 10 04:03:01.838: ISDN BR0: RX <- DISCONNECT pd = 8 callref = 0x8A *Oct 10 04:03:01.842: Cause i = 0x8090 - Normal call clearing *Oct 10 04:03:01.854: ISDN BR0: TX -> RELEASE pd = 8 callref = 0x0A *Oct 10 04:03:01.858: %LINK-3-UPDOWN: Interface BRI0:1, changed state to down *Oct 10 04:03:01.886: %LINK-3-UPDOWN: Interface Virtual-Access1, changed state to down *Oct 10 04:03:01.998: ISDN BR0: RX <- RELEASE_COMP pd = 8 callref = 0x8A ! Now the core router initiates a call to the remote user: *Oct 10 04:03:16.970: ISDN BR0: RX <- SETUP pd = 8 callref = 0x10 *Oct 10 04:03:16.974: Bearer Capability i = 0x8890 *Oct 10 04:03:16.974: Channel ID i = 0x89 *Oct 10 04:03:16.974: Signal i = 0x40 - Alerting on - pattern 0 *Oct 10 04:03:16.978: Called Party Number i = 0xC1, 5764740 *Oct 10 04:03:16.982: Locking Shift to Codeset 5 *Oct 10 04:03:16.982: Codeset 5 IE 0x2A i = 0x808001039E05, From, 0x208B03, 408, 0x8001098001, < *Oct 10 04:03:16.990: ISDN BR0: Event: Received a DATA call from 408 on B1 at 64 Kb/s *Oct 10 04:03:16.998: ISDN BR0: TX -> CALL_PROC pd = 8 callref = 0x90 *Oct 10 04:03:16.998: Channel ID i = 0x89 ! The remote users BRI0:1 comes up: *Oct 10 04:03:17.002: %LINK-3-UPDOWN: Interface BRI0:1, changed state to up *Oct 10 04:03:17.018: %ISDN-6-CONNECT: Interface BRI0:1 is now connected to 408 *Oct 10 04:03:17.030: ISDN BR0: TX -> CONNECT pd = 8 callref = 0x90 *Oct 10 04:03:17.034: Channel ID i = 0x89 *Oct 10 04:03:17.074: ISDN BR0: RX <- CONNECT_ACK pd = 8 callref = 0x10 *Oct 10 04:03:17.074: Channel ID i = 0x89 *Oct 10 04:03:17.078: Signal i = 0x4F - Alerting off *Oct 10 04:03:17.622: %LINK-3-UPDOWN: Interface Virtual-Access1, changed state to up *Oct 10 04:03:18.610: %LINEPROTO-5-UPDOWN: Line protocol on Interface BRI0:1, changed state to up *Oct 10 04:03:18.642: %LINEPROTO-5-UPDOWN: Line protocol on Interface
continues
346
Example 12-32 ISDN Callback Output From the debug isdn 931 Command (Continued)
Virtual-Access1, changed state to up *Oct 10 04:03:23.022: %ISDN-6-CONNECT: Interface BRI0:1 is now connected to 14085265555 access-gw1 804-isdn#
As mentioned in Chapter 11, there is a way to set up the conguration so that both channels come up when a call from the core router is received using the #dialer load-threshold 2 inbound command. It is interesting to check the functionality of PPP callback feature using the IOS. One possible solution is to debug the PPP negotiation and ISDN Q931 with the following commands:
804-isdn#debug isdn q931 804-isdn#debug ppp negotiation
Remember: If you are connected through a telnet session to the remote users router, make sure that the debug commands are turned on with 804-isdn#show debug. Because you will have connects and disconnects during the process, and you will lose the telnet connection, its recommended that you create a log in the remote users router conguration to be able to see the entire process afterwards. The output from the log le looks like Example 12-32 (with added PPP negotiation information). The number 2 in the dialer load-threshold 2 inbound command denes that only the incoming trafc will be compared with the threshold, and it is set to 2 (which is ~1% of the bandwidth = 2 / 255 x 100 x bandwidth). When both channels are up, how do you check that this is due to incoming calls and not outgoing calls? One of the ways is to read the log le for RX<- and TX-> messages to see who is initiating the call. But because this output can be chatty, you might want to try a simpler way, as shown in Example 12-33.
Example 12-33 Output from the sh isdn st Used to Check the Reason for the Calls
804-isdn#sh isdn st Global ISDN Switchtype = basic-5ess ISDN BRI0 interface dsl 0, interface ISDN Switchtype = basic-ni Layer 1 Status: ACTIVE Layer 2 Status: TEI = 104, Ces = 2, SAPI = 0, State = MULTIPLE_FRAME_ESTABLISHED TEI = 113, Ces = 1, SAPI = 0, State = MULTIPLE_FRAME_ESTABLISHED Spid Status: TEI 113, ces = 1, state = 5(init) spid1 configured, spid1 sent, spid1 valid Endpoint ID Info: epsf = 0, usid = 0, tid = 1 TEI 104, ces = 2, state = 5(init)
Troubleshooting PPP
347
Example 12-33 Output from the sh isdn st Used to Check the Reason for the Calls (Continued)
spid2 configured, spid2 sent, spid2 valid Endpoint ID Info: epsf = 0, usid = 1, tid = 1 Layer 3 Status: 2 Active Layer 3 Call(s) Activated dsl 0 CCBs = 2 ! Callid with leading 0: CCB:callid=C, sapi=0, ces=1, B-chan=1, calltype=DATA ! Callid with leading 0: CCB:callid=D, sapi=0, ces=1, B-chan=2, calltype=DATA The Free Channel Mask: 0x80000000 Total Allocated ISDN CCBs = 2 804-isdn#
An explanation for callid can be found in Chapter 9, ISDN Technology Background. The most signicant bit of Q931 is a bit called Flag. When the Flag is 0, the call is initiated from the core router; when Flag is 1, the call is initiated from the remote users site. The numbers in the output are callid=C and callid=D. Written in binary codes, they have leading 0s, which means that the calls are originated from the core router, thus the callback is working. Maybe the simplest way to check the callback function is to use the following command:
804-isdn#show isdn active
With this command, check the calls attribute to see if it is IN or OUT, as shown in Example 12-34.
Example 12-34 Checking the Calls Attribute
-------------------------------------------------------------------------------ISDN ACTIVE CALLS -------------------------------------------------------------------------------Call Calling Called Remote Seconds Seconds Seconds Charges Type Number Number Name Used Left Idle Units/Currency -------------------------------------------------------------------------------In ---N/A--5764740 gateway 17 -___________0__ In ---N/A--5764740 gateway 44 -___________0__
The example shows that both calls are incoming, thus the callback works. As discussed in Chapter 11, another enhancement of MLP is the Multichasis Multilink PPP (MMP), which enables different MLP links to terminate on different NASs.
Troubleshooting MMP
For troubleshooting MMP, it is always recommended that you start with debug sgbp error:
7200-isdn-a#debug sgbp error ! SGBP errors debugging is on 7200-isdn-b# Aug 9 22:20:03 PDT: %SGBP-7-NORESP: Failed to respond to 7200-isdn-a group isdnservers, may not have password
348
The previous message indicates problems answering the challenges sent by a peer. This should be enough to indicate that the username and password are left out of the stack group, as shown in Example 12-35.
Example 12-35 debug sgbp hellos Output
7200-isdn-a#debug sgbp hellos ! SGBP hellos debugging is on for both routers 7200-isdn-a# Aug 9 22:29:37 PDT: %SGBP-7-CHALLENGED: Rcv Hello Challenge message from member 7200-isdn-b using 152.30.253.253 ! Received a hello challenge from 7200-isdn-b from IP address 152.30.253.253 Aug 9 22:29:37 PDT: %SGBP-7-RESPONSE: Send Hello Response to 7200-isdn-b group isdnservers ! Respond to the challenge Aug 9 22:29:37 PDT: %SGBP-7-NORESP: Failed to respond to 7200-isdn-b group isdnservers, may not have password ! You cannot respond because you do not have a password Aug 9 22:29:42 PDT: %SGBP-7-CHALLENGE: Send Hello Challenge to 7200-isdn-b group isdnservers ! You send a challenge to 7200-isdn-b 7200-isdn-b# Aug 9 22:29:37 PDT: %SGBP-7-CHALLENGE: Send Hello Challenge to 7200-isdn-a group isdnservers Aug 9 22:29:42 PDT: %SGBP-7-CHALLENGED: Rcv Hello Challenge message from member 7200-isdn-a using 152.30.253.254 Aug 9 22:29:42 PDT: %SGBP-7-RESPONSE: Send Hello Response to 7200-isdn-a group isdnservers Aug 9 22:29:43 PDT: %SGBP-7-NORESP: Failed to respond to 7200-isdn-a group isdnservers, may not have password ! The password is mismatched or is missing
From the output, each router receives the others challenge; therefore, you congured the correct host names and IP address for the sgbp peers. Adding the username of isdnservers and the password of cisco to the conguration of both routers xes the problem indicated in the last line of the previous output stating that the password is mismatched or is missing. Another possible issue with MMP could be a host name and IP address mismatch. The following message is displayed after entering debug sgbp hello on 7200-isdn-b. It usually means that the router has a host name and IP address mismatch, as shown in the following output:
Aug 10 01:08:15 PDT: %SGBP-1-MISSCONF: Possible misconfigured member 7200-isdn-a using 152.30.253.254
Correcting the SGBP peer line with the correct IP address xes this issue. An incorrect SGBP password prevents peers from authenticating into the SGBP group. The following message means that either the peers password for the stack group is incorrect or yours is incorrect:
Troubleshooting PPP
349
Aug 10 01:48:53 PDT: %SGBP-1-AUTHFAILED: Member 7200-isdn-b failed authentication
The obvious x is to verify that you have the correct SGBP username and password entered in both routers keeping in mind that they are case sensitive. As an example, router 7200-isdn-a is receiving hellos from an unknown peer. As a result, both routers are not establishing a peer relationship. Start by using the debug sgbp error command again on both routers:
SGBP errors debugging is on 7200-isdn-b# Aug 9 22:59:02 PDT: %SGBP-1-DIFFERENT: Rcv 7200-isdn-as addr 152.30.253.253 is different from the hellos addr 152.30.253.254 ! Received a hello from 7200-isdn-a, but from 152.30.253.254 instead of what ! was configured in the sgbp member statement Aug 9 22:59:02 PDT: %SGBP-1-DIFFERENT: Rcv 7200-isdn-as addr 152.30.253.253 is different from the hellos addr 152.30.253.254 7200-isdn-a#
However, on 7200-isdn-a, theres no output after entering debug sgbp error. So you should take a look at the debug sgbp hello output. debug sgbp hello on both routers provides the output in Example 12-36.
Example 12-36 debug sgbp hello Output
SGBP hellos debugging is on 7200-isdn-b# Aug 9 23:00:52 PDT: %SGBP-1-DIFFERENT: Rcv 7200-isdn-as addr 152.30.253.253 is different from the hellos addr 152.30.253.254 Aug 9 23:00:52 PDT: %SGBP-1-DIFFERENT: Rcv 7200-isdn-as addr 152.30.253.253 is different from the hellos addr 152.30.253.254 Aug 9 23:00:52 PDT: %SGBP-7-CHALLENGED: Rcv Hello Challenge message from member 7200-isdn-a using 152.30.253.254 Aug 9 23:00:52 PDT: %SGBP-7-RESPONSE: Send Hello Response to 7200-isdn-a group isdnservers Aug 9 23:00:54 PDT: %SGBP-7-CHALLENGE: Send Hello Challenge to 7200-isdn-a group isdnservers 7200-isdn-a# Aug 9 23:00:08 PDT: %SGBP-7-CHALLENGE: Send Hello Challenge to 7200-isdn-b group isdnservers Aug 9 23:00:30 PDT: %SGBP-7-CHALLENGE: Send Hello Challenge to 7200-isdn-b group isdnservers
In Example 12-36s output, 7200-isdn-bs congured peer IP address is different than the one the actual hellos are coming from. In addition to the debug command, the command show sgbp tells you that there is another active address for 7200-isdn-a, as shown in Example 12-37.
350
Example 12-37 show sgbp Output

7200-isdn-b#show sgbp Group Name: isdnservers Ref: 0xC973B000 Seed bid: default, 50, default seed bid setting Member Name: 7200-isdn-a State: idle Id: 3 Ref: 0x0 Address: 152.30.253.253 Other Active Address: 152.30.253.254
In this case, the problem is that a mistake was made on 7200-isdn-b in the IP address of 7200-isdn-a entered in the sgbp member statement. From 7200-isdn-as perspective, only challenges were sent and nothing was received because 7200-isdn-b was sending the replies to the wrong IP address. From 7200-isdn-bs perspective, challenges were sent, but no responses were received. Instead, 7200-isdn-b was getting challenges from 7200-isdn-a with a different IP address than was congured. After the IP address was xed, debug sgbp hello on both routers would just show the keepalives sent every two seconds:
Aug 10 00:28:21 PDT: %SGBP-7-KEEPALIVE: Sending Keepalive to 7200-isdn-b, retry=0 Aug 10 00:28:21 PDT: SGBP: Keepalive ACK rcv from 7200-isdn-b Aug 10 00:28:23 PDT: %SGBP-7-KEEPALIVE: Sending Keepalive to 7200-isdn-b, retry=0 Aug 10 00:28:23 PDT: SGBP: Keepalive ACK rcv from 7200-isdn-b Aug 10 00:28:25 PDT: %SGBP-7-KEEPALIVE: Sending Keepalive to 7200-isdn-b, retry=0 Aug 10 00:28:25 PDT: SGBP: Keepalive ACK rcv from 7200-isdn-b
NOTE
Some versions of IOS displays these debugs differently.
Mismatched IP addresses are especially easy to encounter if the routers have multiple interfaces. If the sgbp source-ip command is not used, the hellos would use the outgoing interfaces IP address as the source IP address. Therefore, its good to use the IP addresses of loopback interfaces in the sgbp source-ip command to avoid these situations. The following is not usually something you will see, but it illustrates that missing three keepalives will time out the peer and, in order to re-establish the peer relationship, they must be authenticated again as shown in Example 12-38.
Example 12-38 Missing Three Keepalives
Aug Aug Aug Aug Aug Aug Aug 10 10 10 10 10 10 10 00:30:37 00:30:37 00:30:39 00:30:39 00:30:41 00:30:43 00:30:45 PDT: PDT: PDT: PDT: PDT: PDT: PDT: %SGBP-7-KEEPALIVE: Sending Keepalive to 7200-isdn-b, SGBP: Keepalive ACK rcv from 7200-isdn-b %SGBP-7-KEEPALIVE: Sending Keepalive to 7200-isdn-b, SGBP: Keepalive ACK rcv from 7200-isdn-b %SGBP-7-KEEPALIVE: Sending Keepalive to 7200-isdn-b, %SGBP-7-KEEPALIVE: Sending Keepalive to 7200-isdn-b, %SGBP-7-KEEPALIVE: Sending Keepalive to 7200-isdn-b, retry=0 retry=0 retry=0 retry=1 retry=2
Troubleshooting PPP
351
Example 12-38 Missing Three Keepalives (Continued)

! Just missed the third keepalive in a row Aug 10 00:30:47 PDT: %SGBP-7-KEEPALIVE_TIMEOUT: Keepalive timeout on 7200-isdn-b ! 7200-isdn-b has just timed out and is no longer a functional SGBP peer Aug 10 00:30:48 PDT: %SGBP-7-CHALLENGE: Send Hello Challenge to 7200-isdn-b group isdnservers ! Starting hello challenges to try to re-establish 7200-isdn-b as a SGBP peer Aug 10 00:30:49 PDT: %SGBP-7-CHALLENGE: Send Hello Challenge to 7200-isdn-b group isdnservers Aug 10 00:30:50 PDT: %SGBP-7-CHALLENGE: Send Hello Challenge to 7200-isdn-b group isdnservers Aug 10 00:30:51 PDT: %SGBP-7-CHALLENGE: Send Hello Challenge to 7200-isdn-b group isdnservers
As mentioned in Chapter 10, the bidding process of SGBP is when the SGBP stack group routers decide who will be the call master for any given MLP bundle. To view the bidding process, you need to debug SGBP queries, as shown in Example 12-39.
Example 12-39 Debugging SGBP Queries
7200-isdn-a#debug sgbp queries ! Displays the bidding process Aug 10 14:26:21 PDT: %SGBP-7-NEWP: Peer query #22667 for user1-isdn, count 1, peerbid 11, ourbid 10000 ! Your peer received a call from user1-isdn and is bidding. ! Your bid is 10000, so you must already be the call master for this user. Aug 10 14:26:21 PDT: %SGBP-7-DONE: Query #32436 for bundle user1-isdn, count 0, master is local ! The call master is local Aug 10 14:26:21 PDT: %SGBP-7-MQB: Bundle: user1-isdn State: Done OurBid: 10000 Aug 10 14:26:21 PDT: %SGBP-7-PB: 152.30.253.254 State: Closed Bid: 011 Retry: 1
In this case, the master bundle is on the peer, as shown in Example 12-40.
Example 12-40 The Master Bundle Is on the Peer
Aug 10 14:27:14 PDT: %SGBP-7-NEWL: Local query #32444 for user2-isdn, count 1, ourbid 0 ! You received a call from user2-isdn and are starting the bidding process Aug 10 14:27:14 PDT: %SGBP-7-DONE: Query #32444 for bundle user2-isdn, count 1, master is 152.30.253.254 ! The call master is 152.30.253.254 Aug 10 14:27:14 PDT: %SGBP-7-MQB: Bundle: user2-isdn State: Done OurBid: 000 Aug 10 14:27:14 PDT: %SGBP-7-PB: 152.30.253.254 State: Closed Bid: 10000 Retry: 0
352
Troubleshooting PPP Compression Control Protocol

Compression Control Protocol (CCP) is a member of the NCP suite and provides a compression session that increases the ISDN throughput. Keep in mind that all compression methods are trafc dependant, so you cannot expect the same compression ratio for different types of trafc. The protocol is referred to as PPP CCP and denes a method for negotiating compression on PPP links over leased lines, and WAN circuit-switched-lines including ISDN. To congure compression, use the following:
804-isdn(cong-if)#compress {stac | predictor}Under the BRI0 interface 776-isdn>set compression stac | off
Stac compression denes the LZS Stacker compression algorithm and predictorthe RAND or predictor algorithm. The theory behind these algorithms is extremely complex. More information is available in IETF, Calgary Text Compression Corpus, and the Canterbury Corpus les (http://corpus.canterbury.ac.nz/). It is helpful to know that you can see the compression ratio by entering the following:
804-isdn# show compressionFor IOS 12.1 and higher 776-isdn:gateway>show packetsFor images 4.2 and higher
Example 12-41 displays the output for a 776 router.

Example 12-41 show packets Output
776-isdn:gateway> show packets Packet Statistics for Connection 2 Filtered: 0 Forwarded: 2081 Received: 5581 Dropped: 0 Lost: 0 Corrupted: 1 Misordered: 0 Compression Ratio: 1.99:1 776-isdn:gateway>
Here, the router is reporting compression ratio 1.99:1 for connection 2, calculated on the base of 2081 forwarded and 5581 received packets. The last phase of PPP protocol is the teardown, or determination of the connection, which, in turn, should result in releasing the LECs facilities.
PPP: Termination of the Connection

Consider this example: After a connection is established and there is no further demand for a network connection, the end users router sends a request for disconnect -BR0:1 LCP: O TERMREQ [Open], which is referred to as a termination request. After the expected acknowledgment - I TERMACK [TERMsent], you can see LCP Closed, PPP down. Example 12-42 shows the PPP termination sequence if the debug ppp negotiation command is turned on.
Troubleshooting Telephone Interfaces
353
Example 12-42 PPP Termination Sequence

*Mar *Mar *Mar *Mar *Mar *Mar *Mar *Mar 2 04:06:13.755: BR0:1 LCP: O TERMREQ [Open] id 201 len 4 2 04:06:13.827: BR0:1 LCP: I TERMACK [TERMsent] id 201 len 4 2 04:06:13.827: BR0:1 LCP: State is Closed 2 04:06:13.827: BR0:1 PPP: Phase is DOWN 2 04:06:13.831: BR0:1 PPP: Treating connection as a callin 2 04:06:13.831: BR0:1 PPP: Phase is ESTABLISHING, Passive Open 2 04:06:13.831: BR0:1 LCP: State is Listen 2 04:06:13.835: %DIALER-6-UNBIND: Interface BRI0:1 unbound from profile Dialer1 *Mar 2 04:06:13.835: BR0:1 PPP: Phase is ESTABLISHING, Passive Open *Mar 2 04:06:13.839: %ISDN-6-CONNECT: Interface BRI0:2 is now connected to 18007735555 gateway *Mar 2 04:06:13.843: %ISDN-6-DISCONNECT: Interface BRI0:1 disconnected from 18007735555 gateway, call lasted 243s. *Mar 2 04:06:14.783: %ISDN-6-CONNECT: Interface BRI0:2 is now connected to 18007735555 gateway *Mar 2 04:06:14.787: %LINK-3-UPDOWN: Interface BRI0:1, changed state to down *Mar 2 04:06:14.803: BR0:1 LCP: State is Closed *Mar 2 04:06:14.803: BR0:1 PPP: Phase is DOWN *Mar 2 04:06:14.831: %LINEPROTO-5-UPDOWN: Line protocol on Interface BRI0:1, changed state to down
The analogous commands for 77x routers to debug (or not) the PPP phases are
776-isdn>diag ppp on
| |
off off
776-isdn>diag chap on
These commands turn the debug of PPP on and off. If the ISDN service is provisioned for data and voice, the voice portion will work as every other regular phone. Now you will see how to approach the possible problems if your regular phone is connected to the voice ports of the router.

Cisco IOS includes features that handle data and voice priority. Depending on user preferences, voice can take precedence over data and vice versa. Data and voice alternate on every channel. There are three options for voice priority over data: always, conditional, and never. The choice depends on the conguration, so this is the rst thing to check when troubleshooting. The options are shown in the following:
804-isdn(config-if)#isdn voice-priority 5764740 out ? always always bump data call conditional bump data call only if connection is not lost off never bump data call
The conditional option, which is the default, means that the data call will be disconnected only if the network connection can be guaranteed; that is, only if there are two data calls up to the same direction.
354
NOTE
Always advise the user to use POTS2 for voice if he/she is using only one phone because BRI1 is the data channel and comes up rst. This way, the user can (for example) exchange data and be on a conference call simultaneously.
The next important consideration is how the line is provisioned. If it is provisioned only for data, there is no voice option. If it is provisioned for voice and data, the ring signal is usually provided by the line (the LECs switch), but it can also be generated by the router. This should be tested or checked. To test the ring options of the router and determine if there are any hardware issues, it is always good to have the remote user participating in the troubleshooting process. For this particular part, user participation is mandatory to make voice calls out and to hear the different signals. The following are the possible options:
804-isdn#test pots 2 ringer ? <0-2> Cadence number 804-isdn#test pots 2 disconnect ! Disconnect tone
To test the tone capability of the router, the following are the command options:
804-isdn#test pots 1 tone ? busy Busy Tone call-waiting Call Waiting Tone dial Dial Tone reorder Reorder Tone ringback Ringback Tone silence Disable Tones or ringer
It is important to check if the line is provisioned for additional call offering (ACO). This usually means that, if you have two B channels up, the switch forwards the next call (data or voice) to the router, and the router makes a decision based on the conguration. To check if the ACO is set up on the following example (where the phone numbers are 4088535983 and 4085764741), rst enter the following:
804-isdn#debug pots csm 804-isdn#debug pots driver
Then enter:
804-isdn#show debugging POTS: POTS CSM events debugging is on POTS DRIVER debugging is on
Then, make a voice call from 4088535983 to 4085764741, and monitor the output from the router (see Example 12-43).
355
Example 12-43 The Output of CSM Events and POTS Driver Debugging
804-isdn# *Mar 22 20:41:54.525: EVENT_FROM_ISDN:dchan_idb=0x27E6F38, call_id=0x68, ces=0x2 bchan=0x0, event=0x1, cause=0x0 *Mar 22 20:41:54.525: CSM_GET_CALL_INFO_FOR_DN:forward-to-unused-port disabled check the config ! This by default and it is correct - BY DEFAULTT *Mar 22 20:41:54.529: CSM_GET_CALL_INFO_FOR_DN:New call forwarded to port 2 ! Reporting correct because calling the second number. ! The dial-peer 1 is set up, otherwise the call will go to the first channel *Mar 22 20:41:54.529: CSM_PROC_IDLE: CSM_EVENT_ISDN_CALL, call id = 0x68, port = 2 ! Calling the second LDN check the dial peers *Mar 22 20:41:54.529: Calling Number:4088535983 Called number:5764741 ! The numbers are correct, so Q931 provides caller ID and called partys ID *Mar 22 20:41:54.529: POTS DRIVER port=2 activate ringer: cadence=0 callerId=4088535983 *Mar 22 20:41:54.533: POTS DRIVER port=2 state=Idle drv_event=RING_EVENT *Mar 22 20:41:54.533: POTS DRIVER port=2 enter_ringing *Mar 22 20:41:54.573: POTS DRIVER port=2 CallerId Strg=032220414088535983G PCM len=129F *Mar 22 20:41:54.573: POTS DRIVER port=2 cmd=19 *Mar 22 20:41:56.573: POTS DRIVER port=2 cmd=1A *Mar 22 20:41:57.073: POTS DRIVER port=2 cmd=1B *Mar 22 20:41:57.073: POTS DRIVER port=2 ts connect: 3 0 *Mar 22 20:42:00.573: POTS DRIVER port=2 cmd=19 *Mar 22 20:42:02.573: POTS DRIVER port=2 cmd=1A *Mar 22 20:42:06.573: POTS DRIVER port=2 cmd=19 *Mar 22 20:42:07.769: EVENT_FROM_ISDN:dchan_idb=0x27E6F38, call_id=0x68, ces=0x2 bchan=0xFFFFFFFF, event=0x0, cause=0x10 ! The caller is picking the phone *Mar 22 20:42:07.769: CSM_PROC_RINGING: CSM_EVENT_ISDN_DISCONNECTED, call id = 0x68, port = 2 ! The caller disconnects *Mar 22 20:42:07.769: POTS DRIVER port=2 activate disconnect *Mar 22 20:42:07.773: POTS DRIVER port=2 state=Ringing drv_event=DISCONNECT_EVENT *Mar 22 20:42:07.773: POTS DRIVER port=2 cmd=1A *Mar 22 20:42:07.773: POTS DRIVER port=2 enter_idle *Mar 22 20:42:07.773: POTS DRIVER port=2 ts connect: 0 0 *Mar 22 20:42:07.777: POTS DRIVER port=2 cmd=1B *Mar 22 20:42:07.777: POTS DRIVER port=2 activate tone=SILENCE_TONE *Mar 22 20:42:07.777: POTS DRIVER port=2 state=Idle drv_event=TONE_EVENT *Mar 22 20:42:07.777: POTS DRIVER port=2 activate tone=SILENCE_TONE *Mar 22 20:42:07.781: POTS DRIVER port=2 state=Idle drv_event=TONE_EVENT
The test proves the voice calls hit the router, if BRI2 is idle. To check if the ACO is set up, you need to bring the second channel up and test it again. The set of voice features of ISDN can be expanded. The important point here is to have a clear understanding about how the voice features, priorities, and services are provisioned
356
and congured. The troubleshooting needs to occur based on the expected feature performance of the ISDN service.
End Notes
1
Cisco Press. Network Design and Case Studies (CCIE Fundamentals), Second Edition. Cisco Press, 2000.
Summary
This chapter illustrated the layer-by-layer troubleshooting techniques for ISDN. The main focus is to the remote user and the BRI. The systematic approach in this chapter enables you to enhance your knowledge about troubleshooting the most common ISDN solutions and includes information on the following:
D channel Layer 1, Layer 2, and Layer 3 troubleshooting. The PPP protocol troubleshooting in its ISDN implementation. PPP phases and protocols, including PPP callback MLP and MMP protocols and their troubleshooting. Troubleshooting techniques for telephone interfaces.
Review Questions
1 What is the command to see the status of the D channel of the IOS-based ISDN
router? In which mode of the IOS router can you type the command?
2 If you want to see what IP address has triggered the last call in Cisco 77x router, what
command should you type?

3 What do you look for in the output of the IOS command Router#sh isdn status to be
sure if the physical layer in BRI is functional?

4 What IOS command enables you to distinguish between internal and external ISDN
issues?
5 If you want to debug Layer 2 of ISDN, what is the rst IOS command you have to
type?
6 Under normal circumstances, what messages should you not see from the output of
Router#debug isdn q921?
Review Questions
357
7 What are you looking for in the output of the IOS command Router#sh isdn status to
be sure if Layer 2 is functional?

8 In the output from the command Router#debug isdn q921, what does TX ->...ai = 127
mean?
type?
10 What is the bearer capability in Q931 messages for 64 kbps data, 56 kbps data, and
voice calls?
11 What is the name of the message indicating that the LCP negotiation is successful? 12 What is the recommended IOS command to troubleshoot the dialer trafc when the
router makes outgoing data calls?

13 How many lines of PPP CHAP negotiation indicating success can you see in the
output of #debug ppp authentication?

14 If you receive cong nack during the PPP authentication negotiation, what does it
mean?
15 When testing the voice features, what are the two recommended IOS commands you
can use?
CHAPTER
13
Troubleshooting Scenarios for ISDN BRI

This chapter provides more specic examples of some of the most common problems when troubleshooting the remote user ISDN BRI connections. This chapter includes the following:
The common recommendations for the practical troubleshooting of ISDN BRI Scenario 1: New Install Problems Scenario 2: Dial-Out Problems Scenario 3: ISDN Performance Problems Scenario 4: End-to-End Communication Problems Scenario 5: Windows 2000 DDR Issue
These real-life scenarios illustrate the troubleshooting techniques covered in Chapter 12, ISDN BRI Troubleshooting.
Recommendations for Practical Troubleshooting of ISDN Remote Services

It is important to understand that most troubleshooting processes occur remotely. The following sections are written with this premise in mind: You are located somewhere else, possibly thousands of miles from the remote users location. The core router is located somewhere on your campus, or possibly both the core and the end users router are miles away from you.
NOTE
Make sure that you understand the environment in which you are troubleshooting because troubleshooting is an environment-dependant activity.
After you establish the environment with which you are dealing, you need to set up your own environment. This section focuses on how you should set up your troubleshooting process. Of course, the real world can offer you much less, but any part of these
360
Chapter 13: Troubleshooting Scenarios for ISDN BRI
recommendations can help you pinpoint the problem faster. These recommendations include the following:
Using #show isdn status to view service layers Preconguring the routers on both ends Accessing the remote users router
Using #show isdn status to View Service Layers

If the remote users ISDN is not functioning correctly, you cannot telnet to the router. Your best chance is to work with the remote user. Take time to help the user (if necessary) by teaching him or her how to use the telnet session or the console connection to the router. One of the most useful IOS commands for ISDN troubleshooting is show isdn status, which provides a snapshot of all layers of the service. Example 13-1 shows an ISDN line in the activation stage. The rst layer of this IOS-based router is active, but the second layer negotiation is still in progress.
Example 13-1
Snapshot of ISDN BRI Layers

804-isdn#show isdn status Global ISDN Switchtype = basic-5ess ISDN BRI0 interface dsl 0, interface ISDN Switchtype = basic-ni Layer 1 Status: ACTIVE Layer 2 Status: TEI = 96, Ces = 1, SAPI = 0, State = TEI_ASSIGNED TEI = 105, Ces = 2, SAPI = 0, State = TEI_ASSIGNED TEI 96, ces = 1, state = 3(await establishment) spid1 configured, spid1 sent, spid1 valid Endpoint ID Info: epsf = 0, usid = 0, tid = 1 TEI 105, ces = 2, state = 1(terminal down) spid2 configured, spid2 sent, spid2 valid Endpoint ID Info: epsf = 0, usid = 1, tid = 1 Layer 3 Status: 0 Active Layer 3 Call(s) Active dsl 0 CCBs = 0 The Free Channel Mask: 0x80000003 Total Allocated ISDN CCBs = 0 804-isdn#
NOTE
The dynamics of ISDN events can be seen using the powerful command 804-isdn#debug isdn events [interface bri 0]. This command requires a detailed understanding of the messages on the screen and generates signicant output. If you feel condent enough, use it; but when you use it on the core router, limit the duration to less than ten minutes and turn it off.
361
The #show isdn status output in Example 13-2 is of a properly functioning BRI circuit. In Example 13-2, Layer 1 is active and Layer 2 is in a MULTIPLE_FRAME_ESTABLISHED state. The terminal endpoint identiers (TEIs) are successfully negotiated, and the ISDN Layer 3 is ready to make or receive calls.
Example 13-2
All Layers of ISDN Are Active

804-isdn#show isdn status Global ISDN Switchtype = basic-5ess ISDN BRI0 interface dsl 0, interface ISDN Switchtype = basic-ni Layer 1 Status: ACTIVE Layer 2 Status: TEI = 96, Ces = 1, SAPI = 0, State = MULTIPLE_FRAME_ESTABLISHED TEI = 105, Ces = 2, SAPI = 0, State = MULTIPLE_FRAME_ESTABLISHED TEI 96, ces = 1, state = 5(init) spid1 configured, spid1 sent, spid1 valid Endpoint ID Info: epsf = 0, usid = 0, tid = 1 TEI 105, ces = 2, state = 5(init) spid2 configured, spid2 sent, spid2 valid Endpoint ID Info: epsf = 0, usid = 1, tid = 1 Layer 3 Status: 0 Active Layer 3 Call(s) Active dsl 0 CCBs = 0 The Free Channel Mask: 0x80000003 Total Allocated ISDN CCBs = 0 804-isdn#
This is an important command. You must understand each line of this output. Table 13-1 provides a detailed description of the output.
Table 13-1 Output from the #show isdn status Command Line of the Output Global ISDN Switchtype The current ISDN Switchtype = basic5ess ISDN BRI0 interface dsl 0, interface ISDN Switchtype = basic-ni Basic-5ess is the switch-type, congured in the general conguration of the router. Basic-NI1 (National) is congured under interface BRI0. This conguration takes precedence over the previous line. If there are more BRI interfaces without a specic switch-type conguration, they will accept the Basic-5ess settings. See Chapter 10, ISDN Design Solutions. continues Description
362
Table 13-1
Output from the #show isdn status Command (Continued) Line of the Output Layer 1 status ACTIVE Layer 1 Status: Veries the physical layer connectivity with the LECs ISDN switch. This can be ACTIVE or DEACTIVATED. See Chapters 11 and 12 for more information. Description
Layer 2 Status TEI = 96, Ces = 1, SAPI = 0, State = MULTIPLE_FRAME_ESTABLISHED TEI = 105, Ces = 2, SAPI = 0, State = MULTIPLE_FRAME_ESTABLISHED Status of ISDN Layer 2 with the TEI number and multiframe state. If the switch uses dynamic assignments, the valid TEI numbers are from 64 to 124. If they are static assignments, the numbers are from 1 to 63. TEI=127 stands for broadcast-request. The most common Layer 2 states are MULTIPLE_FRAME_ESTABLISHED and TEI_ASSIGNED. A state=MULTIPLE_FRAME_ESTABLISHED indicates that there is data-link connectivity to the LECs ISDN switch. You should see this state under normal operation. Any other state indicates a problem on the circuit. A Layer 2 Status of down is indicated by Layer 2 NOT Activated. See Chapter 12 for more information. Spid Status TEI 96, ces = 1, state = 8(established) TEI 106, ces=2, state = 5(init) TEI number and state. The most common state values are State = 1(terminal down) State = 3(await establishment) State = 5(init) State = 6(not initialized) State = 8(established) Only states 8 and 5 indicate a working BRI circuit. The other states mean the circuit is not properly established.
363
Table 13-1
Output from the #show isdn status Command (Continued) Line of the Output spid(1 or 2) congured, spid(1 or 2) sent, spid(1 or 2) valid , no LDN Description spid(1 or 2) conguration information for a working BRI. The valid combination is shown on the left column and other possible combinations are spid(1 or 2) congured, no LDN, spid1 sent, spid1 valid spid(1 or 2) NOT congured, spid1 NOT sent, spid1 NOT valid spid(1 or 2) congured, spid1 NOT sent, spid1 NOT valid spid(1 or 2) congured, spid1 sent, spid1 NOT valid The last three states indicate that either the spid was not congured or that it is incorrect. No LDN means that the associated LDN(1 or 2) is not congured. Endpoint ID Info: epsf = 0, usid = 1, tid = 1 Endpoint identier information can be used by the Endpoint ID Info: epsf = 0, usid = 3, tid = 1 router to decide which channel will answer the call. The message ENDPOINT ID in the isdn q931 format is associated with the usid and tid. usid tid Layer 3 Status 2 Active Layer 3 Call(s) CCB:callid=103, sapi=0, ces=1, B-chan=1, calltype=DATA CCB:callid=819B, sapi=0, ces=2, B-chan=2, calltype=DATA Number of active calls. Information about the active calls. The rst line is incoming calls to the users router, and the second line is outgoing calls. For a connected call, it displays the caller ID information, call reference, and the B channel it is occupying. The rst calls callid is a smaller number than the second one. The call type can be DATA or VOICE. Any other type, such as INTERNAL, identies a problem with the LEC. Activated dsl 0 CCBs = 2 Number of Digital Signal Link (dsl) activated. Number of Call Control Blocks (CCB) in use. Total Allocated ISDN CCBs = 2 Number of ISDN CCBs that are allocated. User Service Identier. Terminal Identier.
In the enterprise environmentwhere usually you have deployed limited types of Cisco ISDN routersyou might have more options available, such as ISDN lines and Cisco routers congured for test purposes. The following sections give you details on these.
364
Preconguring the Routers on Both Ends

The rst thing you must consider is the router thats immediately available to you. Its a good idea to use any Cisco ISDN router, such as Cisco 776, Cisco 804, Cisco 1604, and so on, to perform initial testing of the remote users router. If you are a network administrator who is responsible for a relatively big ISDN environment, its a good idea to have an ISDN line at your desk. For example, the Cisco 77x router at your desk with a simple conguration can help you perform initial troubleshooting. The following are recommended conguration lines:
set system ENS set ppp secret client secret secret set ppp secret host secret secret set ppp auth out none
NOTE
The system name can be anything as long as the system name on both ends (the test side and the remote user side) is the same. If the remote user has a 77x router, the following conguration needs to be applied to the users router to allow remote access for troubleshooting:
set user ENS set ppp client ENS set bridging on set ppp authentication outgoing chap set ppp secret client secret secret set ppp secret host secret secret cd set active ENS
NOTE
One possible option is to turn off the authentication on both ends of the link to rule it out as a problem. The benet of this conguration is that, if the remote users router includes this user conguration, you can call the LDN using the 77x router at your desk. The users router simply prompts you for a password. Remember that the Cisco 77x series router has only one level of password authentication. This is unlike IOS routers, which have more sophisticated password systems, such as vty authentication option, enable password, and secrets.
NOTE
365
To verify that the user prole exists and it is active on both sides, enter the show user command on both routers, as shown in Example 13-3.
Example 13-3
show user Output

ENS> show user User State Connection -------------------------------------------LAN Active LAN Internal Active INTERNAL Standard Active 1 gateway Active 2 ENS Active 3 ENS>
NOTE
The remote users router must be powered up for testing purposes. Even when troubleshooting is performed by the LEC, the technician cannot run any tests without the poweredup NT1. If the router has a built-in NT1, the router must be powered on; if not, the power supply for NT1 must be turned on. Most of the line tests by the local providers require looping back the NT1.
Accessing the Remote Users Router

With your router and the users router setup, you can now make a manual call to the remote users router from your test router, which will result in a number of typical situations:
The circuit is not available, and the message from your test router is usually Cause 34 No Circuit/Channel Available. Typically, after receiving this message, theres nothing to troubleshoot. Either the circuit is disconnected, the service is completely shut down, or you called a non-ISDN number:
ENS> call 1 14087785444 02/04/1995 20:54:45 L05 0 14087785444 ENS> ENS> 02/04/1995 20:54:46 L12 1 Cause 34 No Circuit/Channel Available ENS> 02/04/1995 20:54:46 L27 1 ENS> Outgoing Call Initiated Disconnected Remotely Disconnected
Could this condition be caused by a misconguration? It would be prudent to explore this possibility rst, and double-check it with the remote user, the switch type, SPIDs, and LDNs. If everything is okay, its a good idea to open a trouble ticket with the local provider at this point and double-check how the service is provisioned.
366
If you are calling a non-ISDN number, the typical response will be bearer capability error, as shown in the following:
ENS> call 1 14083691136 02/04/1995 21:00:21 L05 0 14083691136 ENS> ENS> 02/04/1995 21:00:22 L12 1 Cause 65 Bearer Capability Error ENS> 02/04/1995 21:00:22 L27 1 ENS> Outgoing Call Initiated Disconnected Remotely Disconnected
The call is rejected. When the channel is already up, you cannot make a call to the remote users router (unless call waiting is congured on the LEC side). You will receive a Receiver Busy or Call Rejected message. The Call Rejected message is shown here:
ENS> call 1 14085764740 02/04/1995 21:04:34 L05 0 14085764740 Outgoing Call Initiated ENS> ENS> 02/04/1995 21:04:35 L11 1 4085764740 Call Requested ENS> 02/04/1995 21:04:35 L09 1 Call Rejected Cause 17 Receiver Busy ENS> 02/04/1995 21:04:35 L12 1 Disconnected Remotely Cause 17 Receiver Busy ENS> 02/04/1995 21:04:35 L27 1 Disconnected
For other call rejection messages, see Table 12-1 in Chapter 12.
The channel that you are calling is idle, so you can make a call. An idle channel and an initiated call is shown here:
ENS> call 1 14086175555 01/05/1995 21:34:49 L05 0 14086174271 Outgoing Call Initiated ENS> ENS> 01/05/1995 21:34:50 L08 1 14086174271 Call Connected ENS> 01/05/1995 21:34:51 Connection 2 Add Link 1 Channel 1 ! At this point you have a connection ENS> login remote ENS> Enter Password:
After this point, you are in the remote users router. If the provided password is correct, you see the remote users router prompt:
776-isdn>
Now you have direct access to the users router without needing the end user to assist you with troubleshooting.
Preliminary Test of Remote IOS-Based ISDN Router with Test 776 Router
If the users router is an IOS-based ISDN router and you are calling from a 77x router, you can still make a call, but the IOS will not prompt you (by default). To gain access to an IOS router, you usually use a Telnet or Secure Shell (SSH) session. The problem is: How do you use Telnet if the remote users router cannot pass data? This is the benet of using a 77x to call an 804 router. If the call is successful, you see the following message:
ENS> call 1 14087312598 01/01/1995 00:07:36 L05 0 14087312598 Outgoing Call Initiated ENS> ENS> 01/01/1995 00:07:37 L08 1 14087312598 Call Connected ENS> 01/01/1995 00:07:37 L60 1 Password Not Found ENS> 01/01/1995 00:07:37 L12 1 Disconnected Remotely Cause 16 Normal Disconnect
367
ENS> 01/01/1995 00:07:37 ENS>
L27
Disconnected
Your 776 router makes a call to 1 408 731-2598, which is congured in Cisco IOS 804 router. If remote users see the channel1 light, and both the TxD and RxD lights blink, the status of the ISDN service is okay (see the show isdn status command later). But the connection drops with the message Password Not Found, which gives you an indication of what the problem is. First of all, this is the expected message and the connection is dropping at the authentication phase of PPP protocol because you are calling from the test router, but not from the core router. This narrows down the probable causes of the problem. Recall from the explanations in Chapter 12 that to reach the PPP authentication phase, the ISDN service goes through all three layers of the D channel, through the LCP stage of PPP, and, just after that, it reaches the authentication phase. At this point, all you have to do is to concentrate on possible PAP/CHAP issues on both the remote users and core routers.
Preliminary Test of Remote 77x Router with Test IOS-Based ISDN Router
How do you call from an IOS-based router to a 77x router? Example 13-4 shows you how this works. Your test router ENS-isdn is calling 1 831 430-0444 by using your rst channel. You are debugging the ppp negotiation with the command #debug ppp negotiation.
Example 13-4
The Output of Calling a 77x Router from an IOS-Based Router

ENS-isdn#isdn call interface bri0:1 18314300444 *Mar 7 02:28:31.895: BR0:1 PPP: Phase is TERMINATING *Mar 7 02:28:31.899: BR0:1 LCP: O TERMREQ [Open] id 107 len 4 *Mar 7 02:28:31.899: Vi1 CDPCP: State is Closed *Mar 7 02:28:31.903: Vi1 IPCP: State is Closed *Mar 7 02:28:31.907: %LINK-3-UPDOWN: Interface Virtual-Access1, changed state to down *Mar 7 02:28:31.907: Vi1 PPP: Phase is TERMINATING *Mar 7 02:28:31.911: Vi1 LCP: State is Closed *Mar 7 02:28:31.911: Vi1 PPP: Phase is DOWN *Mar 7 02:28:31.911: Di1 IPCP: Remove route to 172.30.253.254 *Mar 7 02:28:32.115: BR0:1 LCP: I TERMACK [TERMsent] id 107 len 4 *Mar 7 02:28:32.115: BR0:1 LCP: State is Closed *Mar 7 02:28:32.119: BR0:1 PPP: Phase is DOWN *Mar 7 02:28:32.119: BR0:1 PPP: Phase is ESTABLISHING, Passive Open *Mar 7 02:28:32.119: BR0:1 LCP: State is Listen *Mar 7 02:28:32.127: %ISDN-6-DISCONNECT: Interface BRI0:1 disconnected from 18007735555 access-gw1, call lasted 61 seconds *Mar 7 02:28:32.319: %LINK-3-UPDOWN: Interface BRI0:1, changed state to down *Mar 7 02:28:32.331: BR0:1 LCP: State is Closed *Mar 7 02:28:32.331: BR0:1 PPP: Phase is DOWN8314300444 *Mar 7 02:28:32.895: %LINEPROTO-5-UPDOWN: Line protocol on Interface BRI0:1, changed state to down *Mar 7 02:28:32.907: %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access1, changed state to down *Mar 7 02:28:35.883: %LINK-3-UPDOWN: Interface BRI0:1, changed state to up
continues
368
Example 13-4
The Output of Calling a 77x Router from an IOS-Based Router (Continued)

*Mar *Mar *Mar *Mar *Mar *Mar *Mar 7 02:28:35.899: BR0:1 PPP: Treating connection as a callout 7 02:28:35.899: BR0:1 PPP: Phase is ESTABLISHING, Active Open 7 02:28:35.903: BR0:1 LCP: O CONFREQ [Closed] id 108 len 35 7 02:28:35.903: BR0:1 LCP: AuthProto CHAP (0x0305C22305) 7 02:28:35.907: BR0:1 LCP: MagicNumber 0xD030C260 (0x0506D030C260) 7 02:28:35.907: BR0:1 LCP: MRRU 1524 (0x110405F4) 7 02:28:35.907: BR0:1 LCP: EndpointDisc 1 Local (0x131001706E6564656C74632D6973646E) *Mar 7 02:28:37.539: BR0:1 LCP: I CONFREQ [REQsent] id 89 len 31 *Mar 7 02:28:37.543: BR0:1 LCP: AuthProto CHAP (0x0305C22305) *Mar 7 02:28:37.543: BR0:1 LCP: MagicNumber 0xB13FEF1B (0x0506B13FEF1B) *Mar 7 02:28:37.543: BR0:1 LCP: MRRU 1524 (0x110405F4) *Mar 7 02:28:37.547: BR0:1 LCP: EndpointDisc 1 Local (0x130C01627564692D6973646E) *Mar 7 02:28:37.551: BR0:1 LCP: O CONFACK [REQsent] id 89 len 31 *Mar 7 02:28:37.551: BR0:1 LCP: AuthProto CHAP (0x0305C22305) *Mar 7 02:28:37.551: BR0:1 LCP: MagicNumber 0xB13FEF1B (0x0506B13FEF1B) *Mar 7 02:28:37.555: BR0:1 LCP: MRRU 1524 (0x110405F4) *Mar 7 02:28:37.555: BR0:1 LCP: EndpointDisc 1 Local (0x130C01627564692D6973646E) *Mar 7 02:28:37.903: BR0:1 LCP: TIMEout: State ACKsent *Mar 7 02:28:37.903: BR0:1 LCP: O CONFREQ [ACKsent] id 109 len 35 *Mar 7 02:28:37.903: BR0:1 LCP: AuthProto CHAP (0x0305C22305) *Mar 7 02:28:37.907: BR0:1 LCP: MagicNumber 0xD030C260 (0x0506D030C260) *Mar 7 02:28:37.907: BR0:1 LCP: MRRU 1524 (0x110405F4) *Mar 7 02:28:37.907: BR0:1 LCP: EndpointDisc 1 Local (0x131001706E6564656C74632D6973646E) *Mar 7 02:28:37.947: BR0:1 LCP: I CONFACK [ACKsent] id 109 len 35 *Mar 7 02:28:37.947: BR0:1 LCP: AuthProto CHAP (0x0305C22305) *Mar 7 02:28:37.947: BR0:1 LCP: MagicNumber 0xD030C260 (0x0506D030C260) *Mar 7 02:28:37.951: BR0:1 LCP: MRRU 1524 (0x110405F4) *Mar 7 02:28:37.951: BR0:1 LCP: EndpointDisc 1 Local (0x131001706E6564656C74632D6973646E) *Mar 7 02:28:37.955: BR0:1 LCP: State is Open *Mar 7 02:28:37.955: BR0:1 PPP: Phase is AUTHENTICATING, by both *Mar 7 02:28:37.955: BR0:1 CHAP: O CHALLENGE id 176 len 34 from ENS-isdn *Mar 7 02:28:37.959: BR0:1 CHAP: I CHALLENGE id 87 len 30 from 804-isdn *Mar 7 02:28:37.963: BR0:1 CHAP: Username 804-isdn not found ! Username is not found *Mar 7 02:28:37.963: BR0:1 CHAP: Unable to authenticate for peer ! Unable to authenticate *Mar 7 02:28:37.963: BR0:1 PPP: Phase is TERMINATING *Mar 7 02:28:37.967: BR0:1 LCP: O TERMREQ [Open] id 110 len 4 *Mar 7 02:28:37.995: BR0:1 LCP: I TERMACK [TERMsent] id 110 len 4 *Mar 7 02:28:37.995: BR0:1 LCP: State is Closed *Mar 7 02:28:37.995: BR0:1 PPP: Phase is DOWN *Mar 7 02:28:37.995: BR0:1 PPP: Phase is ESTABLISHING, Passive Open *Mar 7 02:28:37.999: BR0:1 LCP: State is Listen *Mar 7 02:28:38.003: %ISDN-6-DISCONNECT: Interface BRI0:1 disconnected from 18314300475 804-isdn, call lasted 2 seconds *Mar 7 02:28:38.159: %LINK-3-UPDOWN: Interface BRI0:1, changed state to down *Mar 7 02:28:38.167: BR0:1 LCP: State is Closed *Mar 7 02:28:38.167: BR0:1 PPP: Phase is DOWN ENS-isdn#
Scenario 1: New Install Problems
369
The procedure is successful until the authentication phase (see Chapter 12 for more information on the authentication phase), at which point the call is dropped in two seconds. This shows that the ISDN layers are okay, PPP is congured, LCP is okay, CHAP is the chosen authentication option, and CHAP is congured two ways. From this point, you can focus on authentication, NCP protocols, and routing. It is important to understand that, in this example, username failed because, by default, IOS is trying to use the host name for the CHAP username. With theses initial recommendations, you are now ready to tackle some of the problems you might face. The following scenarios walk you through typical situations that you might encounter when troubleshooting ISDN remote services.
NOTE

New install problems are related to the way a line is provisioned, and to the way the service is designed and installed. The following are typical new install issues:
The local loop is installed and the LECs technician has tested the line, has deemed it as okay, but theres still no ISDN service. The service is installed and the user can make local voice calls, but the user cannot connect to the companys core router. The user can make calls and can connect one of the channels, but not both channels. The user cannot accept voice calls and cannot make voice calls when two channels are making data calls.
There are, of course, many other types of issues. The important thing to recognize is that the provisioning process is critical for new ISDN service. Even if the initial order for the ISDN install is issued correctly and the router is congured accordingly, sometimes a problem can take a long time to correct. An error in the provisioning process can lead to a redesign of the service, and the LEC usually considers a redesign as a new install with new charges and long delays. Pay particularly close attention to the provisioning process. Before troubleshooting new install problems, make sure that you know the specics of the provisioned service. The requested service might be in one of the following stages: requested, ordered, operational, cancelled, deactivated, or pending deactivation. Only spend time troubleshooting if the LEC shows the status as operational, and the requested type of service matches what was provided. For more about provisioning, see Chapter 1, Remote Access Overview.
NOTE
370
NOTE
It is important to note that the type of switch you are connected to is not necessarily the switch type you set in IOS. The technician might know for a fact that the switch is a 5ESS, but it is possible to be provisioned for NI-1. You will need to set up your router likewise. For the U.S., the NI-1 switch setting is by far the most common setting regardless of if the switch is DMS, 5ESS, and so on.
The router is congured based on the provisioning information provided by the LEC. Supposing that the router conguration is correct, Table 13-2 provides some typical new install problems and their respective solutions.
Table 13-2 Problem The local loop is installed, the line tested okay, but there is no voice and no data. The local loop is installed and tested okay, and there is voice, but no data. Typical New Install Problem Descriptions and Their Solutions Solution The LECs provisioning/service department needs to turn the service on in the central ofce (CO) and remove any restrictions from the switch. Check with the LEC to see if the line is provisioned for VOICE and DATA. Also, because of late payments, the service can be temporarily disabled, which means that the LEC or LD carrier changed the switch settings from operational to maintenance or blocked, expecting the end user to contact them. Check with the LEC to see if the line is provisioned for VOICE and DATA. Check the switch-type to determine if it supports VOICE. For some providers, the basic service is DATA; VOICE is considered best effort. Ask the user to make a long-distance voice call. If the longdistance service is not set up, the user will hear either a different LD carrier greeting or a message that states the LD calls are blocked. Using Sprint LD as an example, an automatic recording system is used. If you make an VOICE call to 1 700 5554141 and Sprint is the LD carrier, you will hear, Welcome to Sprint Long-Distance, 54110. The last ve digits are called trailing number, which shows the number of the recorder and where the call hits the Sprint network. If the conguration is set up correctly for the type of service (see Scenario 2), the issue is related to the LEC. The switch is not set up to allow two data calls simultaneously.
The local loop is installed and tested okay, and the user can connect to the core router, but the voice service is not available. The user can make voice and local data calls, but the user cannot connect to the core router.
How do you check to see if the users LD service is set up correctly?
The voice service is okay on both channels, but the data is okay only on the rst channel.
371
Table 13-2 Problem
Typical New Install Problem Descriptions and Their Solutions (Continued) Solution There are two possible solutions to this problem: 1. It is most likely that the rst channel is picked up by one LD carrier and the second channel is picked up by another carrier by mistake. Sometimes this works, and sometimes it doesnt. The message from the 776 router indicates that theres no route to the destination. The LEC must correct the information on the ISDN switch. For example, 333 indicates that the LD portion is picked up by Sprint. 2. The switch does not allow two data calls simultaneously, which the LEC must correct.
The rst channel is okay for data and voice, but when the router brings the second channel up, the user loses the data connection.
The user has data service, but every incoming voice call hits the rst channel. The data service is okay, but the voice portion works only for outgoing calls. The data and voice portions are okay, but when the router brings both channels up, no incoming calls are available, regardless of the conguration. The data and voice portions are okay, but when the rst channel is up and someone places a voice call to the rst channel of the router, it rings busy.
The dial-peer portion of the conguration probably does not exist, or it is miscongured in the conguration. Check to see if the conguration line isdn incoming-voice modem exists under the BRI0 interface. The issue is related to the ISDN switch that rejects every other call if two calls are already in progress. The LEC must correct this. Check for the command no forward-to-unused-port in the dial-peer cong blocks. If dial-peers are available in the cong, by default, the call should go to the next available channel. Also, this can be related to the voice priority issue rather than an available channel issue. Check the way the voice priority is set up in your conguration.
The data and voice portions are okay, but when both channels are up for data and someone places a voice call to the router, it rings busy. The data and voice portions are okay, but there is no ring signal.
This can be the correct reaction of the router. If the switch allows every other call to hit the router, the router makes a decision based on the conguration. Check the way the voice priority is set up in your conguration. The rst thing to check is who is generating the signalthe switch or the router. Set the conguration accordingly. If this does not help, the CPE is probably malfunctioning; you might consider getting another one.
These problems and solutions cover the vast majority of the cases that you might encounter for the new-installs category. The next scenario examines dial-out problems.
372
Scenario 2: Dial-Out Problems

The very rst thing the router should be able to do is make outgoing calls and accept incoming ones. A variety of complexities are related to dial functions, but keep in mind that, regardless of rst layer functions, a call requires all three layers to be set up correctly. Begin dial issue troubleshooting with the show isdn active command. This command shows the active outgoing calls, called party number, and called remote site name, as displayed in Example 13-5.
Example 13-5
show isdn active Output

804-isdn#show isdn active ISDN ACTIVE CALLS -------------------------------------------------------------------------------Call Calling Called Remote Seconds Seconds Seconds Charges Type Number Number Name Used Left Idle Units/Currency -------------------------------------------------------------------------------Out +8007735555 gateway 64 0 Out +8007735555 gatewaay 31 0 804-isdn#
If you dont see the router calling out, you should see if the remote user router has ever made calls out. For this and other information, use IOS command show dialer. Example 13-6 shows the output for this command.
Example 13-6
Output for the show dialer Command

804-isdn#show dialer BRI0 - dialer type = ISDN Rotary group 1, priority = 0 0 incoming call(s) have been screened. 0 incoming call(s) rejected for callback. BRI0:1 - dialer type = ISDN Idle timer (60 secs), Fast idle timer (20 secs) Wait for carrier (30 secs), Re-enable (15 secs) Dialer state is multilink member Connected to 18007735555 (access-gw1) BRI0:2 - dialer type = ISDN Idle timer (60 secs), Fast idle timer (20 secs) Wait for carrier (30 secs), Re-enable (15 secs) Dialer state is idle Di1 - dialer type = IN-BAND SYNC NO-PARITY Load threshold for dialing additional calls is 20 Idle timer (60 secs), Fast idle timer (20 secs) Wait for carrier (30 secs), Re-enable (15 secs) Number of active calls = 1 Dial String Successes Failures Last DNIS 18007735555# 1 164 03:57:41 18007735555 95 165 00:11:05
Last status failed successful
373
A detailed description of the command lines output is shown in Table 13-3.

Table 13-3 Output BRI0 - dialer type = ISDN Rotary group 1, priority = 0 0 incoming call(s) have been screened. 0 incoming call(s) rejected for callback. BRI0:1 - dialer type = ISDN Dialer state is multilink member Di1 - dialer type = IN-BAND SYNC NO-PARITY Load threshold for dialing additional calls is 20 Idle timer (60 secs) Description of the Output from the show dialer Command Description D channel. Dialer 1 is a member of rotary group 1. There is no setting in the cong for call screening. There is no setting in the conguration for callback. BRI1 and BRI2 are dened as a member of MP group. Dialer 1 performs in-band dialing. The threshold for BRI2 is set to 20/255 x bandwidth, which for ISDN is 128 kbps. The dialer is idle before disconnecting the call. The command line is 804-isdn(cong-if)#dialer idle-timeout [0-2147483]. Fast idle timer (20 secs) The fast-idle timer is activated if there is another packet waiting for a different next hop address. The default is 20 seconds and the command is pnedeltc-isdn(cong-if)#dialer fast-idle [1-2147483]. Wait for carrier before making a call. pnedeltc-isdn(cong-if)#dialer wait-for-carriertime [1-2147483] Re-enable (15 secs) Wait interval before redialing. 804-isdn(cong-if)#dialer redial interval [5-2147483] Number of active calls = 2 Dial String 18007735048 Successes Failures 1 95 164 165 Last DNIS Last status 03:57:41 00:11:05 failed successful Number of active calls at the moment. Dialer statistics for every dialer map: String to dial (# indicates secondary) Number of successful calls Number of failures Time from the last call Whether the last call was a failure or success
Wait for carrier (30 secs)
18007735048#
374
This is not the only command that can provide information on dial-out issues. The following commands are also recommended:
804-isdn#debug dialer 804-isdn#debug dialer [events | packets] 804-isdn#show running-config interface dialer 1
The last command enables you to check the conguration of the dialer 1. The result of the previous commands usually will allow you to dene the problem. The Table 13-4 provides a brief overview of well-known dial issues and their possible resolution.
Table 13-4 Problem The router does not call out even if you try a manual call out, you dont see any call activity. Dial Problems, Reasons, and Solutions Reason/Solution This problem can be due to variety of reasons. If the reasons are not obvious, perform the following step-by-step troubleshooting process. First, type the following command: 804-isdn#show isdn status This checks to see if each layer of ISDN is okay. This step eliminates most issues related to media problems, hardware, cables, ports, SPIDs, and switch-types. Check to see if the interface is down. A quick check of interfaces to determine if any are administratively down can be done using the following command: 804-isdn#show ip interface brief When it is a new install, its common for interfaces to be down from the very beginning (by default). Use the previous command to ensure that all interfaces are up. To bring an interface up, go to the interface conguration mode and enter the following: 804-isdn(cong-if)#no shutdown When you change SPIDs and LDNs, instead of power-cycling the router to re-obtain new TEIs, you can enter the following: 804-isdn#clear interface BRI0 Check if the dialer map (dialer string) command exists and is not miscongured. Check if the rotary group (dialer pool) is congured correctly. Check for a missing dialer-list statement. Check for a missing or miscongured access control list. Determine if there is a speed-setting mismatch. Always congure the router with a secondary dialer map for speed 56, or dene a class with options 64 and 56.
375
Table 13-4 Problem
Dial Problems, Reasons, and Solutions (Continued) Reason/Solution There is a missing or miscongured dialer load-threshold command. Enter the following: 804-isdn#show dialer Check the conguration of the dialer interface and specically check if the dialer load-threshold load [outbound | inbound | either] command exists under the dialer interface. Make sure you know how it is congured. This command enables you to congure bandwidth on demand and bring up the second channel if necessary. Or refer to the conguration command: 804-isdn#show run With IOS routers, the load is a fraction of 255, multiplied by the bandwidth (128 kbps). In 77x series routers, it is in kbps. So 25 in IOS indicates about 10 percent of congured interface bandwidth, and in 77x, it indicates 25 kbps. If it is congured for either (IOS only) or both (77x only), the router calculates load based on inbound + outbound. Use 1 if you want two channels to come up simultaneously. For cost-savings purposes, it is recommended to use 100 or either.
The second B channel does not come up. The second channel comes up too early or too late. Both channels come up together.
The line disconnects too slowly. The line disconnects too quickly.
Check dialer idle-timeout [seconds]. This timer denes the time (in seconds) between two consecutive interesting events. The timer ticks down between these events. When expires, the router is tearing down the call. It is recommended that you use 180 seconds.
Packets wait too long for a different next- This occurs when the fast-idle timer is activated. The command does hop address. not appear in the cong unless it is congured for different values than the default. The default value is 20. It can be seen under the dialer interface. 804-isdn(cong-if)#dialer fast-idle [1-2147483] The router waits too long to connect. This is probably a conguration issue. If there is no specic conguration, the default value is 30. Check the conguration command under the dialer interface: dialer wait-for-carrier-time [1-2147483] Dene or change the amount of time to wait for a carrier to pick up the call after dialing the dial string. The router waits too long before redial. This is probably a conguration issue. If there is no specic conguration, the default value is 15 seconds, which is the average time for the switch to release the previous call. Check the conguration command under the dialer interface: dialer redial interval [5-2147483] Dene or change the amount of time is seconds for redial interval.
376
Table 13-4 is not a complete list of all possible issues, but it covers the most common or well-known problems in this category.
NOTE
The bandwidth on demand in ISDN BRI can be congured with one of the most important commands in every dialer conguration: 804-isdn(config-if)#dialer load-threshold load [outbound | inbound | either] Every seconds, the router measures the load in the dialer. The measurement interval is, by default, 300 seconds (5 minutes). To calculate the load at full utilization, the transmission rate of the particular channel is multiplied by the load interval. In general, the rate (input) or (output) is a weighted average calculation that identies the more-recent load data has more weight in the computation. These computations are made in a time interval called the load interval. To obtain faster results (to bring the interface up faster), or when you test throughput, this interval can be altered. The 804-isdn(cong-if)#load-interval 30 command alters the load interval of any interface from the default to 30 seconds.
To make a call is one of the main functions of an ISDN router. To pass data is another major function. This function can be accompanied by frustrating performance problems, which are covered in the next scenario.
Scenario 3: ISDN Performance Problems

Usually, a user has bandwidth expectations and uses software or a tester to measure the network speed. If the service is provisioned for 2 56+D, you can expect a maximum bandwidth of 112 kbps. If the service is provisioned for 2 64+D, you can expect a maximum of 128 kbps. The user must be educated about the overall bandwidth, which needs to be distinguished from the users expectations, based on the size of his test les. Dont forget that, in ISDN, a signicant part of the frame (1/4) is used for signaling information due to the format of an ISDN frame in the S/T coding technique (PseudoTernary Line Coding) and one tenth in the U-interface coding technique (two binary, one quaternary) (see Chapter 2, Telecommunication Basics, for more information). Also, given the fact that overhead is associated with all routing and routed protocols, you should set a users expectations accordingly. Performance problems dont result immediately from these situations; instead, there is an unexpected degradation of the line speed over a period of time. The solution to this type of problem requires systematic research of all possible reasons. The problems can be caused by the following:
Short-term routing issues
377
Line problems Conguration setting problems LEC switch problems
Each issue is discussed in the following sections.
Short-Term Routing Issues

Problems due to routing are related to different aspects of the corporate network, such as routing, server hosting, server availability, and performance. Usually, problems are due to a malfunction of the intranet. A duplicate IP address can severely degrade a users performance, especially in statically assigned IP subnets, where different subnets can affect each other if there is an overlapping address space. The easiest way to discover the problem is to check the DNS and DHCP pools to determine if access is available, or ping every IP address in the subnet to see if there is a difference in the response time and the number of successful responses.
Line Problems
After you ensure the service is set up correctly and fully operational (the router can make calls), check the status of the BRI service by using the following set of very useful commands:
804-isdn#show interface bri0 804-isdn#show interfaces bri0 1 2
The detailed output for these commands is explained in Table 13-5. Before you look at this output, note some of the troubleshooting steps you can take for this category of problems:
1 Make sure that the users router is congured correctlythat it dials out and accepts
calls.
NOTE
Always clear the interfaces and counters before testing to limit results to only your actions.
2 Clear the data channels of the users router before testing by using the following
command:
804-isdn#clear interface bri0:1 804-isdn#clear interface bri0:2
NOTE
Just clearing interface bri0 brings down both channels.
378
3 From the core router or any server, run the following:

server1.cisco.com:/users/pnedeltc>PING 804-isdn 3000
If the threshold of the users router is set to 10 percent of the bandwidth, after 1520 seconds, you will see the second channel come up. Run 200 packet pings and check the statistics. If the packet loss is greater than 0 percent, a problem exists.
4 Check the information on the D channel, and the BRI0:1 and BRI0:2. Compare the
results to the output lines in Table 13-5.

5 Try a 56 K call to determine if the problem still exists. If it does, follow the
recommendations in Table 13-5, or work with the LEC to resolve the issue.
Table 13-5 Output BRI0 is up, line protocol is up (spoong) BRI0:1 is down, line protocol is down Explanation of Output from #show interface bri0 (D Channel) and #show interface bri0 1 2 (For BRI Data Channels 1 and 2) Description D channel information. It shows that the D channel is spoong and indicates that the D channel is up and the dial-on-demand is ready. Unlike BRI0:1 and BRI0:2, this interface must be up at all times for DDR to function. BRI0:1 information. The line and protocol are down, which indicates the channel is inactive and does not send or receive data. This does not mean the BRI1 is not functional. Hardware is BRI with U-interface and POTS MTU 1500 bytes BW 64 Kbit DLY 20000 usec reliability 255/255, txload 1/255, rxload 1/255 Encapsulation PPP loopback not set Hardware information that shows the router has a built-in Uinterface and supports plain old telephone service (POTS). Maximum transmit unit (MTU) is 1500 bytes. Bandwidth is 64 Kbps. The D channel in 2B+D is 64 Kbps; however, for signaling, it uses only 16 Kbps. A delay of 20,000 microseconds = 20 milliseconds. Reliability, transmit load (txload), and receive load (rxload) are a fraction of 255. The encapsulation of the interface is Point-to-Point Protocol (PPP). The loopback is not set. DTR is pulsed for 1 seconds on reset LCP Closed, multilink Closed Closed: CDPCP, IPCP The Data Terminal Ready (DTR) timer is set to 1 second. LCP and multilink can be closed or open. Cisco Discovery Protocol Control Protocol (CDPCP) and IP Control Protocol (IPCP) are part of the NCP suit and can be closed or open as well. These lines exist only for B channels.
379
Table 13-5 Output
Explanation of Output from #show interface bri0 (D Channel) and #show interface bri0 1 2 (For BRI Data Channels 1 and 2) (Continued) Description Number of hours, minutes, and seconds since the last packets were received (input) or sent (output) by this interface. This indicates hours, minutes, seconds, or never since the last reset of this interface. If the time is more than 24 hours, you see 2d3h. But if this format is not sufcient, you will see *****, which indicates that more symbols are required than this format can support. Often in troubleshooting, you need to start with fresh data. This value indicates the last time in hours:minutes:seconds (or never) that the interface counters were cleared using the command: 804-isdn#clear interface bri0:1 or bri0:2 The 804-isdn#clear interface bri0 works as a reset of the D channel and, therefore, works as a reset of the BRI interface.
Last input 00:00:24, output 00:00:24, output hang never
Last clearing of show interface counters 6d23h
Input queue: 0/75/0/0 (size/max/ drops/ ushes); Total output drops: 0 Output queue: 0/1000/64/0 (size/max total/ threshold/drops) Queuing strategy: weighted fair Conversations 0/1/16 (active/max active/max total) Reserved Conversations 0/0 (allocated/max allocated)
Input queue with self-explanatory parameters and the number of dropped packets because of a lack of queue slots. If the number of dropped packets is high, you might want to check the interface buffers with the following: 804-isdn#show buffers The queuing strategy. This entry displays the number of conversations in regards to weighted fair queuing (WFQ). If FIFO is congured on the interface, the output would just show output queue and input queue statistics.
The Following Output Is Where the Line Problems Are Reported 5 minute input rate 4200 bits/sec, 1 packets/sec 5 minute output rate 0 bits/sec, 0 packets/sec 42554 packets input, 187949 bytes, 0 no buffer Received 0 broadcasts 0 runts 0 giants The average rate of data exchange, both in and out in veminute intervals, measured in bits per second and packets per second. Number of packets and bytes passed with no errors. Number of discarded packets because theres no buffer. Total number of received broadcasts on this interface. Number of discarded packets because their size was smaller than the minimum median packet size. Number of packets that were discarded because their size was greater than the maximum median packet size. continues
380
Table 13-5 Output 0 throttles 81 input errors 1 CRC 69 frame
Explanation of Output from #show interface bri0 (D Channel) and #show interface bri0 1 2 (For BRI Data Channels 1 and 2) (Continued) Description Number of times the receiver on the port was disabled; possibly due to buffer or processor overload. Total number of input errors since the last #clear interface command. Cyclic Redundancy Check (CRC) errors usually indicate noise or other transmission problems. Incorrectly received packets, or packets with a non-integer number of octets, which usually indicates noise or other transmission problems. The number of times the input rate exceeded the receivers ability to buffer and handle the data. The number of times the hardware ran low in internal buffers. Broadcast storms and bursts of noise can be the possible cause of the problem. Number of aborts. It shows the illegal number of 1s in the interface. It is an indication of a clocking problem on the interface. (Check the U- or S/T interface cabling.) Number of output packets and bytes in the interface passed without errors. Number of times when the transmitter runs faster than the router can handle. Number of output errors. Number of collisions on the interface. The collisions can come from the contention failures Number of interface resets, which indicate no signal in the interface. The router waits ten seconds and then resets the interface trying to trigger the exchange. Number of buffer failures and swapped output buffers. Use 804-isdn#show buffers failures to check the type and the time of failures. Number of carrier transitions, which is a number that you need to divide by 2 because there are 140 ups and 140 downs in this D channel. This number in the D channel should be much smaller than the same measurement on the B channels because the B channel goes up and down to exchange data, while the D channel stays up (presumably always).
0 overrun 0 ignored
11 abort
42601 packets output, 179159 bytes 0 underruns 0 output errors 0 collisions 9 interface resets
0 output buffers failures, 0 output buffers swapped out 280 carrier transitions
381
For a Cisco 77x router, the line quality of the ISDN line can be checked with the show packets command as displayed in Example 13-7.
Example 13-7
show packets Output

776-isdn:gateway> show 2 packets Packet Statistics for Connection 2 Filtered: 0 Forwarded: 150 Received: 201 Dropped: 59 Lost: 0 Corrupted: 1 Misordered: 0 Compression Ratio: 0.99:1 IP Packet that triggered last call Source Address: 151.70.209.82 Destination Address: 151.68.10.140 Protocol: UDP Source Port: 1242 Destination Port: 53 Date/Time: 01/01/1995 00:00:47 776-isdn:gateway>
The line quality information is shown and explained in Table 13-6.

Table 13-6 Output and Description of the show packets Output From a 77x Router Output Packet statistics for Connection 2 Filtered Forwarded Received Description The packet diagnostic statistics for Link=2. Packets received by the bridge engine and not forwarded. Packets forwarded to Link=2. Packets received from Link=2.
The Following Are Where the Problems Are Reported Dropped Lost Corrupted Misordered Compression Ratio Packets received from Link=2 and dropped because the queue of packets to be forwarded was too long. Packets received from Link=2, but not successfully transmitted (faulty line). Packets received from Link=2 with bad CRC and discarded as corrupted. Packets received out of sequence when using the ordered or fragmented protocol. If using compression, it shows the compression ratio.
The line-quality issues might be only part of the problem, but theyre very signicant and can cause frustrating intermittent problems.
382
NOTE
One of the most unusual cases that I recall involved a user whose MPOE was actually a wooden cabinet in her backyard. On rainy days, her service was intermittent. But every time the LEC technician was onsite testing, everything would be ne. In the end, it turns out that, when the cabinet door was closed, it put pressure on the cable so that moisture caused intermittent connectivity. When the cabinet door was open (such as when the technician was running tests) connectivity was ne.
The interface reports should be interpreted according to the specics of the service, which can include many and different devices in the local loop. Some conguration settings in the users router can cause problems as well; they are discussed in the next section.
Conguration Setting Problems

The buffer shortage is included under interface commands and shows the number of successfully passed packets and bytes, as well as the dropped packets due to no buffer. This setting might cause performance problems. Some simple recommendations that usually work for issues caused by settings include the following:
If the number of drops increments after clearing the appropriate interfaces and running a ping test from the opposite site, determine what destination is incrementinginput or output, looking to the following lines:
Input queue: 0/75/20 (size/max/drops); Total output drops: 30 Output queue: 0/1000/64/0 (size/max total/threshold/drops)
Here, the input queue has dropped 30 packets.
If any queue drops packets, gradually increase the size of the queue by 25 percent, using either of the commands:
804-isdn(config-if)#hold-queue length out 804-isdn(config-if)#hold-queue length in
From the previous example where the input queue dropped 30 packets, you should increase the input queue size. If you see that the number of dropped packets is decreasing after repeated testing, increase the packets for further testing.
LEC Switch Problems

LEC switch problems are related to the quality of service provided by the LEC. Also, there are different departments within a LECs organization, and the troubleshooting engineer does not always have visibility to the LECs internal processes. The following is an example.
383
A user is taking an e-learning course and experiences slow performance of data and video. The user has a /30 bit (255.255.255.252) subnet assigned on one computer at homea new notebook. Here are the troubleshooting steps for this realistic scenario, and the results for this particular case:
1 Gather information from the user. In this case, a conversation with the user determines
that the connection is four months old, and has been the same from the beginning.
2 Do a quick check of the conguration, which looks correct for this scenario. The
ISDN numbers are

isdn spid1 = 56174270270100 LDN1 = 7427027 isdn spid2 = 56174270280100 LDN2 = 7427028
3 Do a quick check of the IP subnet in the DNS and DHCP server to see if it looks
correct and there is no overlapping. In this case, there is no overlapping.

4 Have the user make two calls outone from the BRI0:2 VOICE and one from BRI0:1
DATA. Assume that the router reports that the BRI0:1 makes a voice call, but the BRI0:2 is making a data call, as shown in Example 13-8. This is just the opposite of what you expect to see. Remember this!
Example 13-8

804-isdn#show isdn status Global ISDN Switchtype = basic-ni ISDN BRI0 interface dsl 0, interface ISDN Switchtype = basic-ni Layer 1 Status: ACTIVE Layer 2 Status: TEI = 123, Ces = 1, SAPI = 0, State = MULTIPLE_FRAME_ESTABLISHED TEI = 124, Ces = 2, SAPI = 0, State = MULTIPLE_FRAME_ESTABLISHED Spid Status: TEI 123, ces = 1, state = 5(init) spid1 configured, spid1 sent, spid1 valid Endpoint ID Info: epsf = 0, usid = 1, tid = 0 TEI 124, ces = 2, state = 5(init) spid2 configured, spid2 sent, spid2 valid Endpoint ID Info: epsf = 0, usid = 2, tid = 0 Layer 3 Status: 1 Active Layer 3 Call(s) Activated dsl 0 CCBs = 2 CCB:callid=8021, sapi=0, ces=1, B-chan=2, calltype=DATA ! The router reports that BRI0:1 makes a VOICE call, but the BRI0:2 is ! making a data call -- the opposite to what you would expect. ! Remember the word asymmetric. CCB:callid=8024, sapi=0, ces=1, B-chan=1, calltype=VOICE The Free Channel Mask: 0x80000000 Total Allocated ISDN CCBs = 2
384
5 Have the user download data and check the interfaces to see if they report any errors.
In this case, they dont. The input line errors are not the problem, as you can see from the following fragment from the commands show interface bri0:1 and show interface bri0:2:
609 packets input, 3440 bytes, 0 no buffer Received 0 broadcasts, 0 runts, 0 giants, 0 throttles 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
6 Check the dialer interface for errors. Under the Dialer 1 interface, you see the
following. Obviously, no input or output errors are reported and they are not the problem:
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored 0 input packets with dribble condition detected 6464 packets output, 2178130 bytes, 0 underruns 0 output errors, 0 collisions, 0 interface resets 0 babbles, 0 late collision, 14 deferred 0 lost carrier, 0 no carrier 0 output buffer failures, 0 output buffers swapped out
7 Check the error statistics for virtual interface 1 with show interface dialer 1
command. The same command provides you with great details, including the ve-minute input and output rates on this interface. Again, recall that the user is downloading data and, for some reason, the router is reporting an asymmetric performance, as shown in the following code fragment:
5 minute input rate 2000 bits/sec, 0 packets/sec 5 minute output rate 62000 bits/sec, 0 packets/sec
The most concise commands to check the Ethernet 0, Dialer, and Virtual Access 1 interfaces for certain common values is to use the output modiers of IOS, as follows: 804-isdn#show interface ethernet0 | include 5 minute 804-isdn#show interface dialer1 | include 5 minute 804-isdn#show interface virtual-access 1 | include 5 minute
8 Ask the user to upload data. The result is again the same asymmetric performance:
From the last two tests, you can conclude the tested direction is slow.
9 Do a quick check of the buffers for failures. In this case, it shows that none are present:
804-isdn#shows buffers failures
Obviously, the buffer failures are not causing any issue.

10 Due to the effect the low size of the MTU can have over the performance, check the
E0 interface and computer settings and determine if any MTU is set to less than 1500 for the download direction. In this case, the settings were determined by default. The MTU is not a problem.
385
11 Check the core router with the following:

7206-isdn#show running-config | include 804-isdn dialer map ip 10.19.236.5 name 804-isdn speed 56 15617427027
From this command, you can determine that the core router is calling SPID1, but the call is reaching SPID2. Again, you can see another instance of asymmetric behavior in this particular ISDN service.
12 Given the amount of asymmetric instances, the word asymmetric can characterize this
ISDN service. The action plan should now be to make the service symmetric by removing all asymmetric odds from the service and seeing if this corrects the problem.
13 The easiest way to correct the problem is to change the dialer map from the core router
from (SPID1), as shown here:

7206-isdn(config-if)#dialer map ip 10.19.236.5 name 804-isdn speed 56 15617427027
The core router is dialing SPID1 (15617427027). Make the core router call SPID2 (15617427028) with the following change:
7206-isdn(config-if)#dialer map ip 10.19.236.5 name 804-isdn speed 56 15617427028
14a Ask the user to download the same information from the same server, as he did in an
earlier step. You can check the virtual access interface of the users router with the following command:
804-isdn#show interface virtual-Access 1 | include 5 minute ... 5 minute input rate 40000 bits/sec, 8 packets/sec 5 minute output rate 3000 bits/sec, 3 packets/sec ...
Recall that the user is downloading. Your testing direction, looking from the remote users router, is input. If you compare Step 7 and its output with the new report, you can see that the service has improved and the input rate is increasing. Here is the output from Step 7:
5 minute input rate 2000 bits/sec, 0 packets/sec
Here is the new, improved output:

5 minute input rate 40000 bits/sec, 8 packets/sec
If the user is not available to participate in testing, you must consider how to test without him.
14b Run a ping test with a packet size of 3000 and then increase the size to 4200, as shown
here:
server1.cisco.com:/users/pnedeltc>PING 804-isdn 3000
Measure the ve-minute rate from the users router with this: 804-isdn#show interface Virtual-Access 1 | incl 5 minu
386
When testing with packet size 3000 bytes, the results are
When testing 4500 bytes, the results are

For this case, the result of these steps is that now the connection is according with the expected behavior (symmetric), the input rate is increasing, and no packet is lost, as shown in the following fragment from ping 804-isdn 3000 statistics:
----804-isdn.cisco.com PING Statistics---439 packets transmitted, 438 packets received, 0% packet loss round-trip (ms) min/avg/max = 654/659/947
This example is provided to show how the repeated observation and key impressions of an engineer who doesnt necessarily have knowledge of internal processes of the LEC can still result in resolution of problems. In this particular case, most probably, you were dealing with the way the circuit was designed by the LEC. Although these types of solutions might not have the perfect technical explanation (after all, the engineer is guessing based on his observations), they often solve the problem regardless.
Scenario 4: End-to-End Communication Problems

A typical ISDN case includes situations where the conguration is okay, the interfaces are congured correctly, and the router makes outgoing calls, but the connection is intermittent, or drops, soon after the connection is established. This scenario is one of the most difcult to troubleshoot for ISDN. As a reminder, end-to-end communications are based on the encapsulation protocol running on the BRI and dialer interfaces. Regardless of the fact that Q.931 is considered to be an end-to-end protocol (as discussed in Chapter 9, ISDN Technology Background), after a call is made, the frames are encapsulated by PPP, which takes over and manages the point-to-point and end-to-end communication. Recall that the PPP protocol has ve phases (again, for troubleshooting purposes, you might consider there being four phases). Each phase starts after the previous one is open. Every phase and every protocol in that particular phase can create problems. Therefore, if the call out does not drop in the rst three seconds, focus on PPP when youre troubleshooting. The following issues are typical for end-to-end communication problems:
The LECs ISDN switch settings Link control protocol (LCP) problems and the magic 22 seconds Authentication problems End-to-end routing problems
Each issue is discussed in the following sections.
387
The LECs ISDN Switch Settings

One of the simplest cases is when the router calls out but does not get a response. This situation is typical for new installs. The LEC is responsible for the settings of the switch. An error in the prole can create problems. The easiest way to identify a problem is by using the following:
804-isdn#debug isdn events
Search for messages with prex I: (input). If you do not have access to the users router, work with the end user to determine if the switch passes data from the core router to the users router (check the RxD lights on the router). If no data is passed, work with the LEC to correct the problem. If the remote user is extremely non-technical, this might make troubleshooting very difcult.
LCP Problems and the Magic 22 Seconds

One of the most complicated issues is when everything works correctly and the router makes calls out, but after the router disconnects, the call results in one of the following:
If the disconnect is immediately after call out (less than one second), theres either a wrong phone number or it is not provisioned for data. The error messages in Chapter 12 provide more explanations about the possible cause. If the call disconnects in two seconds, the other party is not congured to be called from this router (CHAP refused authentication) and the call is rejected. The call drops in about 22 seconds.
Because of its importance, the 22 second issue deserves more detailed analyses. This is when the conguration is okay on both sides, the calling router tries to make a call, and the switch responds with call connected, but the call then drops after 22 seconds. Looking at the problem with a 77x router, you see the output thats shown in Example 13-9.
Example 13-9
The 22 Second Issue

1. Status 01/01/1995 18:34:06 Line Status Line Activated Terminal Identifier Assigned SPID Accepted Terminal Identifier Assigned SPID Accepted Port Status Interface Connection Link Ch: 1 64K Call In Progress 20178 DATA 0 0 Ch: 2 Waiting for call ! The Connection (number) =0 and Link (number) = 0 is a typical sign. ! These values never acquire <>0 (non-zero) value. 776-isdn: SJB12A75> 01/01/1995 18:34:24 L12 1 Disconnected Remotely Cause 16 Normal Disconnect 776-isdn: SJB12A75> 01/01/1995 18:34:25 L27 1 Disconnected
continues
388
Example 13-9
The 22 Second Issue (Continued)

776-isdn: SJB12A75> 01/01/1995 18:34:33 776-isdn: SJB12A75> 01/01/1995 18:34:34 776-isdn: SJB12A75> 01/01/1995 18:34:56 Cause 16 Normal Disconnect L05 L08 L12 0 1 1 20178 Outgoing Call Initiated 20178 Call Connected Disconnected Remotely
Another important message from the output of the IOS-based ISDN router is
Jul 30 11:01:59 PDT: %ISDN-6-DISCONNECT: Interface BRI0:1 disconnected from 4086175555 , call lasted 22 seconds.
The symptoms are confusing, and checking the call messages does not provide any useful information. The indications from the switch are even more confusing because the switch reports that the call is disconnected and the reason is normal, but the end-to-end communication is not normal. To understand what is occurring, you must review the PPP protocol. As a second-layer protocol, PPP works after Q.931 is complete (the REQUEST and CONNECT messages are sent and conrmed). Once nished (the switch reports a successful connection), and the call is treated as a callout, the next phase of the PPP protocol starts, which is LCP. This protocol establishes various parameters, as described in Chapter 12, and negotiates the line parameters in a typical handshake manner. You can see outgoing requests, incoming requests, and conrmations. In one of the cases, the output of the core router, which of course is reporting the same situation, can be viewed in Example 13-10.
Example 13-10 The Output of the Core Router
7206-isdn#debug ppp negotiation Jul 30 11:01:37 PDT: %LINK-3-UPDOWN: Interface Serial2/1:3, changed state to up Jul 30 11:01:37 PDT: Se2/1:3 PPP: Treating connection as a callin ! The core accepts a call and treats it as an incoming call from a remote user. Jul 30 11:01:37 PDT: Se2/1:3 PPP: Phase is ESTABLISHING, Passive Open [0 sess, 1 load] Jul 30 11:01:37 PDT: Se2/1:3 CHAP: Using alternate hostname SJB12A75 ! The router recognizes the alternate hostname, configured under the users ! dialer interface, or the hostname, used as a username in the remote ! users configuration. Jul 30 11:01:37 PDT: Se2/1:3 LCP: State is Listen ! The LCP is open Jul 30 11:01:39 PDT: Se2/1:3 LCP: TIMEout: State Listen ! LCP state is listen Jul 30 11:01:39 PDT: Se2/1:3 CHAP: Using alternate hostname SJB12A75 Jul 30 11:01:39 PDT: Se2/1:3 LCP: O CONFREQ [Listen] id 37 len 30 ! First attempt to establish a connection (sending confirmation request OUT) Jul 30 11:01:39 PDT: Se2/1:3 LCP: AuthProto CHAP (0x0305C22305) Jul 30 11:01:39 PDT: Se2/1:3 LCP: MagicNumber 0x48430C39 (0x050648430C39) Jul 30 11:01:39 PDT: Se2/1:3 LCP: MRRU 1524 (0x110405F4) Jul 30 11:01:39 PDT: Se2/1:3 LCP: EndpointDisc 1 Local (0x130B01534E564143413031) Jul 30 11:01:41 PDT: Se2/1:3 LCP: TIMEout: State REQsent Jul 30 11:01:41 PDT: Se2/1:3 LCP: O CONFREQ [REQsent] id 38 len 30 ! Second attempt to establish a connection (sending confirmation request OUT) Jul 30 11:01:41 PDT: Se2/1:3 LCP: AuthProto CHAP (0x0305C22305)
389
Example 13-10 The Output of the Core Router (Continued)

Jul 30 11:01:41 PDT: Se2/1:3 LCP: MagicNumber 0x48430C39 (0x050648430C39) Jul 30 11:01:41 PDT: Se2/1:3 LCP: MRRU 1524 (0x110405F4) Jul 30 11:01:41 PDT: Se2/1:3 LCP: EndpointDisc 1 Local (0x130B01534E564143413031) Jul 30 11:01:43 PDT: %ISDN-6-CONNECT: Interface Serial2/1:3 is now connected to 4086174270 Jul 30 11:01:43 PDT: Se2/1:3 LCP: TIMEout: State REQsent
Skipping the exact same sequence for attempts 3 through 9, take a look at the last (10) attempt in Example 13-11.
Example 13-11 Final Attempt
... Jul Jul Jul Jul Jul 30 11:01:57 PDT: Se2/1:3 LCP: O CONFREQ [REQsent] id 46 len 30 30 11:01:57 PDT: Se2/1:3 LCP: AuthProto CHAP (0x0305C22305) 30 11:01:57 PDT: Se2/1:3 LCP: MagicNumber 0x48430C39 (0x050648430C39) 30 11:01:57 PDT: Se2/1:3 LCP: MRRU 1524 (0x110405F4) 30 11:01:57 PDT: Se2/1:3 LCP: EndpointDisc 1 Local (0x130B01534E564143413031) Jul 30 11:01:59 PDT: Se2/1:3 LCP: TIMEout: State REQsent Jul 30 11:01:59 PDT: Se2/1:3 LCP: State is Listen ! Last (10th) attempt to establish a connection ! (sending confirmation request OUT) Jul 30 11:01:59 PDT: %ISDN-6-DISCONNECT: Interface Serial2/1:3 disconnected from 4086174270 , call lasted 22 seconds ! Again, the same message for call lasted 22 seconds and as a result ! LCP: State is Closed Jul 30 11:01:59 PDT: %LINK-3-UPDOWN: Interface Serial2/1:3, changed state to down Jul 30 11:01:59 PDT: Se2/1:3 LCP: State is Closed Jul 30 11:01:59 PDT: Se2/1:3 PPP: Phase is DOWN [0 sess, 1 load]
The same output can be seen from both ends of the connection; the time interval should match. The interval between 2 consecutive attempts might vary, but every attempt takes about 2 seconds (see the timestamps). So, 10 attempts with 2 seconds for each, 1 second at the beginning, and 1 at the end is equivalent to 22 seconds. These parameters are adjustable, but theres no guarantee that if you use non-default parameters, its going to work. Its recommended to use the default parameters and investigate further. The same case using a 77x scenario results in 8 attempts, and the interval is a little less than 3 seconds. In order for LCP to be successful and to report the LCP phase open, both parties expect an incoming message conrming the parameters from each other, which looks like the following:
Jul 30 11:12:21 PDT: Se2/1:5 LCP: I CONFACK [ACKsent] [REQsent] id 118 len 8,
390
The previous line indicates the conrmation acknowledgement and the expected output from this command is shown in Example 13-12.
Example 13-12 LCP Is Successfully Opened
Jul 30 11:12:20 PDT: %LINK-3-UPDOWN: Interface Serial2/1:5, changed state to up Jul 30 11:12:20 PDT: Se2/1:5 PPP: Treating connection as a callin Jul 30 11:12:20 PDT: Se2/1:5 PPP: Phase is ESTABLISHING, Passive Open [0 sess, 0 load] Jul 30 11:12:20 PDT: Se2/1:5 CHAP: Using alternate hostname SJB12A75 Jul 30 11:12:20 PDT: Se2/1:5 LCP: State is Listen Jul 30 11:12:21 PDT: Se2/1:5 LCP: I CONFREQ [Listen] id 1 len 36 Jul 30 11:12:21 PDT: Se2/1:5 LCP: MRU 1522 (0x010405F2) Jul 30 11:12:21 PDT: Se2/1:5 LCP: AuthProto CHAP (0x0305C22305) Jul 30 11:12:21 PDT: Se2/1:5 LCP: MagicNumber 0x00119790 (0x050600119790) Jul 30 11:12:21 PDT: Se2/1:5 LCP: MRRU 1800 (0x11040708) Jul 30 11:12:21 PDT: Se2/1:5 LCP: EndpointDisc 3 0040.f913.abc8 (0x1309030040F913ABC8) Jul 30 11:12:21 PDT: Se2/1:5 LCP: LinkDiscriminator 5578 (0x170415CA) Jul 30 11:12:21 PDT: Se2/1:5 CHAP: Using alternate hostname SJB12A75 Jul 30 11:12:21 PDT: Se2/1:5 LCP: O CONFREQ [Listen] id 118 len 30 Jul 30 11:12:21 PDT: Se2/1:5 LCP: AuthProto CHAP (0x0305C22305) Jul 30 11:12:21 PDT: Se2/1:5 LCP: MagicNumber 0x484CD7F7 (0x0506484CD7F7) Jul 30 11:12:21 PDT: Se2/1:5 LCP: MRRU 1524 (0x110405F4) Jul 30 11:12:21 PDT: Se2/1:5 LCP: EndpointDisc 1 Local (0x130B01534E564143413031) Jul 30 11:12:21 PDT: Se2/1:5 LCP: O CONFREJ [Listen] id 1 len 8 Jul 30 11:12:21 PDT: Se2/1:5 LCP: LinkDiscriminator 5578 (0x170415CA) Jul 30 11:12:21 PDT: Se2/1:5 LCP: I CONFNAK [REQsent] id 118 len 8 Jul 30 11:12:21 PDT: Se2/1:5 LCP: MRU 1522 (0x010405F2) Jul 30 11:12:21 PDT: Se2/1:5 LCP: O CONFREQ [REQsent] id 119 len 30 Jul 30 11:12:21 PDT: Se2/1:5 LCP: AuthProto CHAP (0x0305C22305) Jul 30 11:12:21 PDT: Se2/1:5 LCP: MagicNumber 0x484CD7F7 (0x0506484CD7F7) Jul 30 11:12:21 PDT: Se2/1:5 LCP: MRRU 1524 (0x110405F4) Jul 30 11:12:21 PDT: Se2/1:5 LCP: EndpointDisc 1 Local (0x130B01534E564143413031) Jul 30 11:12:21 PDT: Se2/1:5 LCP: I CONFREQ [REQsent] id 2 len 32 Jul 30 11:12:21 PDT: Se2/1:5 LCP: MRU 1522 (0x010405F2) Jul 30 11:12:21 PDT: Se2/1:5 LCP: AuthProto CHAP (0x0305C22305) Jul 30 11:12:21 PDT: Se2/1:5 LCP: MagicNumber 0x00119790 (0x050600119790) Jul 30 11:12:21 PDT: Se2/1:5 LCP: MRRU 1800 (0x11040708) Jul 30 11:12:21 PDT: Se2/1:5 LCP: EndpointDisc 3 0040.f913.abc8 (0x1309030040F913ABC8) Jul 30 11:12:21 PDT: Se2/1:5 LCP: O CONFACK [REQsent] id 2 len 32 Jul 30 11:12:21 PDT: Se2/1:5 LCP: MRU 1522 (0x010405F2) Jul 30 11:12:21 PDT: Se2/1:5 LCP: AuthProto CHAP (0x0305C22305) Jul 30 11:12:21 PDT: Se2/1:5 LCP: MagicNumber 0x00119790 (0x050600119790) Jul 30 11:12:21 PDT: Se2/1:5 LCP: MRRU 1800 (0x11040708) Jul 30 11:12:21 PDT: Se2/1:5 LCP: EndpointDisc 3 0040.f913.abc8 (0x1309030040F913ABC8) Jul 30 11:12:21 PDT: Se2/1:5 LCP: I CONFACK [ACKsent] id 119 len 30 Jul 30 11:12:21 PDT: Se2/1:5 LCP: AuthProto CHAP (0x0305C22305) Jul 30 11:12:21 PDT: Se2/1:5 LCP: MagicNumber 0x484CD7F7 (0x0506484CD7F7)
391
Example 13-12 LCP Is Successfully Opened (Continued)

Jul 30 11:12:21 PDT: Se2/1:5 LCP: MRRU 1524 (0x110405F4) Jul 30 11:12:21 PDT: Se2/1:5 LCP: EndpointDisc 1 Local (0x130B01534E564143413031) Jul 30 11:12:21 PDT: Se2/1:5 LCP: State is Open ! Finally the LCP is successfully opened.
Another type of the same problem is when both parties try to establish the LCP parameters and still cannot establish a connection, although both parties exchange messages. If you trigger the router to make a call out with the following command and you have the #debug ppp negotiation command on, you see the ping unsuccessful:
804-isdn#ping 151.68.10.70
The output from the debug command will appear as displayed in Example 13-13.
Example 13-13 debug ppp negotiation Output
*Aug 22 09::04:21.823: %LINK-3-UPDOWN: Interface BRI0:1, changed state to up *Aug 22 09::04:21.843: %ISDN-6-CONNECT: Interface BRI0:1 is now connected to 14087320178 . *Aug 22 09::04:21.847: BR0:1 PPP: Treating connection as a callout *Aug 22 09::04:21.847: BR0:1 PPP: Phase is ESTABLISHING, Active Open *Aug 22 09::04:21.851: BR0:1 LCP: O CONFREQ [Closed] id 12 len 35 *Aug 22 09::04:21.851: BR0:1 LCP: AuthProto CHAP (0x0305C22305) *Aug 22 09::04:21.851: BR0:1 LCP: MagicNumber 0xB0C6897B (0x0506B0C6897B) *Aug 22 09::04:21.855: BR0:1 LCP: MRRU 1524 (0x110405F4) *Aug 22 09::04:21.855: BR0:1 LCP: EndpointDisc 1 Local (0x13100172626561756368652D6973646E) ! The remote user requests confirmation for the first time ! See the O CONFREQ message *Aug 22 09::04:23.623: BR0:1 LCP: I CONFREQ [REQsent] id 41 len 30 *Aug 22 09::04:23.623: BR0:1 LCP: AuthProto CHAP (0x0305C22305) *Aug 22 09::04:23.627: BR0:1 LCP: MagicNumber 0xBE47D746 (0x0506BE47D746) *Aug 22 09::04:23.627: BR0:1 LCP: MRRU 1524 (0x110405F4) *Aug 22 09::04:23.627: BR0:1 LCP: EndpointDisc 1 Local (0x130B01534E564143413031) ! The core router requests confirmation for the first time ! See the I CONFREQ message *Aug 22 09::04:23.631: BR0:1 LCP: O CONFACK [REQsent] id 41 len 30 *Aug 22 09::04:23.631: BR0:1 LCP: AuthProto CHAP (0x0305C22305) *Aug 22 09::04:23.63.5: BR0:1 LCP: MagicNumber 0xBE47D746 (0x0506BE47D746) *Aug 22 09::04:23.635: BR0:1 LCP: MRRU 1524 (0x110405F4) *Aug 22 09::04:23.635: BR0:1 LCP: EndpointDisc 1 Local (0x130B01534E564143413031) *Aug 22 09::04:23.851: BR0:1 LCP: TIMEout: State ACKsent ! The remote user confirms with O CONFAK, but the process times out ! First time, because there is no confirmation from the core router *Aug 22 09::04:23.851: BR0:1 LCP: O CONFREQ [ACKsent] id 13 len 35 *Aug 22 09::04:23.851: BR0:1 LCP: AuthProto CHAP (0x0305C22305) *Aug 22 09::04:23.855: BR0:1 LCP: MagicNumber 0xB0C6897B (0x0506B0C6897B)
continues
392
Example 13-13 debug ppp negotiation Output (Continued)

*Aug 22 09::04:23.855: BR0:1 LCP: MRRU 1524 (0x110405F4) *Aug 22 09::04:23.855: BR0:1 LCP: EndpointDisc 1 Local (0x13100172626561756368652D6973646E) ! The remote user requests confirmation again ! Second time see O CONFREQ message *Aug 22 09::04:25.623: BR0:1 LCP: I CONFREQ [ACKsent] id 42 len 30 *Aug 22 09::04:25.623: BR0:1 LCP: AuthProto CHAP (0x0305C22305) *Aug 22 09::04:25.627: BR0:1 LCP: MagicNumber 0xBE47D746 (0x0506BE47D746) *Aug 22 09::04:25.627: BR0:1 LCP: MRRU 1524 (0x110405F4) *Aug 22 09::04:25.627: BR0:1 LCP: EndpointDisc 1 Local (0x130B01534E564143413031) ! The core router requests confirmation for the second time ! See I CONFREQ for the second time <output omitted> *Aug 22 09::04:39.863: BR0:1 LCP: O CONFREQ [ACKsent] id 21 len 35 *Aug 22 09::04:39.863: BR0:1 LCP: AuthProto CHAP (0x0305C22305) *Aug 22 09::04:39.867: BR0:1 LCP: MagicNumber 0xB0C6897B (0x0506B0C6897B) *Aug 22 09::04:39.867: BR0:1 LCP: MRRU 1524 (0x110405F4) *Aug 22 09::04:39.867: BR0:1 LCP: EndpointDisc 1 Local (0x13100172626561756368652D6973646E) *Aug 22 09::04:41.623: BR0:1 LCP: I CONFREQ [ACKsent] id 50 len 30 *Aug 22 09::04:41.623: BR0:1 LCP: AuthProto CHAP (0x0305C22305) *Aug 22 09::04:41.623: BR0:1 LCP: MagicNumber 0xBE47D746 (0x0506BE47D746) *Aug 22 09::04:41.627: BR0:1 LCP: MRRU 1524 (0x110405F4) *Aug 22 09::04:41.627: BR0:1 LCP: EndpointDisc 1 Local (0x130B01534E564143413031) *Aug 22 09::04:41.631: BR0:1 LCP: O CONFACK [ACKsent] id 50 len 30 *Aug 22 09::04:41.631: BR0:1 LCP: AuthProto CHAP (0x0305C22305) *Aug 22 09::04:41.635: BR0:1 LCP: MagicNumber 0xBE47D746 (0x0506BE47D746) *Aug 22 09::04:41.635: BR0:1 LCP: MRRU 1524 (0x110405F4) *Aug 22 09::04:41.635: BR0:1 LCP: EndpointDisc 1 Local (0x130B01534E564143413031) *Aug 22 09::04:41.863: BR0:1 LCP: TIMEout: State ACKsent ! The same message TIMEout: Stare ACKsent for the 10th time *Aug 22 09::04:41.863: BR0:1 LCP: O CONFREQ [ACKsent] id 22 len 35 *Aug 22 09::04:41.863: BR0:1 LCP: AuthProto CHAP (0x0305C22305) *Aug 22 09::04:41.867: BR0:1 LCP: MagicNumber 0xB0C6897B (0x0506B0C6897B) *Aug 22 09::04:41.867: BR0:1 LCP: MRRU 1524 (0x110405F4) *Aug 22 09::04:41.867: BR0:1 LCP: EndpointDisc 1 Local (0x13100172626561756368652D6973646E) *Aug 22 09::04:43.731: %ISDN-6-DISCONNECT: Interface BRI0:1 disconnected from 1408735555 gateway, call lasted 22 seconds *Aug 22 09::04:43.731: %LINK-3-UPDOWN: Interface BRI0:1, changed state to down *Aug 22 09::04:43.751: BR0:1 LCP: State is Closed *Aug 22 09::04:43.751: BR0:1 PPP: Phase is DOWN The state LCP: State is Open cannot be reached.
The messages call lasted 22 second and The state LCP: State is Open cannot be reached indicate that the LCP phase cannot be established. The missing message here is the
393
incoming message, I CONFACK [ACKsent], which will conrm that the core router has agreed on parameters that the remote user was proposing. Here are two important questions to ask when troubleshooting LCP problems:
Is only one user affected or are multiple users affected? Whats causing the problem?
The answer to the rst question will focus your analysis to either the remote users set of problems or to the core router and its set of issues. To answer the second question, you need to investigate at least three problem cases:
56/64 speed problem Cable mapping problem Trunk problem
The 56/64 case is related to the 56/64 Kbps settings. In general, it is recommended that 56 kbps be dened and applied as part of the dialer interface or class, to see if it makes a difference. This is especially useful in rural areas or when the circuit runs through old types of switches. The cable mapping case is related to one of the new features of IOS, called Non-Facility Associated Signaling (NFAS) groups that are a typical set-up for core routers. These groups are comprised of some T1s/PRIs grouped in a way that every single PRI has 24 available data channels and is congured as 24B. Two data channels of the PRIs in the group are designated for D channels and are called primary and backup D channels. They are congured as 23B+D. The other channels are called members, as shown in Example 13-14.
Example 13-14 show isdn nfas group 0 Output
7206-isdn#show isdn nfas group 0 ISDN NFAS GROUP 0 ENTRIES: The primary D is Serial2/0:23. The backup D is Serial2/1:23. The NFAS member is Serial2/2:23. The NFAS member is Serial2/3:23. The NFAS member is Serial3/0:23. The NFAS member is Serial3/1:23. The NFAS member is Serial3/2:23. The NFAS member is Serial3/3:23. There are 8 total nfas members. There are 190 total available B channels. The primary D-channel is DSL 0 in state IN SERVICE. The backup D-channel is DSL 1 in state STANDBY. The current active layer 2 DSL is 0. 7206-isdn#
Now, recall that the D channel uses TDM technology. One of the features of TDM is that it denes a slot for every data channel (trunk), and an empty slot cannot be used by another.
394
Also, its important to note the calls hit a single or NFAS circuit in a particular order (for example Serial1/0, Serial1/1, and Serial2/0). As soon as the rst circuit in the switch is in state=2 (busy), the calls roll to available trunks of member circuits. The hunting order set up by the telco should also be known. If its set up as rst available, troubleshooting is easier. But sometimes, the telco uses other hunting methods, such as least busy or round robin, to help spread the calls out and give the modems less of a duty cycle. It is important to ensure the correct mapping of the circuits between the telco switch conguration and core router conguration. If the cable mapping is mismatched, the calls dont hit the core router in the way the ISDN switch sends them. The TDM cannot handle the D channel signaling correctly and a problem occurs. Monitoring the calls for long periods of time show the call order and it does not usually match the expected order. The easiest way to identify a NFAS group is to disconnect one of the circuits and determine if some of the others are affected. If the cabling is correctly set up, this should not affect any other member of the group, but if there is a mapping problem, you will see at least one of the other members of the group affected. The correct way of setting up the NFAS group and cable mapping is explained in Chapter 6. The nal case is the trunk misconguration problem. If it is in the remote users side, you need to troubleshoot the users service. If the core side is affected, here is what happens. Typically, a group of users is trying to connect to the core router, but they have only a 20 percent success rate. As soon as they connect, they can exchange data, but the initial connect rate is low. Sometimes, users are disconnected in the middle of the session. Here is a typical case for a group of remote users experiencing this problem. After discussing the problem with the end users, you might conclude it is more common during the early morning, and the success rate is higher later at night. It is confusing because no solid pattern or trend exists. When reviewing the core router information, all users call Serial interface 2/1. So, here is the plan of action. The rst thing to do is check the serial 2/1:23, which is the D channel of this interface, as shown in Example 13-15.
Example 13-15 show interface serial2/1:23 Output
3640-isdn#show interface serial2/1:23 Serial2/1:23 is up, line protocol is up (spoofing) Hardware is DSX1 Description: SJB12A75 72HCQA123132-001 408-732-5555 MTU 1500 bytes, BW 64 Kbit, DLY 20000 usec, reliability 255/255, txload 1/255, rxload 1/255 Encapsulation PPP, loopback not set DTR is pulsed for 1 seconds on reset Last input 00:00:25, output 00:27:47, output hang never Last clearing of show interface counters 1w2d Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0 Queuing strategy: weighted fair Output queue: 0/1000/64/0 (size/max total/threshold/drops)
395
Example 13-15 show interface serial2/1:23 Output (Continued)

Conversations 0/1/16 (active/max active/max total) Reserved Conversations 0/0 (allocated/max allocated) Available Bandwidth 48 kilobits/sec 5 minute input rate 0 bits/sec, 0 packets/sec 5 minute output rate 0 bits/sec, 0 packets/sec 93069 packets input, 847750 bytes, 0 no buffer Received 0 broadcasts, 0 runts, 0 giants, 0 throttles 9501 input errors, 9010 CRC, 400 frame, 0 overrun, 0 ignored, 31 abort 93069 packets output, 738440 bytes, 0 underruns 0 output errors, 0 collisions, 0 interface resets 0 output buffer failures, 0 output buffers swapped out 0 carrier transitions Timeslot(s) Used:24, Transmitter delay is 0 flags 3640-isdn#
If the router reports a high number of errors, you might suggest that it is line quality related. However, there is no signicant amount of aborts on the line. The line is not apping (0 carrier transitions on Serial 2/1:23), and the errors are mainly format errors. You need to nd out what is causing the problem and why is it worse in the morning hours versus evening hours. One of the most amazing stories about troubleshooting Ive ever encountered was a 3 PM ISDN problem. The connection was ne, except at 3 PM every day, when the connection went down for 15 or 20 minutes. It so happened that the local loop was built under a nearby runway and every day, on schedule, a heavy Hercules aircraft would take off from that runway, which affected the connection for 15 to 20 minutes. The second thing to do is to nd a pattern. Testing with the LEC, trunk by trunk, does not provide any resolution or clues to the nature of the problem. To nd a pattern, one of the possible actions here is to take a closer look at the calls, when the remote users are trying to connect to the core routers circuit Serial 2/1. In this case, the following debug commands are recommended:
#debug isdn events #debug ppp negotiation
NOTE
From the output, you can see that the call failures occur on Serial2/0:0, Serial2/0:1, and Serial2/0:2. You must determine why users calling these channels are experiencing intermittent connections. Reviewing the circuit, you can see up to ve users in the morning, but a fully used circuit late in the afternoon. After monitoring the calls of all users, you identify that sometimes some users are connected for a long time, and sometimes the same users are experiencing disconnects. It looks like its not user related, but trunk (channel) related. You must determine if and which channels cause the disconnects. After a period of monitoring, you determine that the disconnects always result from the same Serial2/0:0 to
396
Serial2/0:4, and the problem is denitely not user related, but channel related. But, if this is the case, why are the disconnects typical for early hours and the success rate higher for late hours? The explanation is simple. When the users are experiencing the problem connect in the early morning, they usually connect to the rst channels because there are few requests. When they connect at night, more users are connected, and as soon as the monitored users are connected to the higher channels (trunks), they are okay. The last step is the resolution of this case. Obviously, the rst 5 channels of this particular PRI are failing. The solution is to either redene the circuit from 23B+D to 18B+D, or busy out the rst 5 trunks while working with the LEC to correct. After a few days, you need to check the Serial2/0:23 and you should see no errors, as shown in the following fragment:
... 93069 packets input, 847750 bytes, 0 no buffer Received 0 broadcasts, 0 runts, 0 giants, 0 throttles 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort ...
NOTE
Remember that when you are troubleshooting the core router, a signicant amount of output is generated by such commands as debug isdn events and debug ppp negotiations. These debugs can lead to unexpected conditions on the router. The bad news for you will be that you will see more information than is relevant to your particular test plan (in the previous case, the D channel of the serial interface 2/1:23). More helpful will be to apply conditions for the debugging, such as debug condition interface serial s2/0:23. After that, you can type debug isdn events and the router reports only the ISDN events on the serial 2/0:23.
The nal activity is to nish your work with the LEC, xing the trunks or replacing malfunctioning devices.
Authentication Problems
Before discussing authentication problems, its important to follow the next rule of the thumb in authentication: Establish the basic IP connectivity prior to implementing any authentication. Verify that the link works, then secure it. The authentication problems are easier to resolve when used in an enterprise environment. Two basic solutions are available:
Local authentication is used where the username (host name) and the password are dened in the particular box to which the remote user is trying to connect:
397
username 804-isdn password 7 11456A0119461B02456B
The previous statement is necessary in the core router to locally dene the user.
TACACS+ authentication is performed in a designated server.
A detailed description of core routers TACACS+ conguration is provided in Chapter 6 and applies to ISDN as well. In the TACACS+ server, every user has a prole (record). A sample of a user prole in the TACACS+ server is shown in Example 13-16.
Example 13-16 Sample of a User Prole in the TACACS+ Server
User Profile Information user = 804-isdn{ profile_id = 5483 profile_cycle = 1 password = chap ******** service=ppp { default attribute=permit allow .* .* .* protocol=ip { set addr=10.19.28.137 set routing=true set route#1=10.19.28.136 255.255.255.252 10.19.28.137 default attribute=permit } protocol=multilink { default attribute=permit } protocol=ccp { default attribute=permit } protocol=lcp { default attribute=permit } }
More discussion about authentication can be seen in Chapter 6 and Chapter 20. Visit Cisco.com for more detailed discussion and conguration examples. For either of these solutions, you need to know what options are available for authentication. PPP authentications follows the LCP stage of the PPP protocol, where you need to receive LCP OPEN, before authentication takes place. The options for PPP authentication are as follows:
ppp authentication chap ms-chap pap [callback] [callin] [callout] [optional]
NOTE
398
The following steps are recommended when troubleshooting authentication problems. First, make sure you have the encapsulation type and authentication types dened properly under the BRI and dialer interfaces from both sides:
encapsulation ppp ppp authentication chap
Second, use the debug command to monitor the authentication process:

3640-isdn#debug ppp negotiation
After the LCP is open, the expected output should look like the output shown in Example 13-17.
Example 13-17 Output After the LCP Is Open
Jul Jul Jul Jul Jul 30 11:12:21 PDT: Se2/1:5 LCP: I CONFACK [ACKsent] id 119 len 30 30 11:12:21 PDT: Se2/1:5 LCP: AuthProto CHAP (0x0305C22305) 30 11:12:21 PDT: Se2/1:5 LCP: MagicNumber 0x484CD7F7 (0x0506484CD7F7) 30 11:12:21 PDT: Se2/1:5 LCP: MRRU 1524 (0x110405F4) 30 11:12:21 PDT: Se2/1:5 LCP: EndpointDisc 1 Local (0x130B01534E564143413031) Jul 30 11:12:21 PDT: Se2/1:5 LCP: State is Open ! The LCP opens successfully, PPP negotiation starts Jul 30 11:12:21 PDT: Se2/1:5 PPP: Phase is AUTHENTICATING, by both [0 sess, 0 load] Jul 30 11:12:21 PDT: Se2/1:5 CHAP: Using alternate hostname SJB12A75 Jul 30 11:12:21 PDT: Se2/1:5 CHAP: O CHALLENGE id 33 len 29 from SJB12A75 Jul 30 11:12:21 PDT: Se2/1:5 CHAP: I CHALLENGE id 1 len 34 from 804-isdn !One pair exchanged - Input and Output Jul 30 11:12:21 PDT: Se2/1:5 CHAP: Waiting for peer to authenticate first Jul 30 11:12:21 PDT: Se2/1:5 CHAP: I RESPONSE id 33 len 34 from 804-isdn Jul 30 11:12:21 PDT: Se2/1:5 CHAP: O SUCCESS id 33 len 4 Jul 30 11:12:21 PDT: Se2/1:5 CHAP: Processing saved Challenge, id 1 Jul 30 11:12:21 PDT: Se2/1:5 CHAP: Using alternate hostname SJB12A75 ! Second pair exchanged Input and Output Jul 30 11:12:21 PDT: Se2/1:5 CHAP: O RESPONSE id 1 len 29 from SJB12A75 Jul 30 11:12:21 PDT: Se2/1:5 CHAP: I SUCCESS id 1 len 36 msg is chap: User SJB12A75 authorized. ! Last pair exchanged - I and O Jul 30 11:12:21 PDT: Se2/1:5 PPP: Phase is VIRTUALIZED [0 sess, 0 load]
There are two SUCCESS messages, and the message Phase is VIRTUALIZED ends the process. Finally, check the way the passwords are congured. Two things are important here:
The username in the global conguration of the remote users router must match the CHAP of the core router. The example includes the host name of the dialer interface of the core router is SJB12A75. This means, for the general conguration mode of the remote users router, you must have a line starting with 804-isdn#username
Scenario 5: Windows 2000 DDR Issue
399
SJB12A75 password, and the core router must have an authentica-tion part reecting the host name of the remote user804-isdn.
The passwords from both sides must be the same. If the password from the core router is 11456A0119461B02456B (encrypted), or the word secret (unencrypted), you can congure the remote users router with the following:
804-isdn(config)#username SJB12A75 password secret
Remember that the host names are case sensitive, so when typing or comparing, make sure that the passwords match.
End-to-End Routing Problems

The routing problems are often related to conguration rules and errors. The rst type of problem arises when no default gateway is congured, or it is miscongured. The rule to follow is the default gateway must point to the local routers Ethernet interface. One example is when the local DHCP is dened and part of that denition is the default gateway, as shown in Example 13-18.
Example 13-18 The Local DHCP Is Dened and Part of that Denition Is the Default Gateway
ip dhcp pool ippool network 10.70.209.80 255.255.255.248 dns-server 20.68.10.70 20.68.10.140 netbios-name-server 20.68.235.228 20.69.2.87 domain-name cisco.com default-router 10.70.209.81 lease infinite !
The second case is when there is no route to a remote network. To check if a particular IP address is in the routing table, you can use the command line:
804-isdn#show ip route 10.20.30.40
If the message returned is % Network not in table, you need to dene a static route to the remote partys IP address. See the Cisco IOS Conguration Guide for more details.

This scenario covers DDR and the possible issues with interesting trafc that triggers the router to dial out. In general, the DDR congurations, discussed in detail in Chapter 11, is straightforward. They are usually based on the assumption that the environment is designed and established, and includes certain hardware and software. All potential users, processes, and events are
400
well known and the conguration is a reection of policies, techniques, and rules. Two major conventional conguration settings are described in this scenario: the dialer-list command and the access control list (ACL). The syntax of the dialer-list command is
dialer-list dialer-group protocol protocol {permit | deny | list access-list-number}
You must consider what happens when a major change occurs in the environment, such as the addition of new hardware and technology. Typical cases include a new operating system (OS) or a new wireless access points being deployed in the enterprise. This is always a challenge; the DDR must be re-evaluated to meet the new requirement. This is the case (controversy) with a new Microsoft Windows 2000 platform and Cisco DDR. The problem is that, according to monitoring and billing information, if an idle Windows 2000 (W2K)-based computer is connected to the router, the trafc can increase by as much 60 percent or more, and the number and duration of calls also increases from a reasonable 3 to 4 hours/day to almost 23 to 24 hours/day. For usage-based ISDN charges, this can increase the monthly charges by 10 to 20 times or more. In this case, the major challenge is to transform the interesting trafc to uninteresting to the router in a way that guarantees the interoperability of the devices connected to the routers, and at the same time, not prevent the W2K-based platforms from operating. The process is iterative. You should follow four easy steps:
Step 1 Read everything available about the new product to be connected to the
Cisco router. Try to understand the underlying concept for it and its implications on DDR. Implement the manufacturers recommendations and determine if they are effective.
Step 2 Monitor and sniff all trafc and try to nd patterns and characteristics of
the trafc.
Step 3 Use a Cisco knowledge base to remedy any identied problems. Step 4 Select a solution and test it. Depending on the results, return to Steps 1,
2, or 3 if necessary. Now, follow the steps to determine if they provide the necessary x for DDR.
Step 1: Implement the Manufacturers Recommendations and Determine if They Are Effective
The information provided by Microsoft about the problem and possible remedies can be found at http://support.microsoft.com/directory/overview.asp. Generally speaking, this problem is a legacy issue carried over from Windows NT. It is based on certain periodic exchanges between the workstation and the server. At the URL just given, you can nd that Microsoft recognizes the signicance of the problem and points to four major factors contributing in the issue:
401
Keeping the ISDN line up to ensure interoperability of Windows OS. The directory service client code was changed so that queries are issued once an hour. WAN trafc distribution of group policies. Browsing and other trafc incurs a high cost over ISDN routers. Periodic retransmit times for packets.
A more careful review of the explanations shows that more issues contribute to the problem, including domain browsing, Windows Internet Name Service (WINS) replication, directory replication, user accounts database (SAM) replication, printer browsing, and so on. All periodic retransmissions can be broken down, as Table 13-7 shows.
Table 13-7 Periodic Retransmissions Packet Type NetLogon Browse Protocol SMB SMB Transport TCP/IP & NetBEUI TCP/IP & NetBEUI Interval 300 seconds 300 seconds (Windows NT 3.1) 720 seconds (Windows NT 3.5x) KeepAlive SessionAlive Poll/Final KeepAlive Echo SMB NetBIOS NetBIOS LLC NetBIOS SMB TCP/IP NetBEUI NetBEUI IPX Direct Host IPX 60 minutes (Windows NT 3.5x) 30 seconds (LAN Manager) 30 seconds (or ACK to Poll) 30 seconds 240 seconds
In general, the recommendation is to check and change the following registry settings: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NetBT\Parameters For Windows 2000, the following data type is a string value that species the number of times the system will retry NetBIOS name query broadcasts. The default is 3: BcastNameQueryCount = integer Data Type: DWORD For Windows 2000, the following data type is a string value that species the period of time that the system will wait before timing out broadcast name queries. The minimum value is 100, and the default is 750: BcastQueryTimeout = milliseconds Data Type: DWORD For Windows 2000, the following data type is a string value that species how long NetBIOS names are cached. The minimum is 60,000 milliseconds (1 minute) and the default is 360,000 milliseconds (6 minutes):
402
CacheTimeout = milliseconds Data Type: DWORD For Windows 2000, the following data type is a string value that species the UDP port on the name server to send name queries or registrations. The default is 137: NameServerPort = port Data Type: DWORD The following value species the number of times the system will try to contact the WINS server for NetBIOS name resolution. The default is 3: NameSrvQueryCount = integer Data Type: String For Windows 98, the following data type is a string value that species how long the system waits before timing out a name server query. The minimum is 100 and the default is 750: NameSrvQueryTimeout = milliseconds Data Type: DWORD For Windows 2000, the following data type is a string value that species how often to send session keepalive packets on active sessions. The minimum is 60 seconds and the default is 3600 seconds (1 hour): SessionKeepAlive = milliseconds Data Type: DWORD For Windows 2000, the following data type is a string value that species how many buffers of various types to preallocate, and the maximum that can be allocated, where 1 = small, 2 = medium, and 3 = large. The default is 1, but if the WINS proxy is enabled, the default is 3: Size/Small/Medium/Large = 1, 2, or 3 Data Type: DWORD
Step 2: Monitor and Sniff All Trafc and Try to Find Patterns and Characteristics of the Trafc
This part is the most important. It can sometimes take days or months, and hundreds of pages of sniffer information, logs, and analysis. Some examples follow. When analyzing the service and processes of Windows 2000, you can establish that a service automatically runs as soon as you start the computer. It is called remote procedure call (RPC) and provides the endpoint mapper and other miscellaneous RPC services. Snifng the trafc shows the role of RPC in keeping the ISDN line up. The contribution of TCP/IDP port 111 (Cisco keyword sunrpc) is signicant and generates more than 19 percent of the additional trafc. In general, your rst contributor for this extra ISDN-trafc situation is RPC (TCP/UDP port 111).
403
For the snifng purposes, its good to know some of the protocol numbers, shown in Table 13-8.
Table 13-8 Protocol Numbers Service Internet Control Message Protocol (ICMP) Transmission Control Protocol (TCP) User Datagram Protocol (UDP) General Routing Encapsulation (PPTP data over GRE) Authentication Header (AH) IPSec Encapsulation Security Payload (ESP) IPSec Exterior Gateway Protocol (EGP) Gateway-Gateway Protocol (GGP) Host Monitoring Protocol (HMP) Internet Group Management Protocol (IGMP) MIT Remote Virtual Disk (RVD) Open Shortest Path First (OSPF) PARC Universal Packet Protocol (PUP) Reliable Datagram Protocol (RDP) Reservation Protocol (RSVP) QoS Protocol Independent Multicast (PIM) Protocol Number 1 6 16 47 51 50 8 3 20 88 66 89 12 27 46 103
Also for snifng (and not only snifng purposes), it is useful to know the TCP/UDP port numbers. Ports are used in TCP (RFC 793) to name the ends of logical connections that carry long-term conversations. For providing services to unknown callers, a service contact port is dened. This list species the port used by the server process as its contact port. These port numbers are divided into three ranges:
Well-known ports range from 0-1023 Registered ports range from 1024-49151 Dynamic and/or private ports range from 49152-65535
Well-known ports are controlled and assigned by the Internet Assigned Numbers Authority (IANA). The IANA is now called American Registry for Internet Numbers (ARIN) and, on most systems, can be used only by the system (or root) processes or by programs executed by privileged users. Table 13-9 shows some of the well-known ports.
404
Table 13-9
Some of the Most Important Port Numbers Port Number 0 1-4 5 7 9 Port Type TCP & UDP TCP & UDP TCP & UDP TCP & UDP TCP & UDP Protocol Reserved Unassigned Remote Job Entry Echo Discard RJE ECHO DISCARD continues 11 13 15 16 19 20 21 23 25 37 39 42 43 49 53 67 68 69 70 75 77 79 80 87 88 TCP & UDP TCP & UDP TCP & UDP TCP & UDP TCP & UDP TCP & UDP TCP & UDP TCP & UDP TCP & UDP TCP & UDP TCP & UDP TCP & UDP TCP & UDP TCP & UDP TCP & UDP TCP & UDP TCP & UDP TCP & UDP TCP & UDP TCP & UDP TCP & UDP TCP & UDP TCP & UDP TCP TCP & UDP Active Users Daytime Who is up or Netstat Quote of the Day Character Generator File Transfer (Default Data) File Transfer (Control) Telnet Simple Mail Transfer Protocol Time Resource Location Protocol Host Name Server Who Is Terminal Access Controller Access Cntrl Sys. Domain Name Server Bootstrap Protocol Server Bootstrap Protocol Client Trivial File Transfer Protocol Gopher Any private dial-out service Any private RJE service Finger Hypertext Transfer Protocol (HTTP) Linkcommonly used by intruders Kerberos KERBEROS FINGER www USERS DAYTIME NETSTAT QUOTE CHARGEN FTP-DATA FTP TELNET SMTP TIME RLP NAMESERVER NICNAME TACACS DOMAIN BOOTPS BOOTPC TFTP GOPHER Keyword
405
Table 13-9
Some of the Most Important Port Numbers (Continued) Port Number 89 95 101 102 103 104 107 109 110 111 113 116 119 123 133-136 137 137 138 138 139 144 161 162 167 169 194 Port Type TCP & UDP TCP TCP TCP TCP TCP TCP & UDP TCP TCP TCP & UDP TCP & UDP TCP & UDP TCP & UDP TCP & UDP TCP & UDP UDP TCP UDP TCP UDP TCP TCP & UDP TCP & UDP UDP TCP & UDP TCP & UDP Protocol Open Shortest Path First SUPDUP Protocol NIC Host Name Server ISO-TSAP X400 X400-SND Remote Telnet Service Post Ofce Protocol v2 Post Ofce Protocol v3 SUN Remote Procedure Call Authentication Service UUCP Path Service USENET Network News Transfer Protocol Network Time Protocol (NTP) Unassigned NETBIOS Name Service Unassigned NETBIOS Datagram Service Unassigned NETBIOS Session Service NeWS Simple Network Mgmt. Protocol Q/R SNMP Event Traps X Display Manager Control Protocol xdmcp Border Gateway Protocol (BGP) Internet Relay Chat Well-Known IRC NETBIOS-SSN Well-Known SNMP SNMP-TRAP NETBIOS-DGM NETBIOS-NS Keyword OSPF SUPDUP HOSTNAME ISO-TSAP X400 X400-SND RTELNET POP2 POP3 SUNRPC AUTH UUCP-PATH NNTP Well-Known
You already established that RPC is one of the contributors in this process you are trying to analyze. Continuing the same process of snifng for every protocol and port, you nd the following:
Netbios-ns generates more than 24 percent of the W2K-related trafc. Netbios-dgm generates about 1 percent of the W2K-related trafc.
406
TCP 445 generates almost 5 percent of the W2K-related trafc. PIM generates about 33 percent, and so on.
Your percentage numbers can differ based on characteristics of the trafc.
Step 3: Use a Cisco Knowledge Base to Remedy any Identied Problems

Its time to implement the existing Cisco knowledge base. Based on the available information on Cisco.com for an ACL, you can create the following solution. For IOS routers, the ACL might include the following:
access-list access-list access-list access-list access-list access-list access-list access-list access-list access-list access-list access-list dialer-list dialer-list 101 deny 101 deny 101 deny 101 deny 101 deny 101 deny 101 deny 101 deny 101 deny 101 deny 101 deny 101 permit 1 protocol 1 protocol icmp any any echo icmp any any echo-reply icmp any any host-unreachable udp any any eq sunrpc udp any any eq netbios-ns udp any any eq netbios-dgm udp any any eq ntp tcp any any eq sunrpc tcp any any eq 445 pim any any igmp any any ip any any ip list 101 netbios deny
The 77x version would include the following:

set set set set set set set set set set set set set set set set set udp111 offset 2 from udphdr udp137 offset 2 from udphdr udp138 offset 2 from udphdr udp123 offset 2 from udphdr tcp111 offset 2 from tcphdr tcp139 offset 2 from tcphdr tcp445 offset 2 from tcphdr ip filter icmp out ignore ip filter out udp111 ignore ip filter out udp137 ignore ip filter out udp138 ignore ip filter out udp123 ignore ip filter out tcp111 ignore ip filter out tcp445 ignore ip multicast off netbios name spoofing off netbios filter on pattern pattern pattern pattern pattern pattern pattern 00 00 00 00 00 00 01 6f 89 8a 7b 6f 8b bd
Or the shorter version of the same ACL for 77x router can be the following:
set set set set set set set set set set ip filter udp out de=0.0.0.0/0:111 ip filter udp out de=0.0.0.0/0:137 ip filter udp out de=0.0.0.0/0:138 ip filter udp out de=0.0.0.0/0:123 ip filter tcp out de=0.0.0.0/0:111 ip filter tcp out de=0.0.0.0/0:445 ip fiter icmp out ignore netbios name spoofing off ip multicast of bridging of ignore ignore ignore ignore ignore ignore
407
Step 4: Select a Solution and Test It

At this step, you must test your solution. The objective is to prove that you are able to make the extra trafc uninteresting and prevent the router from dialing out. The recommended debug settings are
804-isdn#debug arp ARP packet debugging is on 804-isdn#debug dialer Dial on demand events debugging is on 804-isdn#debug ip udp UDP packet debugging is on 804-isdn#debug ip tcp transactions TCP special event debugging is on
The expected result from the debugging the process is displayed in Example 13-19.
Example 13-19 Debugging Results
804-isdn# Aug 1 06:30:25.886: %ISDN-6-LAYER2UP: Layer 2 for Interface BR0, TEI 88 changed to up *Aug 1 06:30:25.910: %ISDN-6-LAYER2UP: Layer 2 for Interface BR0, TEI 97 changed to up ! The moment the ISDN line is established, the router is triggering a call ! based on multicast request. *Aug 1 06:30:28.514: Di1 DDR: ip (s=161.70.209.81, d=230.0.0.1), 28 bytes, outgoing uninteresting (list 101) ! The traffic is blocked with ACL 101 *Aug 1 06:30:28.518: Di1 DDR: sending broadcast to ip 162.30.253.254 -failed, not connected *Aug 1 06:30:43.278: Di1 DDR: ip (s=161.70.209.82, d=161.68.235.228), 96 bytes, outgoing uninteresting (list 101) *Aug 1 06:30:44.778: Di1 DDR: ip (s=161.70.209.82, d=161.68.235.228), 96 bytes, outgoing uninteresting (list 101) *Aug 1 06:30:46.278: Di1 DDR: ip (s=161.70.209.82, d=161.68.235.228), 96 bytes, outgoing uninteresting (list 101) ! The traffic is blocked to 2 WINS servers with ACL 101 *Aug 1 06:30:51.490: Di1 DDR: cdp, 295 bytes, outgoing uninteresting (no list matched) *Aug 1 06:30:51.494: Di1 DDR: sending broadcast to ip 162.30.253.254 -- failed, not connected *Aug 1 06:30:55.502: Di1 DDR: ip (s=161.70.209.81, d=230.0.0.13), 30 bytes, outgoing uninteresting (list 101) *Aug 1 06:30:55.502: Di1 DDR: sending broadcast to ip 162.30.253.254 -- failed, not connected *Aug 1 06:31:25.502: Di1 DDR: ip (s=161.70.209.81, d=230.0.0.13), 30 bytes, outgoing uninteresting (list 101) *Aug 1 06:31:25.502: Di1 DDR: sending broadcast to ip 162.30.253.254 -- failed, not connected *Aug 1 06:31:51.562: Di1 DDR: cdp, 295 bytes, outgoing uninteresting (no list matched) *Aug 1 06:31:51.566: Di1 DDR: sending broadcast to ip 162.30.253.254 -- failed, not connected
continues
408
Example 13-19 Debugging Results (Continued)

*Aug 1 06:31:55.398: Di1 DDR: ip (s=161.70.209.82, d=161.68.222.255), 116 bytes, outgoing uninteresting (list 101) *Aug 1 06:31:55.574: Di1 DDR: ip (s=161.70.209.81, d=230.0.0.13), 30 bytes, outgoing uninteresting (list 101) *Aug 1 06:31:55.574: Di1 DDR: sending broadcast to ip 162.30.253.254 -- failed, not connected *Aug 1 06:32:00.406: Di1 DDR: ip (s=161.70.209.82, d=161.68.222.255), 116 bytes, outgoing uninteresting (list 101) *Aug 1 06:32:05.414: Di1 DDR: ip (s=161.70.209.82, d=161.68.222.255), 116 bytes, outgoing uninteresting (list 101) *Aug 1 06:32:51.634: Di1 DDR: cdp, 295 bytes, outgoing uninteresting (no list matched) *Aug 1 06:32:51.638: Di1 DDR: sending broadcast to ip 162.30.253.254 -- failed, not connected *Aug 1 06:32:55.646: Di1 DDR: ip (s=161.70.209.81, d=230.0.0.13), 30 bytes, outgoing uninteresting (list 101) *Aug 1 06:32:55.650: Di1 DDR: sending broadcast to ip 162.30.253.254 -- failed, not connected .
From the previous limited segment, you can see that you are blocking the multicast and preventing the W2K computer with an IP = 161.70.209.82 to trigger a call to the WINS servers of your enterprise. You might consider turning on all the debugging and monitoring the process in more detail and for a longer period of time. The comparison between the Microsoft provided solution and the Cisco ACL-based solution shows the former one is able to reduce the extra trafc to 50 percent in some instances. However, the Cisco ACL-based solution blocks more than 99 percent of the extra trafc. The recommended hours for testing the solution are at least 72 hours. Its worth trying the same solution using different hardware, a different set and number of computers, and a different environment to make sure the solution is successful. If this step does not give you the result you are looking for, you need to start from the beginning and iterate the process again.
Summary
This chapter started by covering some recommendations for practical troubleshooting of ISDN remote services. These included using #show isdn status to view service layers, preconguring the routers on both ends, and accessing the remote users router. After that general discussion, this chapter presented ve scenarios aimed toward helping you learn how to apply ISDN troubleshooting techniques covered earlier in this part:
Scenario 1: New Install Problems Scenario 2: Dial-Out Problems
Summary
409
Scenario 3: ISDN Performance Problems Scenario 4: End-to-End Communication Problems Scenario 5: Windows 2000 DDR Issue
PART
IV
Frame Relay
Chapter 14 Frame Relay Technology Background Chapter 15 Frame Relay Design Solutions Chapter 16 Basic and Advanced Frame Relay Congurations Chapter 17 Frame Relay Troubleshooting Chapter 18 Frame Relay Troubleshooting Scenarios
CHAPTER
14
Frame Relay Technology Background

Frame Relay technology includes a combination of hardware, software, standards, and architectures to provide a variety of services. They include data, Voice over Frame Relay (VoFR), Frame Relay multicast, Internet Protocol (IP) multicast over Frame Relay, Frame Relay compression, and others. It is beyond the scope of this book to include all available features of Frame Relay, so the content of Part IV, Frame Relay, only includes the technology background, common design and conguration solutions for enterprise remote access, and proven troubleshooting techniques and scenarios. This chapter also provides a more detailed background of Frame Relay technology, including the following:
Frame Relay standards Frame Relay service architecture Frame Relay protocols, including Link Access Procedures for Frame Mode Bearer Services (LAPF) core and control protocol
One of the fundamental reasons for creating Frame Relay technology was the need for higher speeds. The other driving factor was the industry change from mainly text exchange, to graphical exchanges, which requires peak bandwidth or dynamic bandwidth and lower response time. Widespread digital facilities demand more reliability and less overhead, and the ability to handle bursty trafc. This combination of factors drove the development of new technology at the end of the 1980s. Frame Relay combines the statistical multiplexing and port sharing of X.25 with the highspeed and low-delay characteristics of time-division multiplexing (TDM) circuit switching. Conceived as a derivative from X.25, Frame Relay eliminates the Layer 3 protocols of X.25 and concentrates the addressing and multiplexing in Layer 2. The architecture model is more compliant with Open System Interconnection (OSI), where the second layer deals with frames and not with packets. Only a few Layer 2 functions are used in permanent virtual circuit (PVC) solutions, and they are known as the core aspects such as checking for valid error-free frames but not requesting retransmission if an error is found. Therefore, many high-level protocol functions such as sequencing, windowing, acknowledgments, and supervisory frames are not duplicated within Frame Relay.
414
Chapter 14: Frame Relay Technology Background
What Is Statistical Multiplexing? The term multiplexing refers to sharing a single resource among many users. Analog communications typically use frequency-division multiplexing (FDM) to carry multiple conversations. A good example is the 6-MHz TV bandwidth, or simultaneous voice and video. FDM divides the available bandwidth between a narrow voice channel (about 4 kHz) and a wider band for video, and allocates a 900 Hz guard band between them. Digital signaling is mostly based on TDM. TDM allocates a small slot of time for every member sharing the channel. On a round-robin basis, every member gets a dedicated slot. For more bursty applications (bursty means that the peak data rate is much greater than the average rate), statistical multiplexing is more commonly used because individual applications are supplied with bandwidth on an as needed basis. Thus, the channel is idle if all applications have nothing to send, but if at least one application has data to send, the channel is active. This provides optimal use of available bandwidth, but unlike TDM, cannot guarantee bandwidth for individual applications.
The lack of certain protocol functions in Frame Relay dramatically increases throughput because each frame requires much less processing time. Table 14-1 summarizes the characteristics of these protocols, comparing X.25 switching and Frame Relay.
Table 14-1 X.25 and Frame Relay Comparison 1 Feature Time-slot multiplexing Statistical (virtual circuit) multiplexing Port sharing Packet sequencing Error checking Perform ow control Network access X.25 Packet Switching No Yes Yes Yes Yes Yes 300 bps-64 kbps 10-40 msec 200-500 msec Frame Relay No Yes Yes No No No, drops frames; on congestion 56-2048 kbps; the technology provides speeds up to 45 Mbps; recent advancements include speeds up to 155 Mbps 2-6 msec 40-150 msec
Switch delay One-way delay
415
Frame Relay uses a variable length framing structure, which ranges from a few to thousands of bits. This feature affects delay-sensitive user data because the delay is a function of the packet size. Although this is a feature in Frame Relay compression, it is a disadvantage when carrying voice trafc. However, Frame Relay has been adapted to handle the voice trafc, as dened in FRF11.1 (see Table 14-3). The two factors that make Frame Relay a desirable choice for data transmission are the following:
Frame Relay virtual circuits consume bandwidth only when they transport data, thus many virtual circuits can exist simultaneously across a given transmission line. Also, each device can use more of the bandwidth as needed, and thus operate at higher speeds. The improved reliability of communication lines and increased error-handling sophistication at end stations allows the Frame Relay protocol to discard erroneous frames, and thus eliminates time-consuming error-handling processes.

All written standards that govern Frame Relay implementations are American National Standards Institute (ANSI), International Telecommunication Union Telecommunication Standardization Sector (ITU-T), or Frame Relay Forum (FRF) standards. Although ANSI and ITU-T standards are based on the ISDN architecture, the FRF documents address implementation issues, ensuring the interoperability of multivendor networks. Table 14-2 summarizes some of the ANSI and ITU-T standards governing Frame Relay.
Table 14-2 ANSI and ITU-T Standards Governing Frame Relay Subject Architecture and service description Data link layer core aspects PVC management Congestion management Switched virtual connection (SVC) signaling ANSI T1.606 T1.618 T1.617 Annex D T1.606a T1.617 ITU-T I.233 Q.922 Annex A Q.933 Annex A I.370 Q.933
The FRF (www.frforum.com) was created to develop Frame Relay technologies, to improve the existing standards, and to facilitate multivendor inter-operability. The FRFs formal documents are called Implementation Agreements (IAs). Table 14-3 shows the current issued agreements.
416
Table 14-3
Frame Relay Forum (FRF) Implementation Agreements Document FRF.1.2 FRF.2.1 FRF.3.2 FRF.4.1 FRF.5 FRF.6 FRF.7 FRF.8.1 FRF.9 FRF.10.1 FRF.11.1 FRF.12 FRF.13 FRF.14 FRF.15 FRF.16 FRF.17 FRF.18 FRF.19 FRF.20 Description User-Network Interface (UNI) Network-to-Network Interface (NNI) Multiprotocol Encapsulation SVC User-Network Interface (UNI) Frame Relay/ Asynchronous Transfer Mode (ATM) PVC Network Interworking Frame Relay Service Customer Network Management Frame Relay PVC Multicast Service and Protocol Description Frame Relay/ATM PVC Service Interworking Data Compression over Frame Relay Frame Relay Network-to-Network SVC VoFR Frame Relay Fragmentation Service Level Denitions Physical layer Interface End-to-End Multilink Frame Relay Multilink Frame Relay UNI/NNI Frame Relay Privacy Network-to-Network FR/ATM SVC Frame Relay Operations, Administration, and Maintenance Frame Relay IP Header Compression
The RFCs specic to Frame Relay are listed in Table 14-4.

Table 14-4 IETF Frame Relay Related RFCs Document 1604 1596 1315 1490 1294 1293 1973 2427 Description Denition of Managed Objects from Frame Relay Services Denition of Managed Objects from Frame Relay Services Management Information Base for Frame Relay DTEs Multiprotocol Interconnect over Frame Relay Multiprotocol Interconnect over Frame Relay Inverse Address Resolution Protocol (ARP) Point-to-Point Protocol (PPP) in Frame Relay Multiprotocol Interconnect over Frame Relay
Frame Relay Service Architecture
417
Frame Relay Service Architecture

The Frame Relay service architecture is dened as two planes: the C-plane (control) and Uplane (user). Both planes are governed by standards, such as ANSI T1.601.2 Figure 14-1 shows the relationship between the two planes. The Frame Relay and frame switching concepts are shown in Figure 14-2 and Figure 14-3.
Figure 14-1 C-Plane and U-Plane in Frame Relay Using the ANSI UNI Protocol
Control Plane D Channel
User Plane D, B, or H Channel
User Plane D, B, or H Channel
Control Plane D Channel
Q.931/Q.933
User Selectable Terminal Functions
Q.931/Q.933
LAPD (Q.921)
LAPF Core Functions of Q.922
LAPF Core Functions of Q.922
LAPD (Q.921)
ANSI I.430/I.431 Physical Layer Standards User (TE)
ANSI I.430/I.431 Physical Layer Standards S/T Interface Network (NT)
Figure 14-2 Frame Relay Concept

DTE
Switch
Switch
DTE
Network Layer
Network Layer
LAPF Control
LAPF Control
LAPF Core Functions of Q.922 ANSI I.430/I.431 Physical Layer Standards
LAPF Core
LAPF Core
ANSI I.430/I.431 Physical Layer Standards
S/T Interface
Frame Relay Network
S/T Interface
418
Figure 14-3 Frame Switching Concept

DTE
Switch
Switch
DTE
Network Layer
Network Layer
LAPF Control
LAPF Control
LAPF Control
LAPF Control
LAPF Core
LAPF Core
S/T Interface
Frame Relay Network
S/T Interface
The C-plane uses the Q.921 and Q.931 protocols, and the U-plane deals with the 64-kbps B channel, the 16- or 64-kbps D channel, or the H channel (384, 1472, or 1536 kbps). The main interfaces used today are the following:
ITU-T V.35A full duplex interface that typically operates at 56 kbps ANSI T1.403A metallic interface between carriers and the customer premises equipment (CPE), operating at DS1 or 1.544 Mbps rates ANSI/EIA/TIA-530-A-1992An electrically balanced interface, operating at data rates below 2.1 Mbps, using a 25-pin connector ANSI/EIA/TIA-613-A-1993Ciscos High-Speed Serial Interface (HSSI), operating at up to 53 Mbps, using a 50-pin connector ANSI t1.107aThe DS3 interface, operating at 33,736 Mbps ITU G.703The E3 interface, operating at 34.368 Mbps ITUV36/V.37An interface operating at 2-10 Mbps, using a 25-pin connector
The current version of FRF.1.13 adds the following high-speed interfaces:
From the point of view of a troubleshooting engineer, it is good to know that the most commonly available Frame Relay service is the PVC service with typically 56 kbps, or incremented fractions of 64 kbps, such as 64, 128, 384, up to 1544 kbps. Frame Relay supports switched virtual circuit (SVC) and PVC, but SVC is not commonly deployed in Frame Relay.
Frame Relay Protocols
419

The Frame Relay protocols are designed to reect the concept of the second layer of the OSI model, based on services from the physical layer and providing services for the higherlayer protocols. At the same time these protocols are not simplistic. They provide a mechanism to maintain PVCs to establish SVCs, and to encapsulate higher-layer protocols.
LAPF
Frame Relay technology provides second layer functions such as framing, error control, and sequence control, and support for third layer functionality such as addressing and multiplexing. This is the core functionality of LAPF, which is dened in Recommendation Q.922. The protocol allows statistical multiplexing of one or more frame connections over a single channel. LAPF can be used over Frame Relay to provide end-to-end error and ow control. LAPF denes core functions and full functionality. The core LAPF is used for Frame Relay, and full LAPF (core LAPF and control LAPF) is used for frame switching.
LAPF Core Protocol and the T1.618 (Q.922 Annex A) Frame Format
LAPF core functions are organized around ve elementary procedures:
Frame Relay must provide services to delimit and align frames and provide transparency of the frame ags with zero-bit stufng and unstufng. Frame Relay must support virtual circuit multiplexing and demultiplexing through the use of the data-link connection identier (DLCI) eld in the frame. The system must inspect the frame to ensure that it aligns itself on an integer number of octets, prior to zero bit insertion and following the unstufng of the zero bit. The system must inspect the frame to ensure that it does not exceed the maximum and minimum frame size (the frame sizes are established by the service provider). The systems must be able to detect transmission errors through the use of the Frame Check Sequence (FCS) eld.
A Frame Relay network consists of endpoints (PCs, servers, local-area networks [LANs]), Frame Relay access equipment (bridges, routers, hosts and Frame Relay access devices [FRADs]), and network devices (switches, network routers and T1/E1 multiplexers). The protocol interconnecting these devices is a subset of the high-level data link control (HDLC) frame format that is shown in Figure 14-4. The frame consists of ve elds:
Beginning ag eld Ending ag eld Two-byte address eld Variable-length information eld FCS eld, used for error control
420
NOTE
For the purposes of this book, the term router is used later in the discussion as a common name for a Frame Relay access device.
Figure 14-4 Frame Relay Frame Format

User-Network User-User User-Network
1 Flag 01111110
2 Address
n Information Field (Data)

Variable-Length Field May Contain up to 16,000 Octets
2 FCS
1 Flag 01111110
LAPF Core
Higher Layer PDU
LAPF Core
The information eld and the FCS elds are no different from most protocol formats. The information eld contains encapsulated upper-layer data. Each frame in this Variablelength eld includes a user data or payload eld that varies in length as large as 16,000 octets. This eld serves to transport the higher-layer protocol packet (protocol data unit [PDU]) through a Frame Relay network. The FCS precedes the ending ag delimiter and is usually a cyclic redundancy check (CRC) calculation remainder. The CRC calculation is redone in the receiver. If the result differs from the value in the original frame, an error is reported. This eld uses a 2-byte CRC sequence with a CRC-16 polynomial. The information eld can vary in length up to 16,000 octets, but FCS code provides error detection for frames up to 4096 bytes. The next sections concentrate on Frame Relay specic format elds such as the Flag eld and Address eld.
Flag Field
The Flag eld is one byte that is a xed sequence and consists of 01111110 (binary) or 0x7E (7Eh). The Flag indicates the beginning and end of the frame. If the sender needs to send 7Eh as part of the information in the middle of the transmission, but not as a Flag, the sender inspects the data stream for 011111. If found, a 0 is inserted immediately after the fth 1, which changes the data stream (see Figure 14-5). This procedure works regardless of the value of bit 7 (0 or 1), because of the content of the next (address) eld.
421
Figure 14-5 The Zero-Insertion Procedure
Sender
Receiver
Data
Zero-Bit Insertion
Transmit
Remove the Inserted Bit
Data
01111110
011111010
011111010
01111110
Address Field
The address eld has three different formats, shown in Figure 14-6. Descriptions of the elds follow:
DLCIData link connection identier is a unique number that provides local identication of the connection. The default address eld format is 2 bytes or 10 bits. The extended address frame format can be 3 bytes (16 or 17 bits) or 4 bytes (23 bits). C/RCommand/Response Field provides interconnectivity with higher-layer protocols. Frame Relay does not check it and the router can use this bit for signaling and control. FECNForward explicit congestion notication indicates congestion in the direction of the trafc ow. BECNBackward explicit congestion notication indicates congestion in the direction opposite of the trafc ow. DEDiscard eligible indicates the importance of the packet. If DE = 1, the packet is eligible for discarding, and in the case of congestion it can be dropped without any notication. It is a bit that can be set by the user and by the network. Setting a bit DE = 1 does not necessarily mean that the frame will be dropped; however, the packet is eligible for discard when congestion exists on the network. In fact, in CIR = 0 provisioned networks, you might have up to 99.9 percent of frames delivered. EAExtended address extends the addressing structure from a default of 2 bytes, to 3 and 4 bytes. The EA = 0 indicates that more address follows, and EA = 1 indicates that it is the last address byte. D/CData or control eld that exists in either the DLCI or the DL-core control indicator.
Two UNI interfaces connect to each other by using a 10-bit DLCI (by default), which provides 210 = 1024 DLCIs, from 0 to 1023 (see Table 14-5).
422
Figure 14-6 LAPF Core Formats of the Address Field

The default address field format is 2 bytes - DLCI 10 bits. DLCI ranges from 0-1023.
2 C/R 0/1
1 EA0 0 EA1 1
DLCI (High Order) DLCI (Low Order) FECN BECN
DE
The extended address frame format - 3 bytes - DLCI 16 or 17 bits.
2 C/R 0/1
1 EA0 0 EA0 0 EA1 1
DLCI (High Order) DLCI FECN BECN
DE D/C
DLCI (Low Order) or DL-CORE Control
The extended address frame format is 4 bytes. DLCI is 23 bits.
2 C/R 0/1
1 EA0 0 EA0 0 EA0 0
DLCI (High Order) DLCI DLCI DLCI (Low Order) or DL-CORE Control FECN BECN
DE
D/C
EA1 1
The core LAPF protocol uses simple logic. The rst check of the incoming frame is for a valid/not valid frame. If the frame is valid, the LAPF core checks the known/unknown DLCI. If it is OK, the frame proceeds further. However, a Frame Relay network drops erroneous and non-erroneous frames. The rst group of erroneous frames is dropped regardless of the condition of the network and includes packets without opening and closing
423
ag elds, frames with the wrong DLCI, larger and smaller than expected frames, and frames with a FCS error. The second group of drops are frames with DE = 1, if there is network congestion. A third group of non-erroneous frames can be discarded randomly during periods of congestion.
Table 14-5 Frame Relay Forum (FRF) 10-Bit DLCI Values and Their Functions DLCI Values DLCI Assignments 0 1-15 16-1007 1008-1022 1019-1022 1023 Reserved for Call Control Signaling; AnnexD Local Management Interface (LMI) Reserved Available for PVC Reserved Used by some vendors for multicast Initially dened for LMI by Consortium; used for consolidated link-layer management (CLLM) messages in T1.618 Function
ANSI (T1.618) and ITU-T (Q.922) 10-Bit DLCI Recommendations and Management (LMI) 0 1-15 16-991 992- 1007 1008-1022 1023 In-channel signaling Reserved Assigned, using Frame Relay connection procedure Layer 2 management of Frame Relay Bearer Services Reserved In-channel layer management
Overall, Cisco LMI provides for 992 VCs, and ANSI provides for 976.
NOTE
The original LMI specication denes DLCI 1023 for LMI, but the AnnexD standard assigns DLCI 0 for this function. This change aligns the LMI function with previously dened ISDN, where DLCI 0 is used for signaling (refer to Table 14-5). AnnexD is the most widely accepted for multivendor solutions.
424
LAPF Control Protocol

For frame switching services, the LAPF control protocol is used along side the LAPF core protocol. This protocol is the full Q.922, and it is implemented both in the users system and in the network (called the frame handler). Figure 14-4 shows one of the common formats, where the information eld carries a higher-layer PDU and represents Frame Relay with other end-toend protocols above LAPF, thus providing error and ow control. Here again, the Flag and Address elds and FCS are the same as in the LAPF core format. The specic elds for this protocol, the control eld and information (data) eld are discussed in the following sections.
Control Field
In Figure 14-7 and Figure 14-8, two formats of Q.922 are shown. The only difference between the core format and the control protocol format is the control eld. The control eld has the same format and identical functionality as the Link Access Procedure on the D channel (LAPD) eld. The control protocol provides the functions of error and ow control that are missing from the LAPF core protocol.
Figure 14-7 LAPF Frame Formats; Frame Relay with End-to-End LAPF Control
1 Flag 01111110
2-4 Address
1 or 2 Control
2 FCS
1 Flag 01111110
LAPF Core
LAPF Control
Higher Layer PDU
LAPF Core
Figure 14-8 LAPF Frame-Switching Format

1 Flag 01111110
2-4 Address
1 or 2 Control
2 FCS
1 Flag 01111110
LAPF Core
LAPF Control
Higher Layer PDU
LAPF Core
425
Figure 14-7 represents one possible option for end-to-end ow control and error control, based on the full LAPF protocol frame. The Frame Relay control eld is part of the information eld of the frame, and because Frame Relay does not monitor the information eld, this feature is signicant for end-to-end connections. At the same time, the information eld can contain network and transport layer PDUs. Figure 14-8 represents the frame switching bearer service. The control eld is visible to the network because it is not part of the information eld. Therefore, error control is performed in the user-to-network part of the structure. Regardless of this second layer control feature, the error and ow control functions can still be exercised by the higher-layer protocols. The different LAPF control formats are shown in Figure 14-9.
Figure 14-9 LAPF Control Formats
Information Transfer 1 0 Supervisory 1 1 2 0 3 S 4 S 5 0 6 0 7 0 8 0 9 P/F 10 11 12 13 N(R) 14 15 16 2 3 4 5 N(S) 6 7 8 9 P/F 10 11 12 13 N(R) 14 15 16
Unnumbered 1 1 2 1 3 M 4 M 5 P/F 6 M 7 M 8 M
N(S)Transmitter Send Sequence Number N(R)Transmitter Receive Sequence Number P/FPolling/Final Bit SSupervisory Function Bit MModifier Function Bit
NOTE
The control eld in LAPF is used between the user and the network; it is not an end-to-end function. End-to-end functions are based on PDUs for the higher-layer protocols, which provide end-to-end ow and error control.
426
Information (Data) Field of the LAPF Control Protocol Frame

In the LAPF control protocol, the information eld carries both non-data (signaling) and user data information. A Frame Relay network uses four categories of signaling messages:
LMI messages T1.617 AnnexD messages CLLM messages SVC messages
In general, the information eld uses two formats as shown in Figure 14-10. In the gure, IE indicates the information elements.
Figure 14-10 Information Field Formats
The Signaling Message
Control
Message Header
IE1
IE2
IE...
The User Data
Network Layer Header
Higher Layer Data
The IE elds carry higher-layer protocol information such as user data and higher-layer overhead and routing updates. It is transparent to the Frame Relay network. There is no inspection or change to this eld, which allows the use of new features such as compression, Virtual Private Network (VPN), quality of service (QoS), and VoFR. ANSI T1.618 and FRF.1.1 recommend a maximum negotiated information length up to 1600 bytes to reduce the number of segmentations and re-assembly functions in wide-area network (WAN)-LAN borders. Each of the four categories of signaling messages use a Q.931 header to carry different information.
NOTE
The protocol discriminator eld of Q931 (single octet) (refer to Figure 10-7) carries the format of the message that follows. The value 08H indicates messages dened by ANSI T1.607, and 09H indicates a Consortium message.
The messages that do not relate to the call establishment disconnect, or status use a Dummy Call Reference in Q.931 header with the eld containing all zeros (00H).
427
Part of the signaling message is the IE, which can follow one of two basic single octet formats: single octet (type 1) and single octet (type 2). The IE can have variable length information. The two single octet types (type 1 and type 2) are shown in Figure 14-11. The single octet basic IE format and the variable-length basic IE format are explained in Table 14-6.
Figure 14-11 Two Basic Single Octet Formats of IE. The First Format Is the Common Single Octet Format and the Second Two Show Type 1 and Type 2 Formats
8 1
Information Element Identifier
Content of IE
Single Octet IE (Type 1) 8 1 7 6 5 4 3 2 1
Information Element Identifier
Single Octet IE (Type 2) 8 0 7 6 5 4 3 2 1
Information Element Identifier Length of Contents of IE (Octets) Content of IE
Table 14-6
Single Octet and Variable-Length IE Format* Bits* 8765 4321 1xxx xxxx 1000 xxxx 1001 xxxx 1101 xxxx 0xxx xxxx 0000 0001 Description of the IE Formats Single Octet IE Reserved Shift Repeat indicator Variable Length IE Report type 3 continues 1 1 1 Max Length (Octets)
428
Table 14-6
Single Octet and Variable-Length IE Format* (Continued) Bits* 8765 4321 0000 0011 0000 0100 0000 0111 0000 1000 0001 0100 0001 1000 0001 1001 0001 1010 0001 1110 0010 0000 0010 1000 0100 0010 0100 0100 0100 1000 0100 1001 0100 1100 0100 1101 0110 1100 0110 1101 0111 0000 0111 0001 0111 1000 0111 1100 0111 1101 0111 1110 0111 1111 Description of the IE Formats Keepalive Bearer capability PVC status Cause Call state Channel ID DLCI Link integrity verication Progress indicator Network specic facilities Display End-to-end transit delay Packet layer binary parameters Link-layer core parameters Link-layer protocol parameters Connected number Connected subaddress Calling party number Calling party subaddress Called party number Called party subaddress Transit network selection Low-layer compatibility High-layer compatibility User-user Escape for extension Max Length (Octets) 4 5 5 32 3 n/a 6 4 4 n/a 82 11 3 27 9 n/a 23 n/a 23 n/a 23 n/a 14 4 131 n/a
*All other values are reserved; x means the value does not matter. n/a means it is not defined.
There is no commonly implemented minimum or maximum frame size for Frame Relay, although a network must support at least a 262-octet. Generally, each Frame Relay provider species an appropriate value for its network. Frame Relay DTE must allow the maximum
Review Questions
429
acceptable frame size to be congurable. The minimum frame size allowed for Frame Relay is ve octets between the opening and closing ags, assuming a two-octet Q.922 address eld. This minimum increases to six octets for a three-octet Q.922 address and to seven octets for a four-octet Q.922 address format. The Cisco maximum transmission unit (MTU) is set by default to 1500 bytes. Given the fact that the two ag elds, the default address eld and the FCS, are 6 bytes, only a small portion of the size of the packet (up to (1500 6) / 1500 = 0.004) is the technology overhead, which is one of the unique features of Frame Relay. (See Chapter 9, ISDN Technology Background, for a comparison with ISDN overhead.)
End Notes
1 Held,
Gilbert. Frame Relay Networking. John Wiley & Son Ltd. 1999.
2 American National Standards Institute. ISDN Basic Access Interface for Use on Metallic
Loops for Applications on the Network Side of the NT. ANSI T1.601.1994.
3Frame
Relay Forum. User-Network Interface (UNI) Implementation Agreement. FRF.1.1, January 1996.
Summary
Frame Relay technology service offerings, which commonly include PVCs provide a variety of services for the enterprise environment, including data, VoFR, Frame Relay multicast, IP multicast over Frame Relay, Frame Relay compression, and others. This chapter gives you a better understanding about Frame Relay standards, architectures, and protocols, such as LAPF core and LAPF control protocol, and also gives you a detailed explanation about common Frame Relay protocol formats.
Review Questions
1 Does Frame Relay perform ow control over the frames? 2 Name the FRF implementation agreement that governs data compression over Frame
Relay.
3 Dene the main components of the full LAPF protocol. 4 Name the components of the Frame Relay format. 5 What is the maximum frame size that FCS can provide error detection for?
430
6 What is the zero-insertion procedure and why is it necessary? 7 How many DLCI address eld formats are available? 8 What does the DE bit stand for and who can set it? 9 Name the LMI numbers for Consortium and AnnexD specications. 10 What is the main difference between the core format and control protocol format of
LAPF?
11 Name the four categories of signaling messages of the LAPF control protocol. 12 What is the purpose of the Dummy Call Reference in the Q.931 header?
CHAPTER
15
Frame Relay Design Solutions

Frame Relay is a versatile and exible technology where the provisioned parameters dene the way that the service can be manipulated by both the service provider and the enterprise. Provider manipulation is beyond the scope of this chapter, although the enterprise will receive the type of service (ToS) and further ability to manipulate the service, based on the design parameters, topologies, and provisioned parameters. In this chapter, you learn about the following:
Design parameters of Frame Relay User-Network Interface (UNI) and Network-to-Network Interface (NNI) Frame Relay topologies User and Frame Relay switch under congestion Frame Relay performance criteria Frame Relay and upper-layer protocols Local Management Interface (LMI) Inverse Address Resolution Protocol (ARP)
Trafc shaping techniques that do not require any specic design by the enterprise are discussed in Chapter 16, Basic and Advanced Frame Relay Congurations, and Chapter 17, Frame Relay Troubleshooting. To provide an effective Frame Relay service for the enterprise, the Frame Relay network has to solve two main issues: reduce the response time and prevent possible congestion and oversubscription. In the Frame Relay design stage of an enterprise network, it is important to dene the design parameters, structural decisions, and both UNI and NNI solutions. It is also important to anticipate the possible multicast and compression solutions, and voice and fragmentation decisions.
434
Chapter 15: Frame Relay Design Solutions
Design Parameters
The following parameters must be considered in the Frame Relay design stage:
Access rate (AR) or link speedThis is the data rate, which is measured at the physical interface in bits per second. The link speed determines how rapidly (maximum rate) the end user can inject data into a Frame Relay network. Committed interval (Tc)The committed interval represents a time slot over which the rates burst and the committed information rate (CIR) is measured. The measurement is in secondsusually ranging from 0.5 to 2 seconds. Tc is sometimes called the bandwidth interval. The user and network negotiate and agree on the measurement interval based on the I.370 recommendations: When the CIR equals the AR (E1, T1), the ARs at the ingress and egress points must be equal. When CIR = 0, Bc = 0, Be must be > 0 and Tc = Bc / access rate. The ITU-T also recommends that the end users Frame Relay router should accept and react to the explicit congestion notications. The router (end-user device) reacts to these notications because the users equipment, which is connected to the router, has no way of knowing the conditions of the Frame Relay network.
NOTE
The rule of thumb for Tc is that it should be set to four times the end-to-end transit delay.
Committed burst rate (Bc)The Bc is the maximum amount of data in bits that the network agrees to transfer, under normal circumstances, over the Tc. The Bc is established (negotiated) during a call setup, or pre-provisioned with a permanent virtual circuit (PVC). Bc defaults to the value of the CIR unless otherwise congured. Excess burst rate (Be)The Be is the maximum amount of uncommitted data in bits over and above Bc that the network attempts to deliver in a given Tc. Be is also negotiated during call setup (in frame-switched networks), or pre-provisioned with the PVC. The probability of delivering Be is obviously lower than Bc.
NOTE
When the connection is established (whether it is a PVC or SVC), the user and network establish the CIR, Bc, and Be in the Tc. These three measurements are referred to as network capacity management, which relies on discarding frames (if necessary) at the egress point of the network.
Discard eligible (DE)The DE is a one-bit eld in the Link Access Procedures for Frame-Mode Bearer Services (LAPF) address eld, which indicates that the frame can be discarded to relieve congestion (see Figure 14-6 in Chapter 14).
Design Parameters
435
CIRThe CIR is the allowed amount of data that the network is committed to transfer under normal conditions. The rate is averaged over an increment of time Tc. The CIR is also referred to as the minimum acceptable throughput. CIR is one of the most important parameters when designing the network and when subscribing for the service. The measurement is in bps or kbps over the time period of Tc: CIR = Bc / Tc
Bc, Be, Tc, and CIR are dened per data-link connection identier (DLCI). Because of this, the leaky-bucket lter controls the rate per DLCI. The access rate is valid per User-Network Interface (UNI). Bc, Be, and CIR incoming and outgoing values can be distinguished. If the connection is symmetrical, the values in both directions are the same. For PVCs, incoming and outgoing Bc, Be, and CIR are dened at subscription time as follows: Peak = DLCIs maximum speed; the bandwidth for that particular DLCI Tc = Bc / CIR Peak = CIR + Be / Tc = CIR (1 + Be / Bc) If the Tc is one second: Peak = CIR + Be = Bc + Be EIR = Be Frames sent in excess of Bc have the DE bit set. Frames sent in excess of Bc + Be are dropped.
CIR Options
Figure 15-1 provides a general and simplistic view of CIR.1 The CIR is computed over the minimum increment of Tc. Therefore, if Tc = 1.125s, a CIR of 64 kbps permits a Bc of 72 kbps (72 / 1.125 = 64). If the Bc is 144 kbps and the Tc is 1.125s, the CIR is 128 kbps (128 1.125 = 144).
Figure 15-1 Committed Information Rate (CIR), Excess Information Rate (EIR), and the Service Offering
Committed Information Rate (CIR) If Tc=1 Second, CIR=Bc Transmit if Possible Set DE=1 Unconditional Transmit Excessive Information Rate (EIR) If Tc=1 Second, EIR = Be
Discard All Access Rate
436
NOTE
Each users frame is sent at the wire (link) speed (access rate). The end user can be provisioned for a CIR of 128 kbps on a T1 link of 1.544 Mbps, and as a result, the trafc can burst across the link at 1.544 Mbps, which provides low latency in the ingress and egress points.
Several factors must be considered when selecting a CIR from the service provider. Some service providers offer CIRs in increments of 16 kbps, from 0 up to a fractional T1, full T1, and more. Others might not offer CIR = 0 (zero CIR) and might provide CIRs in increments of 4 kbps or 64 kbps. Another choice can be between 56 kbps and fractions of a T1. The cost of the service is proportional to the CIR; therefore, the choice can signicantly impact the monthly network charges for the enterprise.
Zero CIR Selection

If the design of the network is to carry only non-delay critical data, you should provision the circuit for CIR = 0. If the CIR = 0, every bit is marked with DE = 1. The fact that every frame is eligible for discard does not mean that the network drops the frame. In fact, service providers generally allow more than 99 percent of frames to ow from end to end. If the frame is dropped, the higher-layer protocols can retransmit the dropped packets. However, the frames can be delayed slightly until the network congestion clears. This is a trade-off for the lower cost of the service. Also, if all the endpoints are connected to the same Frame Relay switch, only the backplane of the switch is between them, and a CIR of 0 is often all that is needed for wire speed performance. The importance of CIR increases when the topology is more complex, such as in interswitch links. During times of network congestion, DE packets are the rst to be discarded, but the data wont be lost because the upper-layer protocols will retransmit them.
Aggregate CIR
Using an aggregate CIR, also referred to as oversubscription, can be a benecial technique when trafc bursts occur on different PVCs. For example, if a T1 is installed to a core router, and four users are each congured for four slots of 64 kbps (64 4 = 384 kbps), two basic line conditions exist in the PVC design: idle and busy. If only two users use the service and the other two are idle, the rst two can use the entire rate up to 1.544 Mbps, and because every user is setup for 384 kbps, every extra frame is marked with DE = 1. Regardless of the congured rate, the overall rate is much higher. Now, suppose that every user is congured for 768 kbps. The aggregated rate of all users congured is 2 1.544, which is referred to as an oversubscription. In this example, the ratio is 2:1, where the subscription rate is two times more (2 1.544) than the T1 speed (1.544).
Design Parameters
437
NOTE
Many people are uneasy with the idea of oversubscription, sometimes referred to as statistical multiplexing. Telephone companies (telcos) get a bad reputation for doing it, but Internet service providers (ISPs) do it to a much greater extent. Oversubscription of 7:1 or more from an ISP is not uncommon.
Usually, a 3:1 ratio is a sound ratio, depending on usage patterns. The important factor is to have a relatively reliable picture of the trafc distribution during the day, and the estimation that not all users will burst at the same time of day. Then, the 3:1 ratio reects a trafc prediction that no more than 33 percent of users will use the service during the same period each day.
Asymmetrical CIRs
For interactive query-response types of trafc and for typical client/server operations, the trafc in both directions can differ signicantly. For this reason, it makes sense to consider different CIRs in both directions. This is referred to as asymmetrical CIRs. They reduce the organizations service charges if they are appropriate for that organizations trafc.
Adjustable (Flexible) CIR

If the trafc can be planned precisely (for example, trending of the production environment with different shifts and number of users), and if the service provider supports this feature (for an additional fee), it is worth it to request an adjustable CIR. This feature is also known as bandwidth on demand and it can be benecial when you are trying to satisfy expected changes in bandwidth requirements. When requesting adjustable CIRs from the service provider, it is important to keep in mind the following parameters:
EIRA parameter that is measured in bps or kbps that identies the bits transmitted per second over the time period of Tc, which are beyond the CIR. Offered loadThe amount of data, measured in bits, that the user is ready to request for delivery to the selected destination (DLCI). Explicit congestion noticationThis term refers to the process of explicitly notifying the user of network congestion that is recognized as one of the following states: normal condition (no congestions), mild congestion, and severe congestion. Implicit congestion noticationThis term refers to the high-layer protocols role in Frame Relay or frame switching, where error and ow control operations depend on the frame congestion condition of the network.
438
UNI
The Frame Relay standards (refer to FRF 1.2) clearly dene bearer services provided by the network to make UNI possible. As shown in Figure 15-2, the UNI operation area is locally dened between the data terminal equipment/data communications equipment (DTE/DCE) peers. In turn, the bearer service denition includes the following:
Bidirectional frame transfer Preservation of the frame order Detection of transmission, format, and operational errors Transparent transport of user data, with modication of the address and error-control elds only No frame acknowledgment
Figure 15-2 Area of Operation for the User-Network Interface (UNI)

Remote User
Frame Relay Switch Laptop Computer
UNI CO
Desktop Computer
The underlying assumption of Frame Relay is low error rates. Therefore, only a simple, connection-oriented transport service is required. The ow-control and error-recovery functions are beyond the scope of Frame Relay and are provided by higher-layer protocols, such as the Transmission Control Protocol (TCP). Therefore, the reduced overhead of Frame Relay in comparison to other similar technologies is one of its greatest advantages, providing high-rate and large payload connections.
NOTE
The opposite of X.25, which was the transport of choice prior to Frame Relay, TCPs ability to detect errors and the robustness of current carrier quality networks pushed the role of ow control and error recovery from Layer 2 to Layer 3/4.
NNI
FRF2.1 denes the NNI, which extends user communications beyond the scope of UNI. The NNI interface is concerned with the transfer of C-plane and U-plane information
Design Parameters
439
between two network nodes that belong to two different Frame Relay networks. Figure 153 shows the area of operation of NNI. To keep the architecture functioning in a multivendor environment, network-to-network signaling must exist to keep the PVCs interconnected. To provide this functionality, every pair of adjacent networks (1 and 2; 2 and 3) must support additional provisions to request status information (see details in Chapter 16), and must be able to respond to them. These provisions are called bidirectional procedures. More information about this topic can be found in the Frame Relay Forums (FRFs) Frame Relay Network-to-Network Interface Implementation Agreement, or at www.frforum.com.
Figure 15-3 Area of Operation for the Network-to-Network Interface (NNI)
PVC Segment 1 PVC Segment 2
Remote User
Laptop Computer
Network 1 CO CO CO
Network 2 CO
Desktop Computer UNI PVC Segment 3
Multinetwork PVC
CO
Network 3 CO
UNI
Remote User
Desktop Computer Laptop Computer
440
Voice over Frame Relay

Voice over Frame Relay (VoFR) is dened under FRF.11.1. The Frame Relay approach requires the upper-layer protocols, such as the connection-oriented protocol TCP, to ensure end-to-end delivery of frames. However, retransmission results in repeating part of the voice message, which is not acceptable from a users standpoint. In this case, packetizing and buffering of the frames is required, where the entire message must be stored and played with the appropriate timing. Imminent transport layer retransmissions are not the only possible issues in VoFR designs. Other issues are related to voice compression, silence suppression, echo cancellation, and the ability to preserve voice quality. Additional information and the latest developments on VoFR are available from the FRF, and at www.cisco.com.
Frame Relay Multicast

The multicast provision exists in most local-area network (LAN) technologies and as part of the Internet Protocol (IP). Multicast is a feature that enables one source to send information to multiple recipients. A typical wide-area network (WAN) uses a point-topoint (unicast) connection, where the user transmits information to only one recipient. Frame Relay multicast is addressed in FRF.7, and this agreement denes one-to-many types of connection, where one sender who provides information to multiple recipients. The architecture is based on the International Telecommunication Union Telecommunication Standardization Sector (ITU-T) recommendation X.6, Multicast Service Denition. The model denes multicast groups, which includes a multicast server that provides service to all members of the group. In the case of Frame Relay, the server must be internal to the network, so that members can establish multipoint relationships and participate in point-tomultipoint data transfer. Three types of services are dened:
One-way Two-way N-way
In one-way service, a central location called a root has a point-to-point relationship with all other members of the group, which are called leaves. The root has a one-to-one connection to the server, as does every single leaf. Two-way multicast doubles the previously described structure, providing a full duplex connection. In N-way service, all members of the group are peers, thus every message is sent to all members of the group. The LMI extension provides the following multicast messages to ensure proper functioning of multicast groups:
Addition Deletion Presence
Frame Relay Topologies and Congestion Control
441

After a discussion about Frame Relay design parameters, an understanding of the various Frame Relay topologies becomes important.
Partial-Mesh and Full-Mesh Frame Relay Designs

Frame Relay networks provide several virtual circuits that form the basis for connections between stations (routers) that are attached to it. The resulting set of interconnected devices form a private Frame Relay group. These groups can be either fully interconnected with a complete mesh of virtual circuits, or only partially interconnected. In either case, each virtual circuit is uniquely identied at each Frame Relay interface by a DLCI. From an architectural point of view, a Frame Relay topology supports both partial-mesh and full-mesh structures. Because of the permanent nature of the connections, partial-mesh structures contain physical connections to some sites but not to all, thus creating an any-tosome structure. It becomes obvious that a fully meshed structure requires more resources because an any-to-any connection requires n number of sites to be connected to each other. This number can be calculated by using the following formula: Number of physical connections = n (n 1) / 2, where n is the number of connected routers.
NOTE
These topologies might exist not only on the service provider side, but in enterprises that use Frame Relay as a private network solution.
Regardless of the Frame Relay network topology, from an enterprise standpoint, two main congurable connections exist to the Frame Relay network: point-to-point and point-tomultipont congurations, which are addressed in detail in Chapter 16.
User and Frame Relay Switch Operations Under Congestion

The existence of virtual circuits and statistical multiplexing in Frame Relay requires sophisticated methods to deal with congestion. The Frame Relay specications provide guidelines and rules on how the user should react to forward explicit congestion notications (FECNs) and backward explicit congestion notications (BECNs). The Frame Relay switch at the ingress UNI must exercise caution in the amount of trafc that it permits to enter the network. To prevent severe congestion, you need to implement measures not only at the UNI, but at the switchs ingress point, which should know when to implement rate adoption control.
442
The software at the ingress point should be informed and fast enough to implement a remedy before the trafc load becomes a problem. There are no formal rules for the number of buffers, trafc, and throughput; however, the unofcial rule is the smaller the queue, the lower the delays and better response time. Two main methods control congestion in Frame Relay networks using explicit notication:
Rate adoption algorithmThe rate adoption algorithm uses both a system of counters and certain ratios of the number of bits to perform rate adjustments. This system is also called the leaky-bucket algorithm. The algorithm maintains a running count of the cumulative number of bits sent during a measurement interval. The counter decrements at a constant rate of 1 per bit, to a minimum value of 0, and increments to the value of the threshold.2 When the predened threshold is exceeded, the switch sets the FECN and BECN bits of the passing packet to 1, which noties both parties that the direction is experiencing congestion. Consolidated link-layer management (CLLM)Another congestion method involves using the CLLM message. CLLM transmits management messages over DLCI 1007 (or DLCI 1023 in T1.618), which is reserved for it. Thus, DLCI 1007 (1023) noties the edge switches that congestion has occurred and that the message contains a list of affected virtual connections. The edge switches then set up the FECNs and BECNs of the appropriate packets or issue another CLLM to end devices that support CLLM.
NOTE
Cisco uses Enhanced LMI (ELMI). Its usage is discussed in Chapter 16.
Figure 15-4 is an illustration of the rst method using the rate adoption algorithm. The rst Frame Relay network switch (called the Frame Relay Cloud [FRC] switch) experiences congestion. For this illustration, assume that the router connected to edge switch A sends data to both edge switch B and the router connected to edge switch B through the FRC switch. Then assume that there is additional trafc coming from the Frame Relay network to edge switch B. If the FRC switch and edge switch B are connected through a T1 and, at some point, the overall trafc increases and exceeds 1.5 Mbps, the FRC switch noties all switches of the congestion. For a short period of time, the buffers in the FRC switch overow and the frames are dropped. This is why the FRC switch sets the FECNs and BECNs to 1, in the manner shown in the gure. When the FRC switch reaches a certain threshold, it sets FECN = 1 in the frames that are coming from edge switch A and that are forwarded by the FRC switch to edge switch B. At the same time, the FRC switch sets BECN = 1 in the frames that are transmitted from edge switch B to edge switch A to identify the network that is experiencing congestion in the opposite direction. There is no standard criteria for setting BECNs and FECNs. It is obvious that different providers can choose different criteria to set up these bits. In most cases, router A lowers the transmission rate if the incoming messages contain BECN = 1.
443
Figure 15-4 The Frame Relay Congestion Mechanism and Use of FECNs and BECNs
Edge Switch Frame Relay Cloud
Edge Switch
Long-Distance Carrier Switch (FRC)
FECN=0 BECN=1 BECN=0
FECN=1
Edge Switch A
FECN=0 BECN=1 BECN=0
Edge Switch B
FECN=1
Router A
Router B
American National Standards Institute (ANSI) Annex A in T1.618 denes guidelines for using BECNs and FECNs by the user and the network. The FRC switch does not set the FECNs and BECNs directly. Instead, the FRC switch generates a CLLM to edge switches A and B, and these switches then decide to either set BECNs or FECNs or to generate another CLLM message to routers A and B. The CLLM messages are incompatible with the initial LMI specication because DLCI 1023 is used, but they are compatible with the Annex D specication.
Congestion and Windowing

Using windowing to manage congestion is suggested in the book ISDN and SS7: Architectures for Digital Signaling Networks by Ulysses D. Black. The basic approach resembles the windowing mechanism in the TCP/IP stack, but combines the FECNs and BECNs with the sliding window technique. Unlike TCP, the sliding window technique reduces and increases the size of the window by a factor of 0.125, depending on the network conditions. In Cisco routers, windowing is congurable by parameter K, where K is a maximum number of I-frames that are either outstanding for transmission or transmitted but not acknowledged. The value of K ranges from 1 to 127 frames, with a default of 7. The calculations are based on 2 to the exponent n, where if n = 3, the enumeration of windows is from 0 to 7.
444
Frame Relay Performance Criteria

The design of Frame Relay requires setting objectives for the future network design, when conducting capacity planning, and developing the ability to measure performance using different criteria. Section 4 of T1.606 contains several denitions of Frame Relay performance parameters. The following sections summarize these performance parameters.
Throughput
The term throughput is dened as the number of protocol data units (PDUs) successfully transferred (FCS indicates success) in one direction, per a predened time period (measurement interval) over a virtual connection. For this denition, the PDU is considered to be all data between the ags of the Frame Relay frame (see Figure 14-4).
Transit Delay
The transit delay is a measurement of the time it takes to send a frame across the link between two points (DCE, Frame Relay access device (FRAD), router). The delay is a function of the access rate of the link, the distance, and the size of the frame. A rough estimate can be obtained by using the following equation: Delay (seconds) = size (bits) / link access rate (bps) Transit delay is measured between boundaries, which can be between two adjacent DCEs, two networks, and so forth. Based on the boundary, the measurement starts when the rst bit of the PDU leaves the source (t1), and ends when the last bit of the PDU crosses the other partys boundary (t2). The transit delay can be measured by the following equation: Transit delay = (t2) (t1) The virtual circuit transit delay is the sum of all delays across all boundaries of the virtual connection.
Residual Error Rate

Residual error rate (RER) is synonymous with the undetected error ratio of the number of bits incorrectly received and undetected to the total number of bits sent. RER is measured through the exchange of Frame Relay service data units (SDUs), or FSDUs. This measurement can be calculated from the following formula: RER = 1 (total correct delivered SDUs / total offered SDUs) RER is an important component when considering future use of bandwidth demand. The future design must address these parameters when evaluating the service offerings from different providers.
Frame Relay and Upper-Layer Protocols
445
At the same time, RER must be correlated with the users actual throughput and CIR. If the user constantly exceeds the CIR agreement, a high RER is expected. Conversely, if the design parameters are not exceeded, a lower RER is expected.
Other Performance Parameters

The following parameters are dened by the ITU-T, and are referred to as quality of service (QoS) parameters that affect network performance:
Delivered erroneous framesThe number of frames that are delivered when one or more bits in the frame are discovered erroneous. Delivered duplicate framesThe number of frames delivered twice or more. Delivered out-of-sequence framesThe number of frames that are not in the expected sequence. Lost framesThe number of frames not delivered within the predened time period. Misdelivered framesFrames delivered to the wrong destination. Switched virtual call establishment delay and clearing delayThese refer respectively to the time required to establish and clear the call across the C-plane. Premature disconnectDescribes the loss of the PVC. Switching virtual call clearing failureDescribes a failure to teardown the switched virtual call.

Flow control and error recovery functions can be performed by the full LAPF protocol. Typically, the full LAPF is not used in PVC circuits. Therefore, these functions must be performed by the higher-layer protocols, which are encapsulated in the PDU as a component of the information eld of the frame format. This approach is the most commonly implemented today. To ensure the interoperability of Frame Relay and higherlayer protocols, two major issues must be addressed: multiprotocol support and fragmentation. Multiprotocol support refers to the encapsulation of higher-layer protocols such as IP, TCP, Internetwork Packet Exchange (IPX), and X.25, in the frame format. FRF.3.2 and RFC 1490, Multiprotocol Interconnect over Frame Relay (by Bradley and published by IETF) both address this topic. Fragmentation refers to the process of dividing large network packets into smaller packets and then reassembling them at the receiver site. This subject is governed by ANSI T1.617a Annex A, Signaling Specication for Frame Relay Bearer Service for Digital Subscriber Signaling System Number 1 (DSS1) Protocol Encapsulation and PICS.
446
Frame Relay carries two types of data: routed packets and bridged packets. The remote users router must distinguish between the two types of frames. To assist with this purpose, up to four elds can be added to the T1.618 information eld format, as shown in Figure 15-5. They are the Network Layer Protocol ID (NLPID), L2 Protocol ID, L3 Protocol ID, and Subnetwork Access Protocol (SNAP).
Figure 15-5 Multiprotocol Encapsulation Options
1
Q.922 Control
0-1 Optional Pad
1 NLPID
2* L2 Protocol ID
2* L3 Protocol ID
** SNAP Header Higher Layer Information
*These fields are used with NLPID=0x08 only. **These fields are used with NLPID=0x80 only.
3 Organizationally Unique Identifier (OUI)
2 Protocol Identifier (PID)
NLPID 0x00 0x08 0x80 0x81 0x82 0x83 0xCE 0xCF 0xCC
Protocol Null Network (Inactive Set) (Not Used with Frame Relay) Q.933 SNAP ISO CLNP ISO ESIS ISO ISIS EtherType Unofficial Use PPP Internet IP With Preserved FCS (h) 00 01 00 02 00 03 00 04 00 05
OUI
00 00 00h (Routed Packets) 00 80 C2h (Bridged Packets)
PID EtherType Without Preserved FCS (h) 00 07 00 08 00 09 00 0A 00 0B 00 0D 00 0E 00 0F Media 802.3 /Ethernet 802.4 802.5 FDDI 802.6 Fragments BPDUs, Defined by 802.1d or 802.1g Source Routing BPDUs
447
The Q.922 Control eld species an Unnumbered Information (UI), Supervisory (S), or Information (I) frame. The Pad eld aligns the rest of the frame on a two-octet boundary and contains up to a single octet with the value 00h. The ISO and ITU-T administer the NLPID, which denes the encapsulation of the protocol that follows. The common values are 08h for Q.933; 80h for SNAP; 81h for ISO Connectionless Network Protocol (CLNP); and CCh (0xCC) for IP. In some cases, Layer 2 and Layer 3 Protocol IDs or a SNAP header follow the NLPID. Some of the encapsulated protocols are covered in the next section.
Encapsulating IP, Q.933, and SNAP

ANSI T1.617a Annex F denes the standards for encapsulating IP, Q.933, and SNAP. When encapsulating IP, an optional pad can be added to align the rest of the frame on a two-octet boundary. No further control information, such as IDs or a SNAP header is required. The encapsulation format for Q.933 can be used when no specic network protocol is dened. SNAP is used for encapsulating bridged IEEE 802.3 frames for routed and bridged packets that contain LAN-to-LAN trafc. The NLPID is set to 80h and is followed by a 5-byte SNAP header (3-byte OUI + 2-byte PID). Routed packets use OUI 00 00 00h, and bridged packets use OUI 00 80 C2h to identify the IEEE 802.1. Figure 15-6 shows the encapsulation formats for IP, Q.933, and SNAP.
Figure 15-6 Encapsulating IP, Q.933, and SNAP
IP
1 Q.922 Cntrl (03h)
1 NLPID (CCh)
Variable IP Datagram
2 FCS
1 Flag 01111110
Flag Address 01111110 Q933
1 Q.922 Cntrl (03h)
1 NLPID (08h)
Variable Protocol Data
2 FCS
1 Flag 01111110
Flag Address 01111110 SNAP
L2 L3 Protocol ID Protocol ID
1 Pad 00h
Variable
Q.922 Flag Address Cntrl 01111110 (03h)
PID NLPID OUI 00 01h or (80h) 00 80 C2h 00 07h
802.3
LAN FSC Flag If PID FCS 01111110 Is 0001h
448
Encapsulating Other Protocols over Frame Relay

To indicate the usage of the ISO CLNP protocol, the NLPID eld must be set to 81h. As soon as the NLPID eld indicates ISO CLNP, the data packet immediately follows. NLPID is also considered part of the CLNP packet, and as such, it should not be removed before being sent to the upper layers for processing. IPX does not have a NLPID value dened. For this reason, IPX is encapsulated using the SNAP header. The frame format is in the following order: Initial Q.922 Address and Control eld = 03h, then the Pad eld is added (00h). NLPID is 80h (SNAP) and OUI = 00 00 00h (routed packets), followed by PID = 8137h, and then the IPX packet itself with possible fragmentation. FRF.3.2 provides additional encapsulation examples, including Systems Network Architecture (SNA) and NetBios trafc over Frame Relay.
Frame Relay Fragmentation

The upper-layer protocols use different formats and usually the information eld contains more than one T1.618 frame. T1.617A Annex F and RFC 1490 address the fragmentation process. When a packet must be fragmented, the fragmentation protocol adds an encapsulation header to it and divides the packet into many smaller fragments, according to network requirements. Each fragment receives a fragmentation header (see Figure 15-7). In the example, the size of the IP packet is greater than the size of the T1.618 frame, and you use the RFC 1490 recommendations. The fragmentation header consists of four elds:
A Sequence (Seq.) eld (2 bytes) that is incremented for every fragment A Reserved (Rsvd) eld (4 bits, all 0s) A Final bit, which is 0 for the rst fragment and 1 for the last one An Offset eld, which is an 11-bit value that represents the logical offset of this fragment, divided by 32. The rst fragment has an offset = 0.
The Cisco recommendations for fragment sizes in Table 15-1 are based on port access rates.
Table 15-1 Cisco Recommendations for Fragment Sizes Port Access Rate 64 kbps 128 kbps 256 kbps 512 kbps 1536 (full T1) 2048 (full E1) Recommended Data Segmentation Size 80 bytes 160 bytes 320 bytes 640 bytes 1600 bytes 1600 bytes
LMI
449
Figure 15-7 Fragmented IP Packet in Frame Relay
1 IP Datagram
Encapsulation Header Q.922 Control UI Frame NLPID
Fragment 1
Fragment 2
Fragment 1
1
F
2
A D D R
1
Q.922 Cntrl (03h)
1
Pad 00h
1
NLPID (80h)
3
OUI 00 80 C2h
2
PID 00 01h
2 Seq. n
F (0)
4 Rsvd Offset (0)
1 Q.922 Cntrl
2
NLPID CCh
1
F
First m Bytes of F IP Datagram C S
SNAP Header
Fragmentation Header
Fragment 1
Fragment 2
1
F
2
A D D R
1
Q.922 Cntrl (03h)
1
Pad 00h
1
NLPID (80h)
3
OUI 00 80 C2h
2
PID 00 01h
2 Seq. n
F (1)
4 Rsvd Offset (m/32)
1 Q.922 Cntrl
2
NLPID CCh Remaining Part of IP Packet
2
F C S
1
F
SNAP Header
Fragmentation Header
Fragment 2
LMI
A consortium of companies known as the Gang of Four, which is composed of Cisco Systems, Inc., Digital Equipment Corp, Northern Telecom, and StrataCom, Inc., developed and published the LMI for UNI. The LMI is a set of enhancements to the basic Frame Relay specication that include the following:
Virtual circuit status messagesThe only common extension Multicasting messagesOptional LMI extension Global addressing messagesOptional LMI extension Simple ow controlOptional LMI extension
450
The derivatives of the LMI Consortium were formally adopted as T1.617 Annex D and Q.933 Annex A. The rst group of messages, known as the virtual circuit status messages, are the only common LMI (adopted by all vendors) extensions (see Figure 15-8).
Figure 15-8 The UNI LMI Area of Operation
Remote User Frame Relay Switch Mapping Laptop Computer Frame Relay Switch Corporate
Frame Relay Network

CO CO
Desktop Computer
LMI Messages
Three different LMI types are supported by Cisco:
Cisco-Consortium ANSI-T1.617 Annex D Q.933a-ITU-T Q.933 Annex A
These formats are related to Frame Relay troubleshooting, and their differences are described in the following sections. The purpose of the Annex D LMI type is to create a multivendor LMI type. The difference between Cisco LMI and Annex D LMI is that, in Annex D, ANSI provides a signaling scheme derived from the initial LMI agreement. To avoid confusion, the Consortium LMI is referred to as the Consortium, and the ANSI T1.617 LMI is referred to as Annex D.3 The LMI messages periodically poll the network using the Q.931 structure, and are transmitted in HDLC UI frames. To indicate the LMI message, Consortium LMI uses DLCI 1023, whereas Annex D LMI uses DLCI 0. In both cases, the FECN, BECN, and DE bits are set to 0. Within the Q.931 header of Annex D messages, the PD eld is set to 08h, and the Consortium LMI sets the PD eld to 09h. The Dummy Call Reference and message types are identical, but unlike Consortium, Annex D adds the Locking Shift information element (IE) to the message header.
NOTE
The remaining discussion uses Consortium to refer to the original LMI specications, and Annex D to refer to ANSI (T1.617 Annex D).
LMI
451
Consortium (Cisco) LMI Type

The Consortium designed the LMI protocol to perform the following functions:
Allow the network to notify the FRAD about active and present DLCIs Allow the network to notify the FRAD if DLCI is removed or fails Monitor the status of the router-to-network link in real-time through keepalive messages
The Consortium LMI denes two messages: status enquiry and status. The general format of this LMI type is shown in Figure 15-9.
Figure 15-9 Format of Consortium LMI Messages
1 Flag 01111110
2 Address
2 FCS
1 Flag 01111110
1
Control UI Frame 03h
Consortium Message Header 1 1 1 Protocol Call Message Descriminator Reference Type (09h) (00h)
n IE1
n IE2
n IE...
The Message Type Can Be: 0111 1101 Status 0111 0101 Status Inquiry
Both messages are sent in HDLC UI frames, with a Control eld value of 03h. The threeoctet message header is based on Q.931 and includes a Protocol Discriminator (09h), a Call Reference Value (00h, also a Dummy Call Reference), and a Message Type indicator. The message types are 75h (0111 0101) to indicate status enquiry, and 7Dh (0111 1101) to indicate status.
Annex D (ANSI) LMI Type

The T1.617 Annex D denes a polling protocol for use between the router and the network to exchange information about the status of the interfaces and the dened PVCs. The functions of the protocol are as follows:
Notication of the addition of a PVC Detection of the deletion of a PVC
452
Notication of the availability or unavailability of a congured PVC Verication of the integrity of the link (UNI)
The router periodically polls the network, sending a status enquiry message, and the network responds with a status message. The polling period is a negotiable parameter, and ten seconds is the default. The rst poll requests a link integrity verication response to determine the status of the in-channel signaling link. Another polling cycle (typically every six polling cycles) occurs when the user requests the status of all PVCs on the interface. The resulting response is a full status message that contains information on each PVC that is congured on that physical channel. The information includes the recent history of the PVC and its availability (inactive or active). The periodic polling for Annex D also detects error conditions, such as reliability errors of DLCI 0, signaling-link protocol errors, or internal network problems. The format of these messages is shown in Figure 15-10.
Figure 15-10 Format of Annex D LMI Messages
1 Flag 01111110
2 Address
2 FCS
1 Flag 01111110
1
Annex D Message Header 1 1 1 Protocol Call Message Descriminator Reference Type (08h) (00h)
1 Locking Shift (95h)
n IE1
n IE2
n IE...
The Message Type Can Be: 0111 1101 Status 0111 0101 Status Inquiry
Although the Consortium status enquiry messages use the Report Type and Keepalive Sequence IEs, the Annex D status enquiry messages contain Report Type and Link Integrity Verication IEs (see Figure 17-3 and 17-5). The Link Integrity Verication IE (03h) provides an identication ID in the rst byte. The second byte indicates the length of the integrity verication content. The third byte is the end sequence number and the fourth byte is the receive sequence number.
Address Resolution: ARP, Reverse ARP, and Inverse ARP
453
ITU-T Q.933 Annex A LMI Type

The vast majority of contemporary Frame Relay solutions are based on PVCs. However, for SVC, the ITU-T Q.933 Annex A LMI type is recommended. For more information, refer to Cisco documentation or the book Frame Relay for High-Speed Networks, by Walter Goralski. In terms of LMI global addressing, Frame Relay resembles a LAN. Address Resolution Protocol (ARP) operates in Frame Relay exactly as it does in a LAN where ARP maps Layer 3 IP to Layer 2 Media Access Control (MAC). The Inverse ARP implementation for Frame Relay is described in the next section.
Address Resolution: ARP, Reverse ARP, and Inverse ARP

The higher-layer protocol encapsulation in Frame Relay formats raises the issue of resolving the upper-layer addresses to Frame Relay addressing schemes. Especially in point-to-multipoint connections, where the hub side has many Layer-3 addresses (typically IPs) assigned, you need to resolve the Layer-2 address (regardless if it is a DLCI or Q.922 address) to the Layer-3 address (IP). The problem can be resolved by polling all subinterfaces for hardware and protocol address resolution, but this method does not seem appropriate. The Frame Relay network provides several virtual circuits that form the basis for connections between stations that are attached to the same Frame Relay network. Every DTE in Frame Relay can have a DLCI, which is the Frame Relay equivalent of a hardware address that is associated with an established PVC, but DTE does not know the protocol address of the other party.
ARP
Address resolution can be accomplished by using the standard ARP encapsulated within a SNAP. DLCIs have a local signicance for the Frame Relay networks, but they have no signicance whatsoever for the end station (for example, a computer) connected to the Frame Relay router. Therefore, such a station does not have an address to put into the ARP request or reply. The DLCI carried within the Frame Relay header is modied as it traverses the network. When the packet arrives at its destination, the DLCI has been set to the value that, from the standpoint of the receiving station, corresponds to the sending station, but when an ARP message reaches a destination, all hardware addresses are invalid. However, the address found in the frame header is correct. It looks like Frame Relay can use this address in the header as the sender hardware address and still perfom ARP. However, the problem is that the target hardware address in both the ARP request and reply will be also invalid.
454
Reverse ARP
Could Reverse Address Resolution Protocol (RARP) be a solution? RARP works the same way as ARP. The response to a request returns the protocol address of the requesting station, not the address of the station receiving the request. IP-specic mechanisms are designed to only support the IP protocol. Obviously, ARP and RARP are not a solution, and a new address resolution variation was developed. This variation is called Inverse ARP (InARP), which is essentially an expanded ARP.
Inverse ARP
InARP enables a Frame Relay station to discover the protocol address of a station that is associated with the virtual circuit. It is more efcient than sending ARP messages over every virtual circuit for every address that the system wants to resolve, and it is more exible than relying on a static conguration. Basic InARP operates essentially the same as ARP, with the exception that InARP does not broadcast requests. This is because the hardware address of the destination station is already known. A requesting station simply formats a request by inserting its source hardware, protocol addresses, and the known target hardware address. It then zero lls the target protocol address eld. Finally, it encapsulates the packet for the specic network and sends it directly to the target station. In a Frame Relay interface that supports data-link management, an InARP-equipped station that is connected to such an interface sends an InARP request and addresses it to the new virtual circuit. If the other side supports InARP, it can return a response that provides the requested protocol address. In a Frame Relay environment, InARP packets are encapsulated using the NLPID/SNAP format. For more information on the InARP protocol format, see www.faqs.org/rfcs/rfc2390.html. In Cisco routers, the InARP is established by default and does not show up in the conguration. From a conguration point of view, using InARP is referred to as dynamic mappingsee Chapter 16 for more details. InARP does not work without LMIs because it uses LMI messages to determine which PVC to map (remember that LMI carries information for all congured PVCs). If the DLCI is down, the Cisco router still processes and maps an InARP, but does not use it until DLCI is reported as active.
End Notes
1 Kessler,
Gary. Frame Relay: CIR and Billing Issues. Network VAR, 1995.
2 Stallings, W. ISDN and Broadband ISDN with Frame Relay and ATM. Prentice Hall, 1998. 3 American
National Standards Institute. Integrated Services Digital Network (ISDN) Signaling Specications for Frame Relay Bearer Services for Digital Subscriber Signaling System Number 1 (DSS1). ANSI T1.617 Annex D, 1991.
Review Questions
455
Summary
Frame Relay design is an imminent part of enterprise remote access solutions. In fact, the design and provisioned parameters dene the ability of the enterprise to use the versatility and exibility of Frame Relay for its own benets. In this chapter, you learned about design parameters, UNI and NNI interfaces, and VoFR and Frame Relay multicast. Extended information about Frame Relay topologies, congestion control, and performance criteria is another major topic of the chapter. The higher-layer protocol encapsulations and fragmentation are provided in detail. In turn, the higher-layer encapsulation requires resolution of Layer 3 and Layer 2 addresses, where ARP, RARP, and InARP are explained.
Review Questions
1 Dene the term access rate (link speed). 2 What is the recommendation for setting the committed interval Tc in Frame Relay? 3 Dene the committed information rate (CIR). 4 Dene the excess information rate (EIR) 5 Dene the explicit congestion notication types. 6 What is the area of operation of UNI in Frame Relay. 7 Dene the area of operation of NNI. 8 Name the three Frame Relay multicast messages. 9 If n is the number of connected routers, dene the number of physical connections in
a full-mesh topology.
10 Name the two main methods to control congestion in Frame Relay networks by using
explicit notication:
11 What is transit delay? How do you obtain a rough estimate of transit delay? 12 Name the four main specic and common specications of LMI. 13 Name the three LMI types that are supported by Cisco. 14 Can InARP run without LMI?
CHAPTER
16
Basic and Advanced Frame Relay Congurations

The conguration options in Frame Relay are derived from the design and provisioning choices made in earlier phases of Frame Relay service. In the conguration phase, it is preferable to apply a Hub/Spoke topology, as described in Chapter 15, Frame Relay Design Solutions, which is more suitable to the permanent nature of Frame Relay. This chapter provides detailed information about basic and advanced congurations in Cisco Frame Relay routers. The Frame Relay encapsulations (cisco, ietf), DLCI encapsulations (cisco, ietf, ppp, and protocol) and LMI types (cisco, ANSI, and q933a) will not be discussed here. Cisco.com provides detailed information about these topics. This chapter includes two main sections:
Basic Frame Relay congurations: Point-to-multipoint congurations Point-to-point congurations, their hub side and spoke side Minimum data-link connection identier (DLCI) recommendations Frame Relay and the chosen routing protocols The Frame Relay broadcast queue
The advanced conguration sections include the following: Conguring IP unnumbered Frame Relay Frame switching conguration ISDN as Frame Relay backup conguration, based on dialer proles and Hot Standby Router Protocol (HSRP) and Enhanced Interior Gateway Routing Protocol (EIGRP) Frame Relay bridging Frame Relay compression, including header compression, per-virtual circuit compression, and hardware compression Frame Relay and IP multicast conguration Frame Relay and trafc shaping with generic trafc shaping, trafc shaping classes, and foresight adaptive shaping with Enhanced Local Management Interface (ELMI)
458
Chapter 16: Basic and Advanced Frame Relay Congurations
Basic Frame Relay Congurations

This section covers the basic Frame Relay conguration information including point-tomultipoint congurations, point-to-point congurations, minimum DLCI recommendations, and the Frame Relay broadcast queue.
Point-to-Multipoint Congurations
The basic Frame Relay congurations for point-to-multipoint include the conguration of both the core (hub) and the remote users (spoke) side. Figure 16-1 shows an example of this conguration.
Figure 16-1 Hub and Spoke in a Point-to-Multipoint Conguration
7206-Frame FastEthernet 0/0 IP Address 181.70.192.22 255.255.255.224
Hub
Serial 0 DLCI=100, 200, 300, 400 IP Address 181.68.1.1 255.255.255.0
Frame Relay Cloud
Spoke
s
12
Fra c
2500-Frame Interface Serial 1 DLCI=101 IP Address 181.68.1.2 255.255.255.0
lT
ct Fra
1-
ion
1 al T
-1
8k
28
kbp
bp
56
kbp
56
tio
na
kb ps
Ethernet0 10.0.1.0/29 Ethernet0 10.0.2.0/29 Ethernet0 10.0.3.0/29
Ethernet0 10.0.4.0/29
C1-IP 10.0.1.2
C4-IP 10.0.4.2
C2-IP 10.0.2.2
C3-IP 10.0.3.2
459
Point-to-Multipoint Conguration of the Hub

Example 16-1 shows a hub side conguration, including the FastEthernet interface and the serial interface of the core router.
Example 16-1
Basic Hub Conguration in a Point-to-Multipoint Conguration

7206-frame#show running-config <output omitted> interface FastEthernet0/0 description FastEthernet connection to gateway1 ip address 181.70.192.22 255.255.255.224 ! interface Serial0 ip address 181.68.1.1 255.255.255.0 encapsulation frame-relay frame-relay interface-dlci 100 frame-relay interface-dlci 200 frame-relay interface-dlci 300 frame-relay interface-dlci 400 ! ! router eigrp 19 network 181.68.0.0 network 181.70.0.0 ! <output omitted>
In this conguration, the hub side is congured on a Cisco 7206x router (7206-frame) and is connected to four spoke routers with DLCI 100, 200, 300 and 400. The conguration uses dynamic mapping based on Inverse ARP (InARP). InARP is enabled by default and no additional command is required on interface Serial0. The routers learn the DLCIs from the Frame Relay switch through Local Management Interface (LMI) updates. The routers then use InARP for the remote Internet Protocol (IP) address and create a map of local DLCIs and their associated remote IP addresses (see the section, Inverse ARP in Chapter 15). When Frame Relay InARP is enabled, broadcast IP trafc goes out over the connection by default. Using InARP is called dynamic mapping. The response from InARP is stored in an address-to-DLCI mapping table on the router that supplies the next hop protocol address for the outgoing interface. As discussed in Chapter 15, an alternative to using InARP is static mapping. You must use static mapping if the router at the other end either does not support InARP, or does not support InARP for a specic protocol. To establish static mapping according to your network needs, use the commands in Example 16-2. Pay attention to the mapping statements under the Serial0 interface. In this conguration, the Internet Engineering Task Force (IETF) encapsulation is set up on a per-DLCI Basis. If all DLCIs are using the same encapsulation type, you can use a shorter conguration by conguring the IETF encapsulation on a per-interface basis.
460
Example 16-2
Static Mapping Conguration of the Hub Serial Interface

7206-frame#show running-config <output omitted> interface Serial0 ip address 181.68.1.1 255.255.255.0 encapsulation frame-relay frame-relay map ip 181.68.1.2 100 broadcast frame-relay map ip 181.68.1.3 200 broadcast frame-relay map ip 181.68.1.4 300 broadcast frame-relay map ip 181.68.1.5 400 broadcast <output omitted>
ietf ietf ietf ietf
NOTE
In the latter case, encapsulation frame-relay becomes encapsulation frame-relay ietf, and each static mapping statement changes. For example, frame-relay map ip 181.68.1.2 100 broadcast ietf becomes frame-relay map ip 181.68.1.2 100 broadcast, and so on.
The protocol IP address 181.68.1.2 is bound to DLCI = 100. The command frame-relay map ip 181.68.1.2 100 broadcast ietf can be interpreted as saying, If you want to reach IP 181.68.1.2, use DLCI 100, thus mapping a next hop protocol address to the DLCI that connects to the protocol address. InARP is enabled by default for all protocols that it supports, but it can be disabled for specic protocol-DLCI pairs. When you supply a static map, InARP is automatically disabled for the specied protocol on the specied DLCI.
NOTE
The keyword broadcast greatly simplies the conguration for the Open Shortest Path First (OSPF) protocol. See Cisco IOS Wide-Area Networking Command Reference for more information about using the broadcast keyword.
You can use dynamic mapping for some protocols and static mapping for other protocols on the same DLCI. You can disable InARP for a protocol-DLCI pair if you know that the protocol is not supported on the other end of the connection.
Point-to-Multipoint Conguration of the Spoke

The conguration on the remote users router (spoke) is similar to the conguration segment in Example 16-3.
Example 16-3
Conguring the 2500-Frame Router as a Spoke in a Point-to-Multipoint Conguration

2500-frame#show running-config <output omitted> interface Ethernet0 ip address 10.0.1.1 255.255.255.248
461
Example 16-3
Conguring the 2500-Frame Router as a Spoke in a Point-to-Multipoint Conguration (Continued)

! interface Serial1 ip address 181.68.1.2 255.255.255.0 encapsulation frame-relay frame-relay interface-dlci 101 ! ! router eigrp 19 network 10.0.0.0 network 181.68.0.0 ! <output omitted>
Similarly, this side can apply InARP or static mapping. If the following command is applied to Interface Serial1, the protocol IP address 181.68.1.2 is bound to DLCI = 101:
frame-relay map ip 181.68.1.1 101 broadcast ietf
This can be interpreted as saying, If you want to reach IP 181.68.1.1, use DLCI 101, thus mapping a next-hop protocol address to the DLCI 101 to connect to the protocol address. Dynamic and static mapping is applicable to this conguration. With a point-to-point conguration, however, only the static mapping solution is applicable.
Point-to-Point Congurations
Conguring a physical interface with multiple subinterfaces or multiple virtual interfaces is another example of the virtuality used in Cisco routers. This approach is commonly used in point-to-point congurations. The benets of this conguration are realized in partially meshed Frame Relay designs. The concept of subinterfaces was originally created to better handle issues caused by split horizon over nonbroadcast multiaccess (NBMA) networks (such as Frame Relay, Asynchronous Transfer Mode [ATM], Switched Multimegabit Digital Service [SMDS], or X.25), the distance vector-based routing protocols (such as Internetwork Packet Exchange [IPX] Routing Information Protocol/Service Advertisement Protocol [RIP/SAP], AppleTalk, and IP RIP), and transparent bridging. A virtual interface overcomes the rules imposed by split horizon. Because every virtual interface can be considered a separate interface, sending packets back to the same physical interface does not violate the rules of split horizon. The point-to-point conguration solution allows the transformation from a partially meshed to a de facto, fully meshed conguration. To the routed protocol, each subnetwork now appears to be located on separate interfaces. Routing updates that are received from one side on one logical point-to-point subinterface can be forwarded to another on a separate logical interface without violating split horizon.
NOTE
In the NBMA model, all routers are congured as one logical subnet. As such, NBMA resembles a local-area network (LAN) logical topology.
462
NOTE
The split horizon rule states the following: Never advertise a route out of the interface through which it was learned.
The basic hub and spoke conguration in a point-to-point conguration is shown in Figure 16-2.
Figure 16-2 Hub and Spoke in a Point-to-Point Conguration
7206-Frame FastEthernet 0/0 No IP Address
Hub
Subinterface - Interface Serial4/2:0.100 point-to-point ip unnumbered Loopback0 Subinterface - interface Serial4/2:0.200 point-to-point ip unnumbered Loopback0
Interface Serial 4/2:0 Subinterface - interface Serial4/2:0.300 point-to-point ip unnumbered Loopback0 Subinterface - interface Serial4/2:0.400 point-to-point ip unnumbered Loopback0
Frame Relay Cloud
Spoke
-1
Fra cti
Interface Serial1.101 Point-To-Point IP Unnumbered Ethernet0 DLCI=101
ct Fra
T1
io
T1 nal
28
-1
28
kbp
kb ps
56 k
bps
56
on
al
ps kb
2500-Frame Interface Serial 1 no IP Address Ethernet0 10.0.1.0/29
1602-Frame Interface Serial 1 no IP Address
Ethernet0 10.0.2.0/29
C1-IP 10.0.1.2
C4-IP 10.0.4.2 C2-IP 10.0.2.2
C3-IP 10.0.3.2
Point-to-Point Conguration of the Hub

The core side is congured according to Example 16-4. Here, the Serial4/2:0 interface, a T1/Channelized Primary Rate Interface (PRI), is congured with four subinterfaces: Serial4/2:0.100, Serial4/2:0.200, Serial4/2:0.300, and Serial4/2:0.400. It is good practice to have the circuit description under the T1/PRI, as in Example 16-4. When working with the service provider, one can reference the interface description for circuit information.
463
Example 16-4
Conguration of 7206-Frame as a Hub Router in Point-to-Point Congurations

7206-frame#show running-config <output omitted> interface Serial4/2:0 description Home Frame Relay : NUA :5555555511 : HICAP CID XXXYYZZZ72HCR-001 no ip address encapsulation frame-relay no ip route-cache no fair-queue frame-relay traffic-shaping frame-relay lmi-type ansi frame-relay broadcast-queue 100 1200 120 ! interface Serial4/2:0.100 point-to-point description 2500-frame: 10.0.1.0/29 bandwidth 128 ip unnumbered Loopback0 no ip route-cache frame-relay class class-128-new frame-relay interface-dlci 100 ! interface Serial4/2:0.200 point-to-point description 1602-frame : 10.0.2.0/29 : 14716506 : 3842400259 bandwidth 128 ip unnumbered Loopback0 no ip route-cache frame-relay class class-128-new frame-relay interface-dlci 200 ! interface Serial4/2:0.300 point-to-point description 2500-frame1 : 10.0.3.0/29: : 3823600256 bandwidth 56 ip unnumbered Loopback0 no ip route-cache frame-relay class class-56-new frame-relay interface-dlci 300 ! interface Serial4/2:0.400 point-to-point description 1602-frame1 : 10.0.4.0/29 : 14787359 : 3872200079 bandwidth 56 ip unnumbered Loopback0 no ip route-cache frame-relay class class-56-new frame-relay interface-dlci 400 ! interface Loopback0 description monitoring loopback 0 interface ip address 192.3.25.75 255.255.255.255 <output omitted>
464
It is good practice to have a description for every DLCI and user to make remote troubleshooting easier. You can locate that particular interface quickly by using the different search/nd features of IOS. The line description 2500-frame: 10.0.1.0/29 explains that this subinterface is congured for a spoke user, called 2500-frame. The rest of the subinterfaces are congured in a similar manner. Another recommended technique in this conguration is to use the description of the subinterface that is consistent with the DLCI number. It saves time in the troubleshooting process by matching the subinterface number with its associated DLCI. The congured loopback 0 interface allows any monitoring tool to monitor the status of the 7206-frame router. The IOS feature IP unnumbered is discussed in the advanced conguration section. An important part of the hub conguration in point-to-point congurations is to dene how routing is performed. For the purposes of this example, dynamic EIGRP routing is used for the hub router, and static routing is used for the spoke routers. The important routing segments of the conguration are shown in Example 16-5 and Example 16-6. Example 16-5 shows how to prevent other routers on a local network from learning about routes dynamically. One approach here can be to keep routing update messages from being sent through a router interface. This feature applies to all IP-based routing protocols except the Border Gateway Protocol (BGP), and can be congured in the global conguration mode with the following command:
Router(config-router)#passive-interface interface-type interface-number
Example 16-5
Conguring the Passive Interfaces in the Hub Router

<output omitted> router eigrp 19 redistribute static passive-interface Serial4/2:0.100 passive-interface Serial4/2:0.200 passive-interface Serial4/2:0.300 passive-interface Serial4/2:0.400 network 10.0.0.0 no auto-summary no eigrp log-neighbor-changes
As usual, to congure the static routing statements, you must add the commands shown in Example 16-6. In this example, there is a next hop address for subinterfaces of 10.0.1.1, 10.0.2.1, 10.0.3.1, and 10.0.4.1. To dene the next hop address of the routing statement, you must refer to the advanced conguration section, where it is explained how the subinterface Serial1.201 obtains its IP address from the Ethernet 0 interface of the spoke router.
465
Example 16-6
Conguring the Routing Statements in the Hub Router

<output omitted> ip classless ip route 10.0.1.0 ip route 10.0.2.0 ip route 10.0.3.0 ip route 10.0.4.0 <output omitted>
255.255.255.248 255.255.255.248 255.255.255.248 255.255.255.248
Serial4/2:0.100 Serial4/2:0.200 Serial4/2:0.300 Serial4/2:0.400
10.0.1.1 10.0.2.1 10.0.3.1 10.0.4.1
Point-to-Point Conguration of the Spoke

Next, you congure the spoke router to ensure consistency with the hub router. The Ethernet interface is congured with a static IP address and helper address. The Serial1 interface is congured for 128 kbps (service-module t1 timeslots 1-2) with no IP address. Subinterface Serial1.201 obtains an IP address through the IP unnumbered feature of IOS, which is explained in the advanced conguration section of this chapter. The default route statement points to the Loopback0 address of the hub router (192.3.25.75). The major elements of the conguration can be seen in Example 16-7.
Example 16-7
The Major Elements of the Spoke Router Conguration

1602-frame#show running-config interface Ethernet0 ip address 10.0.2.1 255.255.255.248 ip helper-address 192.168.221.193 ! <output omitted> interface Serial1 no ip address encapsulation frame-relay no ip mroute-cache no fair-queue service-module t1 timeslots 1-2 frame-relay lmi-type ansi ! interface Serial1.201 point-to-point ip unnumbered Ethernet0 bandwidth 128 frame-relay interface-dlci 201 ! ip classless ip route 0.0.0.0 0.0.0.0 192.3.25.75 ip route 181.70.194.1 255.255.255.255 Serial0.201 ip route 10.0.2.0 255.255.255.248 Ethernet0 <output omitted>
The other spoke routers from Figure 16-2 are congured in a similar manner.
466
In each of the hub and spoke congurations, you must understand how the IP addressing scheme is dened. In the hub conguration, the serial subinterfaces obtain their IP address from the Loopback0 interface. In the spoke conguration, Serial1.201 obtains its IP address from the Ethernet0 interface. This IP preservation technique is only applicable to point-topoint congurations. You are not limited to one Loopback interface.
NOTE
You cannot change the subinterface congurations from point-to-point to point-tomultipoint or vice versa without reloading the router. When a subinterface is congured, IOS denes an interface descriptor block (IDB). The IDBs dened for subinterfaces cannot be changed without a reload. Also, using the no interface command shows the subinterfaces as deleted until the router is reloaded, when it disappears from the output. You can also change the encapsulation from Frame Relay to high-level data link control (HDLC) on the interface. This strips out all subinterfaces because HDLC does not support this feature, but you still need to reboot the router.
Maximum Number of DLCIs Per Interface

As you already know from Chapter 14, Frame Relay Technology Background, the default DLCI address space is 10 bits. Theoretically, 210 = 1024 DLCIs can be congured on a single physical link. In reality, certain DLCIs are reserved for management and signaling messages. The available DLCIs for permanent virtual circuits (PVCs) range from 16 to 1007 for Consortium and from 16 to 992 for American National Standards Institute/International Telecommunication Union Telecommunication Standardization Sector (ANSI/ITU-T) specications. However, the LMI protocol requires that the full status report about all PVCs t into a single packet. This generally limits the number of DLCIs to fewer than 800, and depends on the maximum transmission unit (MTU) size. If you have the output of a show frame-relay lmi command from your Cisco device, you might notice that the report type (RT) information element (IE) is one byte long and the keepalive (KA) IE is 2 bytes long. For the ANSI and Q933a LMIs, the PVC IE is 5 bytes long. For the Cisco LMI, it is 8 bytes long because of the additional bandwidth value. Detailed information from the debug frame-relay lmi command is given in Chapter 17. For the purposes of the calculation, consider that the MTU size is equal to the entire LMI packet, which is 1500 bytes. Then, you subtract 13 bytes from the entire LMI packet. 13 bytes = IEs (10 bytes) + RT (1 byte) + KA (2 bytes). Next, divide that number by the length of the PVC IE (5 bytes for ANSI and Q933a, 8 bytes for Cisco) to get the maximum theoretical number of DLCIs for the interface: For ANSI or Q933a, the formula is max DLCIs = (MTU 13) / 5 For Cisco, the formula is max DLCIs = (MTU 13) / 8
467
The calculation for the maximum number of DLCIs per router is available in the Cisco documentation. You can also refer to Appendix C of Cisco Internetwork Design by Matthew H. Birkner (Cisco Press, 2000).
Routing Protocols and Frame Relay Congurations

It is well known that every routing protocol adds overhead, which in some cases, can be considerable, and reduces the overall bandwidth. Distance vector protocols, such as RIP and the Interior Gateway Routing Protocol (IGRP), use periodic updates to exchange routing information. RIP updates are exchanged every 30 seconds. RIP IPX updates are exchanged every 60 seconds, which results in the bandwidth consumption reaching 18.7 percent of the access rate of a T1. Some size estimates of the various distance vector routing protocol updates are shown in Table 16-1.
Table 16-1 Size Estimates for Various Distance Vector Protocols Protocol RIP IGRP Novell RIP Novell SAP AppleTalk Bytes 10 14 12 85 6 6 4 16 12
Virtual Integrated Network Service (VINES) Real-Time Transport Protocol

(RTP) Digital Equipment Corporation net (DECnet) IGRP Xerox Network Systems (XNS)
Link-state protocols impose other requirements on the conguration. Examples of these protocols include EIGRP for IP, IPX, AppleTalk, OSPF for IP, and Integrated Intermediate System-to-Intermediate System (IS-IS) for IP. Because these protocols do not broadcast large updates regularly, and thereby less frequently affect performance of the normal user data, higher packet and byte rates are acceptable. The queues must be dimensioned properly for the periodic exchange of the full routing/topology tables. Hence, it is recommended that the queue sizes be dimensioned as if a periodic protocol were being used. If OSPF is chosen as a routing protocol, the broadcast command in the static mapping transforms the nonbroadcast Frame Relay to broadcast. This results in forwarding broadcasts when multicasting is not enabled for NBMA networks. This approach allows OSPF to run over Frame Relay as a broadcast network. In point-to-point congurations
468
using EIGRP, the passive-interface command prevents all routing updates from being sent to or received from a network through a specic interface, thus reducing the bandwidth consumption for routing overhead. The passive-interface command is not applicable for link-state protocols. This command prevents the router from establishing a neighbor adjacency with other routers that are connected to the same link (see Cisco IOS 12.0 documentation for more detail). On most protocols, the passive-interface command stops the router from sending updates to a particular neighbor, but it continues to listen to and use its routing updates. In general, the following techniques reduce the update load: updateonly routing protocols, routing and SAP lters, longer update timers, longer interval timers, multiple access lines, and higher-speed access lines. (For a detailed description on routing protocols and their requirements and conguration features, refer to Cisco documentation).
Frame Relay Broadcast Queue

Remote access designs are characterized by a large number of spoke routers that terminate into one or a couple of hub routers. The routing updates can create a large amount of trafc and thus seriously affect the overall performance of the entire architecture. One of the possible solutions is the use of a Frame Relay broadcast queue per interface. For Frame Relay, the broadcast queue is separate from the regular interface queue. It has its own buffers, size, rate and is congurable with the command frame-relay broadcast-queue size byte-rate packet-rate. The conguration line is as follows:
frame-relay broadcast-queue size byte-rate packet-rate
The simple conguration procedure for Interface Serial3/0:0 is shown in the following lines:
7206-frame#config terminal 7206-frame(config)#interface Serial3/0:0 7206-frame(config-if)#frame-relay broadcast-queue 100 1200 120
The default settings of this command are as follows:
Queue size64 Bytes per second256,000 bytes per second (2,048,000 bits per second) Packets per second36
The actual settings in the conguration can be viewed with the show interface Serial3/0:0 command. The broadcast queue has a guaranteed minimum bandwidth allocation. To set the queue size, Cisco recommends starting with 20 packets per DLCI and monitoring the number of drops. Cisco also recommends that the byte rate should be less than both of the following (assuming 250-byte packets):
N/4 times the minimum remote access rate (measured in bytes per second), where N is the number of DLCIs to which the broadcast must be replicated. 1/4 the local access rate (measured in bytes per second).
Advanced Frame Relay Congurations
469

The represented conguration solutions in the following sections are usually referred to as advanced Frame Relay congurations. They include the following:
Conguring IP unnumbered Frame switching conguration Conguring ISDN as Frame Relay backup Conguring the bridging in Frame Relay Frame Relay compression conguration Conguring IP multicast in Frame Relay Frame Relay trafc shaping conguration, including foresight adaptive shaping
Conguring IP Unnumbered Frame Relay

One of the IP preservation schemes that is only applicable for point-to-point congurations is to use an unnumbered IP address. In Example 16-4, you can see that for the core router conguration the physical interface is congured with no ip address and the IP addresses are assigned to the subinterfaces. These IPs are all obtained from the Loopback0 interface. Given the number of congured subinterfaces, you can see how this approach maximizes the use of available IP address space. The same logic applies to the remote users router conguration in Example 16-7, where the subinterfaces obtain IPs from the Ethernet0 interface and, thus, the overall solution doubles the number of spared IPs.
Frame Switching
When discussing Frame Relay technology options in Chapter 14, Frame switching and a set of protocols were introduced (refer to Figure 14-2 and Figure 14-3). Typically, a router is congured as data communications equipment (DCE) if it is connecting directly to another router. It can also be congured as DCE when connected to a 90i D4 channel unit, which in turn is connected to a telephone company (telco) channel bank. A variety of conguration solutions exist for frame switching, including the following:
PVC switching conguration where the DCE router switches frames that are based on DLCI Two or more Cisco routers congured as DCE and using Network-to-Network Interface (NNI) signaling between them to provide data terminal equipment (DTE) to DTE switching Hybrid conguration where the router is congured as DCE and DTE, and where it switches frames between two or more DCE ports, or DCE and DTE ports Switching Frame Relay PVCs over a point-to-point IP tunnel
470
The full range of conguration examples are beyond the scope of this section, but here are some guidelines about the rst and second conguration examples. The rst switch conguration requires three conguration commands. They are framerelay switching, frame-relay intf-type dce, and frame-relay route. Consequently, the conguration of frame switching (conguring the Cisco router as a DCE device) includes three steps:
Step 1 Enable frame switching Step 2 Conguration of the DTEs, DCE, or NNI Step 3 Specication of the static mapping of DLCI to the next hop address
Assume that the top router in Figure 16-2 performs DCE functions for all four of the spoke routers. The DCE conguration rules are as follows:
The top router must be congured with the following command:

7206-frame(config)#frame-relay switching
Every interface connected to the DTE must be congured with the following command:
7206-frame(config-if)#frame-relay intf-type dce
This conguration line indicates to DTE that it is connected to DCE. Other conguration options for the same command are as follows: frame-relay intf-type dteCongure as a Frame Relay DTE frame-relay intf-type nniCongure as a Frame Relay NNI
The routing statement must map the in-dlci with the out-dlci in the interface conguration mode:
7206-frame(config-if)# frame-relay route in-dlci interface out-interface out-dlci
NOTE
In Cisco IOS Software release 12.1(2)T and later, the frame-relay route command is replaced with the connect command. This command is dened in global conguration mode, and the format is as follows:
7206-frame(config)#connect connection-name interface dlci interface dlci
The second conguration allows two or more Cisco routers that are congured as DCE to use NNI signaling between them, and to provide DTE to DTE switching. Assume that Figure 16-2 has not one, but two top routers. You need to perform a two-step conguration:
471
Step 1 For each of them, you must ensure that it is congured with NNI
signaling:
7206-frame(config-if)# frame-relay intf-type nni 7206-frame(config-if)# frame-relay lmi-type q933a
Step 2 Determine who provides the clocking. After you obtain the denitive
answer, congure the particular DCE with the following command:

7206-frame(config-if)# clockrate 2048000
In case you want to simulate the future architecture before implementing the new conguration, you might consider using the Adtran simulator as a Frame Relay switch. This device allows you to simulate a telco channel bank and offers a convenient web-based tool for mapping DTEs. Adtrans ATLAS 890 and the 800PLUS/810PLUS with Frame Relay Software installed enable LAN-to-LAN interconnections by using an integral IP router with support for Frame Relay or PPP trafc (www.adtran.com/all/Public/framemacro?section=products.clec).
Frame Relay and ISDN Backup Conguration

Enterprises that require a wide-area network (WAN) service for long periods of the workday normally choose Frame Relay as a primary link. To prevent situations where this link is a single point of failure, and to meet the availability and redundancy requirements of the design, the ISDN is often used as a backup technology. In the remote access enterprise environment, remote users dont usually warrant a backup. It is up to the enterprise to determine if the additional cost of an ISDN backup is worth the added redundancy. Usually, ISDN backup for Frame Relay is deployed in eld sales ofces. The following section provides conguration guidelines for the common ISDN backup, ISDN backup with dialer proles, and ISDN backup that is based on HSRP. Other solutions, such as dialer watch as an alternate backup method, wont be discussed in this section, but can be seen in Chapter 6 and are applicable in Frame Relay.
Common ISDN Backup Conguration for Frame Relay

The backup ISDN interface can be dened in both point-to-multipoint and point-to-point interfaces. Depending on the strategy, ISDN BRI0 can back up both the physical and perDLCI interface. In the physical interface backup scenario, losing the PVC does not trigger the backup mechanism because it only works when there is a complete loss of connectivity (i.e., when both the interface and line protocol are down). Most probably, this is the reason that this method is called physical interface backup.
472
In the per-DLCI scenario, the main interface can stay up, but if the subinterface goes down, the ISDN BRI0 comes up. The physical interface backup (if congured) takes precedence over any other backup conguration. The per-DLCI conguration is the recommended one for practical use. Assume that you need to back up the DLCI 200 (point-to-point interface) that is included in Figure 16-2, and the top router has an ISDN BRI0 interface. The conguration command sequence must include the commands in Example 16-8.
Example 16-8
ISDN Per-DLCI Backup Conguration

7206-frame#configure terminal 7206-frame(config)# interface Serial4/2:0.200 7206-frame(config-if)# frame-relay interface-dlci 200 7206-frame(config-if)# backup interface BRI0 7206-frame(config-if)# backup delay 5 10
The last command represents the IOS interface conguration command backup delay enable-delay disable-delay. This command species enable delay, which is the number of seconds to wait after the primary link has failed before the backup line is brought up; and disable-delay, which is the number of seconds to wait after the primary link is available before the backup line is torn down. In this example, enable-delay is ve seconds and disable-delay is ten seconds. Cisco recommends two rules of thumb in this situation:
Wait at least 20 seconds before starting the backup line just in case it was a glitch and the link bounced. Wait ve seconds after the primary interface comes back up to bring the backup connection down again. This is to ensure that the primary link stays up.
NOTE
Load-based backup, based on load-threshold calculations, is not available in Frame Relay and is applicable only for ISDN. (See Chapter 11, Cisco ISDN Conguration Solutions.)
Frame Relay Backup with ISDN Dialer Proles

This solution is based on creating dialer proles on both the hub and spoke sides. Assume that you have a conguration with one hub and four spoke routers, as shown in Figure 16-2. If all the spoke routers have ISDN backup links available, they can be congured as shown in Example 16-9. As soon as Serial1.201 goes down, the backup ISDN interface comes up according to the conguration settings. Here, the backup delay settings are ve seconds for enable-delay and ten seconds for disable-delay parameters (see the line backup delay 5 10).
473
Example 16-9
Fragment of the Spoke Router Conguration with Per-DLCI Backup Congured Under the Interface Serial1.201
<output omitted> ! interface Serial1.201 point-to-point ip unnumbered Ethernet0 bandwidth 128 frame-relay interface-dlci 201 backup delay 5 10 backup interface BRI0 ! <output omitted>
Now assume that the core router has one backup Basic Rate Interface (BRI) (BRI0) and you want to congure the dialer proles for this router. This conguration has two major steps. The rst step is to congure four dialers (D1-D4) to guarantee one BRI channel per spoke router. This step was discussed in Chapter 11. The second step is to assign BRI interfaces to every pool. Again, refer to Chapter 11 for congurations of dialer pools. The difference here is that to guarantee one BRI channel per every spoke router, you have to restrict the number of channels by using the commands in Example 16-10 under the BRI0 interface.
Example 16-10 Dialer Pool Member Conguration for the Core Router
dialer dialer dialer dialer pool-member pool-member pool-member pool-member 1 2 3 4 max-link max-link max-link max-link 1 1 1 1
If the probability of failure is high, it is better to use a PRI, instead of a group of BRIs, and apply the same conguration rules. In this case, you can consider using multilink ppp. Troubleshooting the solution should follow the methodology described in Chapter 17, Frame Relay Troubleshooting, and Chapter 12. It is not recommended to use the shutdown command on the serial interface to test this solution. Instead, you can emulate a real serial line problem by pulling the cable out from the serial line.
EIGRP- and HSRP-Based Solutions

A more sophisticated backup mechanism is available in Cisco IOS using the EIGRP routing protocol and a combination of oating and static routing. Both one- and two-router based congurations are available. For a full description of the solutions, see the Cisco Press book Advanced IP Network Design (CCIE Professional Development) by Alvaro Retana, Don Slice, and Russ White. An important element of the conguration is to prevent an IP route-cache
474
on the ISDN conguration because the router sends trafc over this interface even after the primary connection is restored. A weakness of this solution is that the conguration still relies on the status of the physical connectivity. It is well known that even when the physical layer is up, this does not necessarily mean that IP connectivity is up. In other words, losing IP connectivity might not trigger the backup mechanism. Another interesting solution is related to HSRP and its functionality. HSRP allows routers to share a virtual IP address between them with only one active HSRP router accepting (and forwarding) trafc destined to that virtual IP. In the latest IOS releases, HSRP provides monitoring and prioritizing capabilities, which result in proper fail-over for devices when a redundant serial link failure occurs on a router. The solution is based on the IOS track and preempt commands that identify the primary router as a higher priority over the backup one. As soon as the primary link fails (interface Serial3/0:0), the standby 1 track Serial3/0:0 command reduces the value of priority, so the backup router now has a higher priority value and becomes the primary router. More about this topic can be found at www.cisco.com/warp/public/619/6.html.
Frame Relay and Bridging

When using Frame Relay bridging, there must be a full mesh of Frame Relay virtual circuits between the bridges of a remote bridge group. If the Frame Relay network is not a full mesh, the bridge network must be divided into multiple remote bridge groups. Because LMI transforms the Frame Relay to a LAN-like architecture, this bridging model is identical to the model for remote bridging as described in IEEE P802.1g, which supports the concept of virtual ports. The Frame Relay virtual circuits that interconnect the bridges of a remote bridge group can be combined or used individually to form one or more virtual bridge ports. This solution provides exibility to treat the Frame Relay interface as either a single virtual bridge port with all virtual circuits in a group, or as a collection of bridge ports (individual or grouped virtual circuits). The simplest bridge conguration for a Frame Relay network is the LAN view, where all virtual circuits are combined into a single virtual port. Frames, such as Bridge Protocol Data Units (BPDUs), which are broadcast on a LAN, must be ooded to each virtual circuit (or multicast, if congured on the Frame Relay network). Flooding is performed by sending the packet to each relevant DLCI that is associated with the Frame Relay interface. Obviously, this approach is typical for point-to-multipoint congurations. A second Frame Relay bridging approach for point-to-point congurations treats each Frame Relay virtual circuit as a separate bridge port. Flooding and forwarding packets are signicantly less complicated by using the point-to-point approach because each bridge port has only one destination. There is no need to perform articial ooding or to associate DLCIs with destination Media Access Control (MAC) addresses. In Example 16-11, a simple bridge conguration (fragment) is provided. The dened subnet of the spoke router is /29 (the subnet mask is 255.255.255.248), and it is a subnet of
475
the core router. Therefore, from the available six addresses for the spoke router, the rst address (in this case, 54.161.107.161) is the default route. The spoke is bridging, but the core is routing the packets.
Example 16-11 Cisco 1602 Router, Congured as a Bridge
1602-frame#show running-config <output omitted> ! bridge irb ! interface Ethernet0 no ip address no cdp enable bridge-group 1 hold-queue 32 in ! interface Serial1 no ip address encapsulation frame-relay no ip mroute-cache no fair-queue service-module t1 timeslots 1-2 frame-relay lmi-type ansi ! interface Serial1.201 point-to-point ip unnumbered BVI1 bandwidth 128 frame-relay interface-dlci 201 bridge-group 1 ! interface BVI1 ip address 54.161.107.162 255.255.255.248 ip nat outside ! ! ip nat inside source list 1 interface BVI1 overload
The rst important line in this conguration is the command bridge irb. It enables the Integrated Routing and Bridging (IRB) feature. This feature allows a given protocol to be routed between routed interfaces and bridge-groups or between bridge-groups within a single router. Specically, local or unroutable trafc is bridged among the bridged interfaces in the same bridge-group, and routable trafc is routed to other routed interfaces or bridge-groups. So again, why use IRB? Here are some reasons:
Interconnect bridged and routed topologies Conserve network addresses but maintain connectivity Increase performance by keeping bridging trafc local
476
The second important part of this conguration is the Bridge Group Virtual Interface (BVI). The concept of BVI was created to enable these interfaces to exchange packets for a given protocol. The BVI is a virtual interface within the router that acts just like a normal routed interface. It does not support bridging but represents the corresponding bridge-group within the router. This virtual interface allows routing between a bridge-group and a routed interface. Because bridging is in the data link layer and routing is in the network layer, they have different protocol conguration models. With IP, for example, bridge-group interfaces belong to the same network and have a collective IP network address, and each routed interface represents a distinct network and has its own IP network address. The interface number of the BVI (#1 in Example 16-11) is the number of the bridge group that this virtual interface represents. The number is the link between this BVI and the bridge group. When you congure the BVI and enable routing on it, packets that come in on a routed interface are destined for a host on a segment that is in a bridge group that goes through the following processes:
Step 1 The packet is routed to the BVIInterface BVI1 in Example 16-11. Step 2 From the BVI, the packet is forwarded to the bridging engine. Step 3 From the bridging engine, the packet exits through a bridged interface.
Similarly, packets that come in on a bridged interface but that are destined for a host on a routed network rst go to the BVI. The BVI then forwards them to the routing engine before sending them out the routed interface. Interfaces Ethernet 0 and Serial1.201 are members of bridge group 1, as dened by the virtual bridge interface (BVI1). As soon as the BVI1 has an IP address assigned to it, Serial1.201 obtains an IP address. Then the router bridges the frames from E0 to BVI1, and vice versa. Network Address Translation (NAT) is also an important part of the conguration, but it was already discussed in this book and does not require any further attention.
NOTE
To check if the bridge is working, add and remove an IP routing statement, such as
1602-frame(config)#ip route 0.0.0.0 0.0.0.0 BVI1
The routing statement should not affect the ability of the router to pass trafc.
Frame Relay Compression

Cisco internetworking devices use the STAC (LZS) and Predictor data compression algorithms.
477
STAC (LZS) is based on the Lempel-Ziv compression algorithm. Cisco IOS Software uses an optimized version of LZS that provides good compression ratios but requires many CPU cycles. LZS searches the input data stream for redundant strings and replaces them with what is called a token. This token is shorter than the original data string. LZS creates dictionaries. This dictionary is built and begins replacing the redundant strings that are found in the new data streams. The Predictor compression algorithm tries to predict the next sequence of characters in the data stream by using an index to look up a sequence in the compression dictionary. It then examines the next sequence in the data stream to see if it matches. If it does match, that sequence replaces the looked-up sequence in the dictionary. If not, the algorithm locates the next character sequence in the index and the process begins again. The Predictor data compression algorithm was optimized by Cisco engineers. When compared with LZS, it makes more efcient use of CPU cycles but requires more memory. The compression alternatives within Frame Relay include two main groups: per-interface compression (also called link compression) and per-virtual circuit compression (also called payload compression). The available Cisco compression solutions for Frame Relay are shown in Figure 16-3. Depending on which part of the packet you want to compress, several available options exist: header compression (TCP and RTP header compression); payload compression (FRF.9, stacker, predictor; and Microsoft Point to Point Compression [MPPC]). MPPC is based on RFC 2118 and is a per-Point-to-Point Protocol (PPP) connection compression algorithm.
NOTE
Shut down the interface or subinterface prior to adding or changing compression techniques. Although not required, shutting down the interface ensures that it is reset for the new data structures.
Van Jacobson Header Compression

Cisco IOS header compression uses the Van Jacobson Algorithm as dened in RFC 1144. Ciscos header compression product supports X.25, Frame Relay, and dial-on-demand WAN link protocols. Because of the processing overhead, header compression is generally used at 64 kbps. For example, a 50 percent throughput improvement can be achieved with telnet, rlogin, and X Windows trafc on a 64-kbps leased line for TCP/IP, which conforms to RFC 1144. Example 16-12 shows an interface congured for TCP/IP header compression and an IP map that inherits the compression characteristics. The Frame Relay IP map is not explicitly congured for header compression.
478
Figure 16-3 Cisco Frame Relay Compression Solutions
Frame Relay Compression
Payload Compression (Per Virtual Circuit Compression)
FRF9 Compression
STAC
CSA Compressor
Data - Stream Compression (Cisco Proprietary)
Predictor
CAIM Compressor
Packet-to-Packet Compression (Cisco Proprietary)
Software
IP TCP Header Compression (Van Jacobson Header Compression)
frame-relay map ip 10.0.2.1 201 broadcast frame-relay ip tcp header-compression [passive | active] frame-relay map ip 10.0.2.1 201 broadcast nocompress frame-relay ip tcp header-compression [passive | active]
compress [active | passive] tcp & rtp header compress
noncompress non-header compression
tcp header-compression [active | passive]
rtp header-compression [active | passive]
payload-compression
Example 16-12 The Interface Serial1 and IP MAP with Inherited TCP/IP Header Compression
1602-frame#show running-config <output omitted> interface Serial1 no ip address encapsulation frame-relay no ip mroute-cache no fair-queue service-module t1 timeslots 1-2 frame-relay lmi-type ansi frame-relay map ip 10.0.2.1 201 broadcast frame-relay ip tcp header-compression passive <output omitted>
479
NOTE
The frame-relay ip tcp header-compression [passive | active] command has two options. The passive option indicates that the TCP header compression is active only for the destinations that are sending compressed headers. The active option requires the other side to be congured for the same type of compression.
If you type 1602-frame#show frame-relay map, you see a line that looks similar to the following:
<output omitted> dlci 201 (0xC9,0x3090), static, broadcast, CISCO TCP/IP Header Compression (inherited), passive (inherited) <output omitted>
This shows that the IP map has inherited passive TCP/IP header compression. This example also applies to dynamic mappings achieved with the use of InARP on point-to-point subinterfaces, where no Frame Relay maps are explicitly congured. Another conguration option is to override the compression set on the interfaces, as shown in Example 16-13.
Example 16-13 Compression, Congured for Interface Serial1 Using an IP Map to Override TCP/IP Header
Compression
1602-frame#show running-config <output omitted> interface Serial1 no ip address encapsulation frame-relay no ip mroute-cache no fair-queue service-module t1 timeslots 1-2 frame-relay lmi-type ansi frame-relay map ip 10.0.2.1 201 broadcast nocompress frame-relay ip tcp header-compression passive <output omitted>
NOTE
If the interface is congured with IETF encapsulation, it cannot be congured for header compression and map compression must be congured. The interface congured for TCP/ IP header compression cannot support priority or custom queuing.
480
Use the show frame-relay map command to display the resulting compression and encapsulation characteristics:
1602-frame#show frame-relay map <output omitted> dlci 201 (0xC9,0x3090), static, broadcast, CISCO <output omitted>
Because IP map did not inherit the TCP header compression, the keyword inherited is not reported in the output.
Per-Virtual Circuit Compression (Payload Compression)

The Frame Relay Forum (FRF) Technical Committee approved an implementation agreement for data compression over Frame Relay called FRF.9. This agreement species a standard for compression to ensure multivendor interoperabilitysee Frame Relay Standards in Chapter 14. FRF.9 is a per-virtual circuit compression mechanism for both switched virtual circuits (SVCs) and permanent virtual circuits (PVCs), which is negotiated at the time that the DLCI is started. Cisco currently supports FRF.9 mode 1 and is evaluating mode 2, which allows more exibility for parameter negotiation. Payload compression has several options. From the core side of the router, the available options are shown in Example 16-14.
Example 16-14 Conguration Interface Serial4/2:0.200 for FRF.9 Payload Compression on the Core Router
7206-frame#show running-config <output omitted> ! interface Serial4/2:0.200 point-to-point description 1602-frame: 10.0.2.1/29 bandwidth 128 ip unnumbered Loopback2 no ip route-cache frame-relay class class-128-new frame-relay interface-dlci 200 IETF frame-relay payload-compression FRF9 stac csa 2 ! <output omitted>
In Example 16-14, subinterface Serial4/2:0.200 uses payload FRF.9 stacker compression, as performed on the compression service adaptor (CSA) hardware module 2(compression service module 2). The syntax of the command is as follows:
frame-relay payload-compression encapsulation-option stac compressor-option
481
The values for encapsulation-option include the following:
FRF9For FRF.9 encapsulation data-streamFor Cisco proprietary encapsulation packet-by-packetFor Cisco proprietary encapsulation
FRF.9 stacker compression can be performed by a Cisco Advanced Integration Module (CAIM), a CSA, or by the main processor:
frame-relay payload-compression FRF9 stac compressor-option
The word stac stands for stacker (LZS) compression. The values for compressor-option include the following:
csaCSA compressor, which is available for 7206 and 3640 platforms softwareForce software compression, which is generally available for all platforms caimCAIM compressor. CAIM performs the following algorithms: STAC (QIC122) compression algorithms MPPC algorithm FRF.9 Frame Relay Payload Compression Compression Control Protocol (CCP) RFC
NOTE
In the core router, as soon as you use payload compression, switch off the fancy switching. The only available option is to use process switching.
From the spoke perspective, a couple of conguration options are available, as shown in Example 16-15. For 1600 router series, there is no hardware compression module available.
Example 16-15 Software Compression Conguration of a 1600 Router
1602-frame#show running-config <output omitted> ! interface Serial1.200 point-to-point bandwidth 128 ip unnumbered Ethernet0 no ip mroute-cache frame-relay interface-dlci 200 IETF frame-relay payload-compression FRF9 stac software <output omitted>
In the output in Example 16-15, you can use either the stacker software compression or the Cisco proprietary packet-to-packet compression. Both options are always available. For the
482
Cisco 2600 series and 3660 series routers, the CAIM is available. For more details about hardware compression modules, see www.cisco.com.
Frame Relay and IP Multicast Conguration

To provide basic multicasting over ISDN and Frame Relay for a remote access environment, you must perform some basic tasks:
Enable IP multicast routing Enable Protocol Independent Multicast (PIM) on an interface Congure the router to automatically accept the rendezvous point (Auto-RP) or hardcode the RPs IP address.
In a Frame Relay environment, the following steps provide basic multicast for users. On the spoke router, the lines in Example 16-16 must be congured.
Example 16-16 Basic Conguration Steps for IP Multicast on the Spoke Router
1602-frame#configure terminal 1602-frame(config)# ip multicast-routing 1602-frame(config)# ip pim accept-rp auto-rp 1602-frame(config)# interface Serial1.201 1602-frame(config-subif)# ip pim sparse-dense-mode 1602-frame(config-subif)#exit 1602-frame(config)# interface Ethernet 0 1602-frame(config-subif)# ip pim sparse-dense-mode 1602-frame(config-subif)# ^Z 1602-frame# copy running-config startup-config
In general, PIM protocol (protocol 103) can be congured for two different modes, which are referred to as dense mode (DM) and sparse mode (SM). PIM DM uses a process of reverse path ooding that is similar to the Distance Vector Multicast Routing Protocol (DVMRP). Unlike DVMRP, it does not require a particular unicast protocol to determine which interface leads back to the source of a data stream. However, it uses whatever unicast protocol is being used in the network. PIM SM denes a rendezvous point (RP), which serves as a registration point to facilitate the proper routing of packets. When a sender wants to send data, the next/rst hop sends data to the RP. When a receiver wants to receive data, the last hop router registers with the RP. A data stream ows from the sender to the RP, then to the receiver. Afterwards, routers in the path optimize the path automatically to remove any unnecessary hops, including the RP. The conguration on the hub side router is even simpler because usually the objective is to congure one more user for IP multicast. If this is the case, ip multicast-routing and ip pim accept-rp auto-rp already exist in the conguration, as in Example 16-16. Also, at least one of the Ethernet or FastEthernet
483
interfaces is congured with the ip pim sparse-dense-mode command. The only interface that needs to be congured now is the serial subinterface. If the core router requires an entire new conguration for IP multicast, follow the guidelines in Example 16-17. Remember that only the interfaces congured for multicast can participate in the multicast shared tree.
Example 16-17 Sample IP Multicast Conguration of the Core Router
7206-frame(config)# ip multicast-routing 7206-frame(config)# ip pim accept-rp auto-rp 7206-frame(config)# interface Serial4/2:0.200 7206-frame(config-subif)# ip pim sparse-dense-mode 7206-frame(config-subif)#exit 7206-frame(config)# interface FastEthernet 0 7206-frame(config-subif)# ip pim sparse-dense-mode 7206-frame(config-subif)# ^Z 7206-frame# copy running-config startup-config
In both congurations (Example 16-16 and Example 16-17), ip multicast-routing is congured in the global conguration mode. This step is mandatory because Cisco routers dont forward broadcast or multicast trafc by default. The next line allows PIM to accept the auto-rp. In general, two options can map RP:
Static RPRP to be congured on all routers; operates in SM. Auto-RPRequires congured candidate RPs and mapping agents.
The next important part is ip pim sparse-dense-mode, which denes a dual mode conguration. This mode of Cisco IOS is in fact an interface conguration that allows both DM and SM groups to ow across that interface. It is normally only applied when Auto-RP sends RP information. The conguration in Example 16-17 can include either DM or SM. If you need to choose, Cisco recommends PIM SM, rather than DM. For Frame Relay, remember that 56 kbps is not the best service for multicast. Even 128 kbps with compression can affect the end users router performance signicantly, and if the wrong conguration settings are used, it can shut the service down completely.
Frame Relay and Trafc Shaping

Trafc shaping enables the router to control the output rate and react to the congestion notication mechanisms according to the trafc shaping settings. In Cisco routers, trafc shaping uses a rate control mechanism called a token bucket lter. The token controls the following expression: (Bc + Be) = Access rate for the virtual circuit
484
Trafc above the maximum speed is buffered in a trafc shaping queue, which is equal to the size of weighted fair queuing (WFQ). The token bucket lter does not lter trafc. Rather, it controls the rate at which trafc is sent on the outbound interface. The parameters dened in trafc shaping are as follows (see Chapter 14 for more information):
Committed information rate (CIR) Excess information rate (EIR) Token bucket (TB), (Bc + Be) Committed burst size (Bc, equals sustained burst size) Excess burst size (Be) Discard eligible (DE) Committed interval (Tc) Access rate (AR)
Bc, Be, Tc, and CIR are dened per DLCI. Consequently, the token bucket lter controls the rate per DLCI. The access rate is valid per User-Network Interface (UNI). For Bc, Be, and CIR, incoming and outgoing values can be congured. If the connection is symmetrical, the values in both directions are the same. For PVCs, parameters such as incoming and outgoing Bc, Be, and CIR are dened at the time of provisioning.
NOTE
Peak equals the DLCIs maximum speed and represents the bandwidth for that particular DLCI: Tc = Bc / CIR Peak = CIR + Be / Tc = CIR (1 + Be / Bc) If the Tc is one second: Peak = CIR + Be = Bc + Be and EIR = Be.
Generic Trafc Shaping

The generic trafc shaping feature is a media and encapsulation-independent trafc shaping tool. It helps reduce the ow of outbound trafc when there is congestion within the cloud, on the link, or at the receiving endpoint router. You can set it on interfaces or subinterfaces within a router. See Example 16-18 for the following conguration steps. First, you need to enable trafc shaping in the main interface (interface Serial4/2:0) with the following command:
frame-relay traffic-shaping
485
Then, under the subinterface, you congure the trafc-shape rate. This command congures trafc shaping for outbound trafc on an interface. The full syntax of this command is as follows:
traffic-shape rate bit-rate [burst-size [excess-burst-size]] [group access-list]
Finally, if the conguration solution requires you to throttle backward explicit congestion notications (BECNs) on a Frame Relay interface, the following command is required in the interface conguration mode:
traffic-shape adaptive [bit-rate]
Example 16-18 shows the basic trafc shaping conguration on the hub router, in a pointto-point conguration with DLCI = 100.
Example 16-18 Conguring General Trafc Shaping on a Core Router
7206-frame# show running-config <output omitted> interface Serial4/2:0 description Remote Frame Relay : NUA :3812777777: HICAP CID XXX72HCR-001 no ip address encapsulation frame-relay no ip route-cache no fair-queue frame-relay traffic-shaping frame-relay lmi-type ansi frame-relay broadcast-queue 100 1200 120 ! interface Serial4/2:0.100 point-to-point description 2500-frame: 10.0.1.0/29 ip unnumbered Loopback0 no ip route-cache frame-relay interface-dlci 100 ! Upper limit rate: traffic-shape rate 128000 ! Lower limit rate (CIR value): traffic-shape adaptive 64000 <output omitted>
NOTE
Trafc shaping must be enabled on the interface with the trafc-shape rate command before you can use the trafc-shape adaptive command.
In Example 16-18, the expected rate is between 64 kbps and 128 kbps. The trafc-shape adaptive command should be congured at both ends of the link because it also congures the device at the slow end to reect forward explicit congestion notication (FECN) signals as BECNs. This enables the router at the high-speed end to detect and adapt to congestion, even when trafc is owing primarily in one direction. With generic trafc shaping, you can
486
only specify one peak rate (upper limit) per physical interface and one CIR (lower limit) value per subinterface. With Frame Relay trafc shaping, you start a token bucket lter per virtual circuit.
Trafc Shape Map Classes

The most common technique for trafc shaping is to dene the trafc shape map class and apply it to different subinterfaces. This approach is much shorter and easier to manage than dening it under every single interface. In general, Frame Relay trafc shaping has three objectives:
Rate enforcement on a per-VC basisYou can congure a peak rate and EIR. BECN support on a per-VC basisThe router can monitor BECNs and throttle trafc based on BECN-marked packet feedback from the network. Priority queuing (PQ), custom queuing (CQ), or WFQ support at the VC level.
The trafc shaping over Frame Relay feature applies to both PVCs and SVCs. The conguration rules are simple, but rst you need to dene the map class. An example of a map class, called class-64, is shown in Example 16-19.
Example 16-19 Conguration Steps for a Map Class Conguration, Called Class-64
7206-frame#config terminal ! Specifies Frame Relay map class named class-64 and ! enters map class configuration mode: 7206-frame(config)#map-class frame-relay class-64 !The next lines can include the following 7206-frame(config-map-class)#frame-relay cir 64000 7206-frame(config-map-class)#frame-relay bc 64000 7206-frame(config-map-class)#frame-relay be 10000 7206-frame(config-map-class)#frame-relay mincir 56000 7206-frame(config-map-class)#end 7206-frame#copy running-config startup-config
In this example, the CIR is set to 64,000 bps, the BC is set to 64,000 bits, the BE is set to 10,000 bits and the minimum committed information rate (MINCIR) to 56,000 bps. This example includes some of the commonly used options. After you enter the map class conguration mode, the syntax of the frame-relay command is as follows:
frame-relay options
The possible values for options include the following:
adaptive-shapingAdaptive trafc rate adjustment; default = none bcBc, default = 56,000 bits beBe, default = 0 bits
487
cirCIR, default = 56,000 bps congestionCongestion management parameters custom-queue-listVirtual circuit custom queuing end-to-endCongure Frame Relay end-to-end virtual circuit parameters fair-queueVirtual circuit fair queuing fecn-adaptEnable trafc-shaping reection of FECN as BECN fragmentRequires Frame Relay trafc shaping to be congured at the interface level holdqHold queue size for virtual circuit interface-queuePVC interface queue parameters ipAssign a priority queue for RTP streams mincirMinimum acceptable CIR; Default = CIR / 2 bps priority-groupVC priority queuing tcPolicing Measurement Interval (Tc) trafc-rateVirtual circuit trafc rate voiceVoice options
Next, you apply the map class to the subinterface as shown in Example 16-20. Of course, frame-relay trafc-shaping must be enabled on the main interface.
Example 16-20 Applying the Frame Relay Class to Subinterface Serial4/2:0.100
7206-frame#show running-config interface serial4/2:0.100 interface Serial4/2:0.100 point-to-point description AndrewC frame: 10.0.1.0/29 : 2322713474 : bandwidth 128 ip unnumbered Loopback1 no ip route-cache ! Here the Frame Relay map class from Example 16-19 is applied. frame-relay class class-64 frame-relay interface-dlci 100
Frame Relay Foresight Adaptive Shaping with ELMI

ELMI allows the router to adapt the shaping parameters dynamically. ELMI enables the automated exchange of Frame Relay quality of service (QoS) parameter information between the Cisco router and the Cisco switch. Routers can then base congestion management and prioritization decisions on known QoS values such as CIR, Bc, and Be. This enhancement operates between Cisco routers and Cisco switches (BPX/MGX and IGX platforms). You can enable ELMI support on the router by using the frame-relay qosautosense command.
488
The conguration rules for this feature are simple. First, you congure the frame-relay trafc-shaping and frame-relay qos-autosense commands on the main interface, as shown in Example 16-21.
Example 16-21 Serial4/2:0 Is Congured for Adaptive Shaping
7206-frame# show running-config <output omitted> interface Serial4/2:0 description Home Frame Relay : NUA :3812800174: HICAP CID XXX72HCR-001 no ip address encapsulation frame-relay no ip route-cache no fair-queue frame-relay traffic-shaping frame-relay lmi-type ansi frame-relay broadcast-queue 100 1200 120 frame-relay qos-autosense <output omitted>
Then, use the following command to add the existing map class, or create a map class:
7206-frame(config-map-class)#frame-relay adaptive-shaping foresight
The ELMI feature reduces the manual conguration efforts and ensures consistency of trafc shaping based on the QoS parameters.
Summary
Conguration options in Frame Relay are based on the design and provisioning choices made in the design phase. In this chapter, you learned about basic (common) and advanced conguration options with Cisco Frame Relay routers, including the following:
Basic Frame Relay congurations, such as point-to-multipoint congurations, pointto-point congurations, and the frame relay broadcast queue. This section also includes minimum DLCIs recommendations, and the effect over Frame Relay service of the chosen routing protocols. The advance conguration sections include conguring IP unnumbered Frame Relay, frame switching congurations, ISDN as Frame Relay backup congurations, Frame Relay bridging, and Frame Relay compression and multicast congurations. Frame Relay trafc shaping, because of its importance, is represented in detail, including generic trafc shaping, trafc shaping classes, and foresight adaptive shaping with ELMI.
The Frame Relay encapsulations (cisco, ietf), DLCI encapsulations (cisco, ietf, ppp, and protocol) and LMI types (cisco, ANSI, and q933a) are discussed from a troubleshooting point of view in the following chapter.
Review Questions
489
Review Questions
1 What is dynamic mapping? 2 For Router-frame, map the IP address 10.0.0.1 to DLCI = 100, using the IETF
encapsulation.
3 Can you use IP unnumbered with Frame Relay? 4 Can you ping your own interface address? Can you ping one spoke router from
another?
5 What happens to deleted subinterfaces? 6 In point-to-point congurations that are running EIGRP, type the command for
Router-frame that prevents all routing updates for interface Serial3/0:0.64?

7 Congure the Frame Relay broadcast queue for Router-framesubinterface
S3/0:0.71 with queue size 100, byte rate 1200, and packet rate 120.
8 Can you congure the Cisco router as a DCE? 9 Under the interface Serial3/0:0.200, what is the backup delay command with enable
delay = 5 seconds and disable delay = 10 seconds?

10 For Router-frame and interface Serial1, what is the command for TCP header
compression, which is active only for the destinations that are sending compressed headers?
11 For Router-frame and interface Serial4/2:0.200, dene that FRF9 payload
compression will be performed on CSA 3.

12 Enable the multicast routing in Router-frame. 13 In Router-frame, for interface Serial4/2:0.100, dene the upper limit of the rate for
trafc shaping to 128000.

14 What Frame Relay timer denes the Cisco autosense feature? How do you congure
it?
CHAPTER
17
Frame Relay Troubleshooting

Troubleshooting Frame Relay connections is a design-dependant process, which starts with a clear understanding of the kind of connection you are troubleshooting. You need to know if this is a point-to-point or point-to-multipoint design, if it is a routing or bridging design, if you have a partial-mesh or full-mesh design, if you are using a switched virtual circuit (SVC) or permanent virtual circuit (PVC), how the signaling is maintained, and so on. The troubleshooting has to be performed as a congurationcontext activity as well. You need to start with the conguration solutions, such as access rate (whether it is 56 kbps or fraction T1), expected bandwidth, committed information rate (CIR) and excess information rate (EIR), and many of the other parameters explained in Chapters 14, Frame Relay Technology Background, 15, Frame Relay Design Solutions, and 16, Basic and Advanced Frame Relay Congurations. You must also make sure that the equipment is properly congured for multicast, compression, and Voice over Frame Relay. This chapter uses the systematic layer-by-layer approach to troubleshooting that is covered in Chapter 4, Troubleshooting Approaches, Models, and Tools, and contains physical and data link layer troubleshooting techniques, as follows:
Physical layer troubleshooting: Line and clocking problems Physical layer-related performance issues Data link layer troubleshooting: PVC conguration issues, PVC encapsulation, and bandwidth denition issues Local Management Interface (LMI) issues, including LMI types, messages and keepalives, timers, counters, and code types
Performance problems: Flapping links and end-to-end problems Troubleshooting Frame Relay shaping problems and congestion control Troubleshooting compression over Frame Relay
492
Chapter 17: Frame Relay Troubleshooting
Beginning the Frame Relay Troubleshooting Process

The minimum information required before starting to troubleshoot includes the characteristics of the service such as: point-to-point or point-to-multipoint design; if routing or bridging is used; what are the remote and local DLCIs; and what is the access rate (link rate), CIR value, and IP addressing scheme. Regardless of the answer to these questions, some common indicators of the status allow you to start with the snapshot commands. The recommended commands are as follows:
1602-frame#show ip interface brief 1602-frame#show interface serial 1
The latter command depends on the conguration of the 160x router. This command can show the status of Serial 0 (for 56-kbps connections) and Serial 1 (if the router is equipped with a wide-area network interface card [WIC]).
NOTE
The truncated form of show ip interfaces brief is sh ip int brie.
Using the rst command for a 56-kbps access rate service, the output in Example 17-1 is displayed.
Example 17-1
Output from the show ip interface brief Command for the 1602 Router, with a Built-In Data Service Unit/Channel Service Unit (DSU/CSU) for a 56-kbps Rate
1604-frame#show ip interface brief Interface IP-Address Ethernet0 151.68.89.89 Loopback0 unassigned ! This is your 56 Kbps connection Serial0 unassigned Serial0.71 171.68.89.89 OK? Method Status YES NVRAM up YES NVRAM up YES NVRAM YES unset up up Protocol up up up up
Example 17-2 shows the output from the show ip interface brief command when applied to 128 Kbps service.
Example 17-2
Output from the show ip interface brief Command for the 1602 Router, Equipped with a WIC Card
1604-frame#show ip interface brief Interface IP-Address Ethernet0 121.70.194.209 Loopback0 unassigned Serial0 unassigned ! This is your 128 Kbps connection Serial1 unassigned Serial1.37 121.70.194.209 OK? YES YES YES Method NVRAM NVRAM NVRAM Status up up administratively down up up Protocol up up down up up
YES NVRAM YES unset
Physical Layer Troubleshooting
493
The commands #show ip interface brief and #show interface serial 1(0) enable you to narrow the scope of the existing problem. The recommended troubleshooting process starts from the rst layer (see Figure 14-1 in Chapter 14 and Figure 17-1).
Figure 17-1 Frame Relay Troubleshooting Tools
End-to-End Commands: show frame-relay pvc debug frame-relay pvc show frame-relay map
Remote User
Local Loop to Spoke
Remote Loop to Hub
Remote Loop to Spoke
Local Loop to Hub
Laptop Computer
Spoke Router
Mapping
Hub Router
Corporate
Frame Relay Network

show running-config show service-module debug service-module show ip interface brief
CO
CO
Desktop Computer UNI Interface Commands: clear interface serial x clear counters show interface serial x show frame-relay imi debug serial interface debug frame-relay imi debug frame-relay packet
show running-config show controllers T1 show diag slot-value show service-module debug service-module show ip interface brief
UNI Interface Commands: clear interface serial x clear counters show interface serial x show frame-relay imi debug serial interface debug frame-relay imi debug frame-relay packet

Troubleshooting the physical layer starts with checking for cabling issues. The vast majority of these issues can be overcome if you follow the directions in the documentation of your equipment. Usually, cabling problems are evident at the initial implementation of the service and include issues such as the wrong crossover cable or faulty cables. Later in the chapter, some cable pinpoint examples are discussed. Physical problems are probably the number-one suspect on a circuit that has already been installed and turned up and after time has developed an outage. In most cases, if no one has changed the congurations, it is usually a punchdown, bridge clip, line card, or cable break issue.
Line and Clocking Problems

Clocking problems in serial connections can lead to either chronic loss of the connection or to degraded performance. The most common indicators for physical layer problems are shown in Example 17-3.
494
Example 17-3
If This Service Is Provisioned for 56-kbps, Check the Status of Serial 0

1604-frame#show ip interface brief <output omitted> Serial0 unassigned YES NVRAM down down <output omitted>
Under 1602-frame#show interface serial 0, the last line reports the status of the physical layer:
<output omitted> DCD=down DSR=down <output omitted> DTR=down RTS=down CTS=down
These signals are usually referred to as the modem and originally come from RS-232, with the following description:
DCD (Data Carrier Detect)Provided by DCE DSR (Data Set Ready)Provided by DCE DTR (Data Terminal Ready)Provided by DTE RTS (Request To Send)Provided by DTE CTS (Clear To Send)Provided by DCE
Although numerous combinations of up and down signals exist, at this stage it is easy to determine what part of the device is failing. DTE is responsible for DTR and RTS, and DCE is responsible for the rest of the signals. When the clockrate command is missing from the DCE side, DCD, DSR, and CTS are shown as inactive or down. If the line is functional but is reporting an excessive number of errors, you should be concerned about the quality of the physical layer. Use the command in Example 17-4 to check the physical layer.
Example 17-4
This Part of the Output Is Your Main Focus

1604-frame#show interfaces serial 0 <output omitted> 237979 packets input, 21491750 bytes, 0 no buffer Received 0 broadcasts, 0 runts, 5 giants, 0 throttles ! The following line is the part of the output you should review carefully: 198487 input errors, 44907 CRC, 20259 frame, 0 overrun, 0 ignored, 133321 abort 29689 packets output, 3054656 bytes, 0 underruns 0 output errors, 0 collisions, 329 interface res <output omitted>
You should also be concerned about a high number of aborts; as you can see in this case, 133321 aborts represent the vast majority of all input errors (about 70 percent). Start with the conguration on both ends. Check the remote users end rst, for interface availability, as shown in Example 17-5. The output in Example 17-5 can be seen from the show version or show hardware commands, which shows that this router has one on-board 56-kbps serial interface.
495
Example 17-5
Output from the show hardware Command

1602-frame#show hardware <output omitted> 1 Serial network interface(s) On-board Switched 56K Line Interface. <output omitted>
The clocking issue is addressed in the remote users router conguration. In the case of a 56-kbps access rate, two conguration commands dene the clocking and signaling, as shown in Example 17-6.
Example 17-6
A Fragment from the 1602 Conguration, Dening the 56-kbps Access Rate
1602-frame#show running-config <output omitted> ! interface Serial0 no ip address encapsulation frame-relay IETF no fair-queue service-module 56k clock source line service-module 56k network-type dds frame-relay lmi-type ansi ! <output omitted>
The service module built into Cisco routers, including the 16xx, 252x, 26xx, 3600, 4xxx, and 7xxx series, supports two modes of 56-kbps settings for network-type: 56-kbps DSU/ CSU and 56-kbps switched modes. The second of the following two commands identies which side provides the clocking:
1602-frame(config-if)#service-module 56k network-type [dds | switched] 1602-frame(config-if)#service-module 56k clock source [line | internal]
NOTE
Dataphone Digital Service (DDS) provides digital transmission service between the CPE and the providers switch at data rates between 2.4 kbps and 56 kbps. The service is available over two twisted pair lines.1
The service module report is shown in Example 17-7. The lines are self-explanatory.
Example 17-7
Verifying the Functionality of the Built-In Service Module

1602-frame#show service-module serial 0 Module type is 4-wire Switched 56K in DDS mode, Receiver has no alarms.
continues
496
Example 17-7
Verifying the Functionality of the Built-In Service Module (Continued)

Current line rate is 56 Kbits/sec and role is DSU side, Last clearing of alarm counters 3d03h oos/oof : 0, loss of signal : 2, last occurred 2d02h loss of sealing current: 0, CSU/DSU loopback : 0, loopback from remote : 0, DTE loopback : 0, line loopback : 0, 1602-frame#
In the case of a fractional T1 (or full T1) conguration, the expected output from the conguration should be as displayed in Example 17-8. The output in Example 17-8 can be seen from the show hardware or show version commands and shows that this router has one on-board 56 Kbps interface and one WIC T1-DSU card plugged-in.
Example 17-8
Output from the show version Command

1602-frame#show version <output omitted> 2 Serial network interface(s) On-board Switched 56K Line Interface. WIC T1-DSU <output omitted>
The conguration settings in the remote users router are shown in Example 17-9.
Example 17-9
This Fragment of the Conguration Denes a 128-kbps Access Rate (2 Slots 64 kbps Each)
1602-frame#show running-config interface Serial1 <output omitted> encapsulation frame-relay service-module t1 timeslots 1-2 <output omitted>
NOTE
These settings are important and the remote user needs to be aware of which circuit is ordered and provisioned. A 56-k circuit can be a true 56-k circuit (4 wire or 2 wire), but it can sometimes be a T1 circuit (4 wire, T1 port speed) with 56-k PVC. The WIC-1DSU-T1 cannot be used for 56-k leased line/DDS service, and of course the 56-k WIC cannot be used for T1 service.
This conguration denes two slots at 64 kbps each, which results in a 128-kbps access rate. In case the line is provisioned for 128 kbps, 384 kbps, or any other fraction of a T1,
497
the built-in service module (serving a 56-kbps port) slows down because the router does not use this clocking (see Example 17-10).
Example 17-10 The Receiver Has Loss of Signal (LOS) because Serial 0 Is Administratively Down. Meanwhile, the
WIC Card Is Functioning Properly

1602-frame#show service-module Module type is 4-wire Switched 56K in DDS mode, ! You can expect the receiver to lose the signal, because the ! WIC card and DCE will provide the clocking, but not the DDS. Receiver has loss of signal, Current line rate is 56 Kbits/sec and role is DSU side, Last clearing of alarm counters 6w1d oos/oof : 0, loss of signal : 1, current duration 6w1d loss of sealing current: 0, CSU/DSU loopback : 0, loopback from remote : 0, DTE loopback : 0, line loopback : 0, Module type is T1/fractional Hardware revision is 0.88, Software revision is 0.2, Image checksum is 0xED22BEC5, Protocol revision is 0.1 ! This line usually indicates that the WIC card is functioning properly. Receiver has no alarms. Framing is ESF, Line Code is B8ZS, Current clock source is line, Fraction has 2 timeslots (64 Kbits/sec each), Net bandwidth is 128 Kbits/sec. Last module self-test (done at startup): Passed Last clearing of alarm counters 6w1d loss of signal : 0, loss of frame : 0, AIS alarm : 0, Remote alarm : 0, Module access errors : 0, Total Data (last 96 15 minute intervals): 0 Line Code Violations, 0 Path Code Violations 0 Slip Secs, 0 Fr Loss Secs, 0 Line Err Secs, 13 Degraded Mins 0 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 0 Unavail Secs Data in current interval (781 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 1602-frame#
NOTE
For troubleshooting FT1 and T1s, see Chapter 6, Dial Design and Conguration Solutions, or RFC 1232.
The clocking and line issues are irrelevant to the situation, when the serial interface reports the output in Example 17-11.
498
Example 17-11 A Typical Output When the Interface Is Administratively Shut Down
1602-frame#show interfaces serial 0 <output omitted> Serial0 is Administratively Down, Line Protocol is Down Hardware is QUICC Serial (with onboard CSU/DSU) <output omitted>
The rst command is used for an interface, whereas the second command is used for subinterface. In this case, you need to un-shut the interface with either of the following two commands:
1602-frame(config-if)#no shutdown 1602-frame(config-subif)#no shutdown
Serial Interface 0 and Line Protocol Is Down

When the interface serial 0 is not administratively down, the clocking problems have to be your primary focus, especially when the router reports the output in Example 17-12.
Example 17-12 The Line Problems Are Evident from This Output
1602-frame#show interfaces serial 0 Serial0 is Down, Line Protocol is Down Hardware is QUICC Serial (with onboard CSU/DSU) <output omitted>
In general, this problem occurs because clocking is not available. The following cases describe situations when the serial interface is not administratively down, but the router is still reporting both layers down. This case is typical for new service installations. The root cause of these problems is due to either or both of the following two cases:
Case OneClocking problems can be because of incorrect cabling, faulty connectors, faulty devices in the D-Mark, and faulty passive or active repeaters. A common problem with the physical wiring is a reversed pair, which shows a line down/protocol down condition. Problems also occur if the CSU/DSU cable is longer than 50 feet [15.24 meters] or is unshielded. Case TwoAnother category of problems result from a faulty DSU/CSU, faulty line cards, an incorrect DSU/CSU conguration, or D-Mark equipment (commonly referred to as smart-jack and is usually on the MPOE, but in case of extended D-marks, can be in another location).
One of the most widespread issues is incorrect cabling. In Table 17-1, the correct cabling is specied for the two most common cases: 56-kbps and fractional T1 WIC cards.
NOTE
Remember that matching pinouts does not mean that the signaling is correct.
499
Table 17-1
56-kbps DSU/CSU and WIC T1 Pinpoints 56-kbps CSU/DSU Pinouts (8-Pin RJ-48S) Pin Number 1 2 7 8 WIC T1 Pinouts (8-Pin RJ-48S) Pin Number 1 2 4 5 Description Transmit Transmit Receive Receive Description Transmit Transmit Receive Receive
NOTE
Its always recommended that you refer to the available technical documentation of the customer premises equipment (CPE).
The CSU/DSU derives the data clock from the data that passes through it. Therefore, to recover the clock, the CSU/DSU hardware must receive at least one 1-bit value for every 8 bits of data that pass through it; this is known as ones density. Maintaining ones density allows the hardware to recover the data clock reliably. Serial communications use a mechanism called serial clock transmit external (SCTE) terminal timing. SCTE is the clock that is echoed back from the data terminal equipment (DTE) device (for example, a router), to the data communications equipment (DCE) device. When the DCE device uses SCTE instead of its internal clock to sample data from the DTE, it is better able to sample the data without error, even if there is a phase shift in the cable between the CSU/DSU and the router. SCTE is an important element in serial transmissions and it uses access rates that are fractions of a T1. To isolate clocking problems, besides the ones listed earlier, Cisco routers provide a set of tools to troubleshoot the CSU/DSU by using the show, debug, and loopback commands:
1602-frame#debug service-module 1602-frame# show service-module 1602-frame(config-if)# loopback dte 1602-frame(config-if)# loopback line 1602-frame(config-if)# loopback remote
500
Refer to Figure 17-1 for the show service-module command. Note that, in addition to the listed commands, under the T1 controller of the core router, you can use the following useful command: 7206-frame(cong-controller)#loopback diag. The rst command reports the functionality of the module, as shown in Example 17-13.
Example 17-13 Debugging the Service Module
1602-frame#debug service-module Service module debugging is on 1602-frame# 6w5d: SERVICE_MODULE(0): lxt441 6w5d: SERVICE_MODULE(0): lxt441 6w5d: SERVICE_MODULE(0): lxt441 6w5d: SERVICE_MODULE(0): lxt441
interrupt interrupt interrupt interrupt
1 1 1 1
status status status status
A7 87 A7 87
loop loop loop loop
0 0 0 0
The output reports that the service module is working properly.
Case One Problem Resolution

It is necessary to perform a series of loopback tests, both local and remote, to determine whether the DSU or CSU is causing the problem. Using the following commands, you can loopback the DTE, line, or the remote site:
1602-frame(config-if)# loopback dte 1602-frame(config-if)# loopback line 1602-frame(config-if)# loopback remote
It is always good to keep a record of all the different tests performed. In general, when looping and running these tests, always check the number of errors. Different ping tests (samples and sizes) are also recommended during this testing. You must determine whether there is a trend in the accumulation of errors and on what side of the User-Network Interface (UNI) they occur. If errors are accumulating on both ends of the connection (hub site and spoke site), it is most likely because of a DSU problem. If only the DSU end is accumulating errors, there is a problem with that particular end. An excessive number of aborts is a symptom of end-to-end line problems and it is recommended that you work with the local exchange carrier (LEC), who provides the local loop, to isolate the issue. Some Cisco line cards (T1/FT1 WIC) have a loopback button that, when engaged, allows the LEC to loop the spoke side for intrusive testing and clocking.
Case Two Problem Resolution

The problems for this case are related to faulty DSU/CSU, faulty line cards, and incorrect DSU/CSU congurations. An incorrect CSU conguration is usually related to the clocking source. The following questions should be considered:
501
What is the source of clocking (line or internal)? Do the impedance parameters match the manufacturers documentation?
An incorrect DSU conguration is related to several important checkpoints. The following questions should be considered: Is SCTE enabled, especially for fractional T1s? Is the ones density maintained properly and do the framing and coding schemes match on both sides (Extended Superframe [ESF], bipolar 8-zero substitution [B8ZS], alternate mark inversion [AMI])? Although it is not common, is AMI coding congured? If it is, you might need to invert the transmit clock to match the LECs requirements. For this purpose, Cisco provides an additional command that is set for 4000 series and 7000 series routers, and jumpers in the older versions of the equipment.
NOTE
Always see the Cisco IOS conguration guides and command references for the version of IOS that you are running on your router. You can also refer to available user guides for your CPE.
Performance Issues Related to the Physical Layer

You can experience line problems even if the router reports that the line is not down, as shown in the output in Example 17-14.
Example 17-14 The Line Shows Up and the Protocol Is Up, But the Performance Issues Exist
1602-frame#show interfaces serial 1 <output omitted> Serial1 is up, line protocol is up <output omitted>
However, the connection experiences slow performance, intermittent connectivity, and high latency. Some of the most common reasons for poor performance follow:
Noisy (dirty) serial lines Cables longer than 50 feet [15.24 meters] or cables are unshielded Noisy or poor patch panel connections External EMI sources, such as unshielded cables running too close to EMI sources
A useful tool in this situation is #show interface serial 0, which allows you to not only check the status of the line at any moment (snapshot), but to monitor the dynamics of the changes. This command reports the output in Example 17-15 (see Table 17-2 for an explanation).
502
Example 17-15 Snapshot of the Serial 0

1602-frame#show interfaces serial 0 Serial0 is up, line protocol is up Hardware is QUICC Serial (with onboard CSU/DSU) MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec, reliability 255/255, txload 1/255, rxload 1/255 Encapsulation FRAME-RELAY, loopback not set Keepalive set (10 sec) LMI enq sent 53714, LMI stat recvd 53710, LMI upd recvd 0, DTE LMI up LMI enq recvd 0, LMI stat sent 0, LMI upd sent 0 LMI DLCI 0 LMI type is ANSI Annex D frame relay DTE FR SVC disabled, LAPF state down Broadcast queue 0/64, broadcasts sent/dropped 8958/0, interface broadcasts 3 Last input 00:00:00, output 00:00:00, output hang never Last clearing of show interface counters 1w0d Queuing strategy: fifo Output queue 0/40, 0 drops; input queue 1/75, 0 drops 5 minute input rate 0 bits/sec, 2 packets/sec 5 minute output rate 0 bits/sec, 0 packets/sec 230129 packets input, 44936503 bytes, 0 no buffer Received 0 broadcasts, 0 runts, 1 giants, 0 throttles 7241 input errors, 3594 CRC, 2701 frame, 0 overrun, 0 ignored, 944 abort 229128 packets output, 49424950 bytes, 0 underruns 0 output errors, 0 collisions, 2509 interface resets 0 output buffer failures, 0 output buffers swapped out 6 carrier transitions DCD=up DSR=up DTR=up RTS=up CTS=up
Table 17-2
The Output From #show interface serial 0 and Its Description Output Serial0 is [up | down] administratively down Description Indicates whether the clocking is presently available or not (matches Data Carrier Detect [DCD] signal in the last line of the output); and whether the line was taken down by the administrator. Indicates a successful exchange of the congured LMI and keepalives (if they are congured). Hardware information, showing the router has a built-in CSU/DSU-interface. Maximum Transmit Unit (MTU) is 1500 bytes. Bandwidth is 1554 kbps. The routing protocols, such as Interior Gateway Routing Protocol (IGRP) and Enhanced Interior Gateway Routing Protocol (EIGRP), use this parameter to compute the routing metrics. If the bandwith differs from the default value (1544 or 1536), the command 7206-frame(cong-if) #bandwidth value species the correct access rate of the line. Delay in the interface in milliseconds.
Line protocol is [up | down] Hardware is QUICC Serial (with onboard CSU/DSU) MTU 1500 bytes BW 1544 Kbit DLY 20000 usec
503
Table 17-2
The Output From #show interface serial 0 and Its Description (Continued) Output reliability 255/255, txload 1/255, rxload 1/255 Encapsulation FRAME-RELAY, loopback not set Keepalive set (10 sec) Description Reliability, transmit load (txload) and receive load (rxload) are a fraction of 255. Thus, 255/255 is the highest and 1/255 is the lowest. The encapsulation of the interface is Frame Relay and the loopback is not set. Keepalive messages are set to 10-second intervals. In some cases, an interval of 30 seconds is acceptable, in other cases, the engineers set the DSU interval to 8 seconds, which is less than the switch interval, and it is set up this way to prevent the line from apping. One of the techniques used for troubleshooting is to negate the keepalives with 7206-frame(cong-if)#no keepalive to prevent the line from apping reports and to rely only on LMIs. LMI enq sent 53714 LMI stat recvd 53710 LMI upd recvd 0 DTE LMI up The number of LMI enquiry messages sent by the DTE. The number of LMI status messages received from the switch. The number of LMI updates received. An indication of DTE LMI [up | down]. (Matches some of the parameters of #show frame-relay status) LMI enq recvd 0 LMI stat sent 0 LMI upd sent 0 The number of LMI status enquiries received by the switch. The number of LMI status messages sent to the switch. The number of LMI updates sent to the switch. (Matches some of the parameters of #show frame-relay status) LMI DLCI 0 LMI type is ANSI AnnexD Frame Relay DTE The type of LMI signaling (see Chapter 14 or the following chapter). In this case, DLCI 0 indicates ANSI AnnexD LMI. The other options are cisco and q.933. FR SVC disabled Link Access Procedures for FrameMode Bearer Services (LAPF) state down Broadcast queue 0/64, broadcasts sent/dropped 8958/0, interface broadcasts 3 This report is for PVC design (frame-relay), but not Frame-Switching. This is why the SVC is down. LAPF down means LAPF is not performing the signaling in this circuit. Only the core functions of LAPF are involved. The line reports the status of the broadcast queue. In Frame Relay, this queue is separate from others. continues
504
Table 17-2
The Output From #show interface serial 0 and Its Description (Continued) Output Last input 00:00:00, output 00:00:00 Description The number of hours, minutes, and seconds since the last packet was received (input) or sent (output) by this interface. Indicates hours:minutes:seconds or never since the last reset of this interface. If the time is more than 24 hours, you can see 2d3h (2 days and 3 hours), but if this format is not large enough, you can see *****, which indicates more characters than can be expressed in this format. Often when troubleshooting, you need to start with fresh data. This value indicates the last time in hours:minutes:seconds (or never) that the interface was cleared by using any of the following commands: 1602-frame#clear counters serial 0 7206-frame#clear counters serial 3/0:0 7206-frame#clear interface serial 3/0:0 Queuing strategy: fo Output queue 0/40, 0 drops Input queue 1/75, 0 drops The FIFO queuing strategy stands for First-In-First-out. For other queuing strategies, see www.cisco.com. An input queue with self-explanatory parameters and the number of dropped packets because of a lack of queue slots. If the number of dropped packets is high, you might want to check the interface buffers using the following command: 1602-frame#sh buffers Conversations 0/1/16 (active/max active/max total) Reserved conversations 0/0 (allocated/max allocated) 5 minute input rate 0 bits/sec, 2 packets/sec 5 minute output rate 0 bits/sec, 0 packets/sec Multiplexing many logical (virtual) interfaces into one physical interface is called data conversations. This information exists only for the D channel. BRI channels do not have signaling functions. The average rate of data exchange in and out in 5-minute intervals, measured in bit/sec and packets/sec. It indicates exponentially weighted values, which are cumulative values and not snapshot values. You only use this parameter as an approximation of the trafc, to check trafc trends, or to compare with other interfaces. The number of successfully received packets and bytes. The number of instances of a lack of input buffer slots. Total number of received broadcasts on this interface. The number of discarded packets because their size was smaller than the minimum packet size.
Output hang never
Last clearing of show interface counters 1w0d
230,129 packets input, 44,936,503 bytes, 0 no buffer Received 0 broadcasts 0 runts 1 giants 0 throttles
505
Table 17-2
The Output From #show interface serial 0 and Its Description (Continued) Output Description The number of discarded packets because their size was greater than the maximum packet size. The number of times the receiver on the port was disabled, possibly because of buffer or processor overload. 7241 input errors 3594 CRC 2701 frame 0 overrun 0 ignored 944 abort The total number of input errors since the last #clear counters command, which are categorized as follows: Cyclic redundancy check (CRC) errors that usually indicate noise or other transmission problems. Incorrectly received packets, or packets with a non-integer number of octets, which usually indicates noise or other transmission problems. The number of times when the input rate exceeded the receivers ability to buffer and handle the data. The number of times when the hardware ran low in internal buffers. Broadcast storms and bursts of noise can be the possible cause of this problem. The number of aborts. It shows an illegal number of 1s in the interface, which is an indication of clocking problems on the interface. 229,128 packets output, 49,424,950 bytes 0 underruns 0 output errors 0 collisions 2509 interface resets 0 output buffer failures, 0 output buffers swapped out 6 carrier transitions The number of output packets and bytes in the interface that were passed without errors. The number of times when the transmitter runs faster than the router can handle. The number of all output errors. The number of collisions on the interface, which might come from the contention failures. A number of collisions more than 45 percent should be investigated. The number of interface resets indicates no signal in the interface. On the serial line, this is caused by a malfunctioning modem DSU/CSU or a cable problem. If the router sees the DTR up but protocol down, it resets the interface in an effort to trigger the LMI or keepalive exchange. The number of buffer failures and swapped output buffers. The number of carrier transitions, where an excessive number indicates either intrusive testing performed by the LEC, or switch card/line problems that must be investigated with the LEC. continues
506
Table 17-2
The Output From #show interface serial 0 and Its Description (Continued) Output DCD = up DSR = up DTR = up RTS = up CTS = up Description DCD clock is up. Data Set Ready (DSR), an input signal, is up. Data Terminal Ready, an output signal, is up. Request To Send (RTS), an output signal, is up. Clear To Send (CTS), an input signal, is up. All ve ups indicate that the serial interface is up.
If at any step of the troubleshooting process, the number of errors exceeds an approximate range of 0.5 percent to 2.0 percent of trafc on the interface, clocking problems are likely to exist somewhere in the WAN.
Data Link Layer Troubleshooting

Troubleshooting the second layer in Frame Relay includes the encapsulation types, LMI types and messages, and should be performed just after the physical layer issues are resolved. As previously mentioned #show ip interface brief and #show interfaces serial 1(0) are the commands that help narrow the scope of troubleshooting. Some typical reports for protocol layer issues are shown in Example 17-16 and Example 17-17.
Example 17-16 The Serial 1 Interfaces Show Line Up and the Protocol Down
1604-frame#show ip interface brief Interface IP-Address OK? Method Status Protocol Ethernet0 121.70.194.209 YES NVRAM up up Loopback0 unassigned YES NVRAM up up Serial0 unassigned YES NVRAM administratively down down ! The following narrows the scope of possible problems to ! the data link layer issues. Serial1 unassigned YES NVRAM up down Serial1.37 unassigned YES unset down down
Example 17-17 Data Link Layer Issues Can Be Seen if You Use the show interfaces Command
7206-frame#show interfaces s3/0:0 Serial0 is up, line protocol is down Hardware is QUICC Serial (with onboard CSU/DSU) <output omitted>
507
PVC Conguration Issues

Conguration issues for a PVC include problems with conguration, encapsulation, and bandwidth denitions. In the case of a 56-kbps conguration shown in Example 17-18, the conguration line is shaded and denes the type of PVC encapsulation.
Example 17-18 First Step Is to Make Sure the Conguration Is Correct
1602-frame#show running-config <output omitted> ! interface Serial0 no ip address ! The frame relay encapsulation and its type (IETF) are your primary focus here encapsulation frame-relay IETF no fair-queue service-module 56k clock source line service-module 56k network-type dds ! The LMI type is the second point of attention frame-relay lmi-type ansi ! <output omitted>
In the case of fractional T1 (FT1) or T1 congurations, the conguration settings are a little different. The conguration lines are shown in Example 17-19.
Example 17-19 In Case of Fractional T1, the Encapsulation and the LMI Type Need to Be Your Primary Focus
1602-frame#show running-config <output omitted> ! interface Serial1 <output omitted> ! The frame relay encapsulation and its type are your primary focus here encapsulation frame-relay no ip mroute-cache no fair-queue ! The access rate configuration is your secondary focus. service-module t1 timeslots 1-2 ! The LMI type is the next point of attention frame-relay lmi-type ansi ! <output omitted>
508
The encapsulation options are shown in Example 17-20.

Example 17-20 The Encapsulation Options for Cisco 1602 Frame Relay Routers
1602-frame(config-if)#encapsulation ? atm-dxi ATM-DXI encapsulation frame-relay Frame Relay networks hdlc Serial HDLC synchronous lapb LAPB (X.25 Level 2) ppp Point-to-Point protocol smds Switched Megabit Data Service (SMDS) x25 X.25
Frame Relay encapsulation options are cisco and ietf (RFC 1490 and RFC 2427). In pointto-point congurations, you need to congure a subinterface, as shown in Example 17-21.
Example 17-21 Fragment of Conguration of Point-To-Point Interface Serial0.1
interface Serial0.1 point-to-point bandwidth 56 ip unnumbered Ethernet0 frame-relay interface-dlci 16
Encapsulation options are shown in Example 17-22, and if the encapsulation type is omitted, it defaults to cisco.
Example 17-22 Frame Relay DLCI Encapsulation Options
3640-frame(config-fr-dlci)# interface-dlci 16 ? cisco Use CISCO Encapsulation ietf Use RFC1490/RFC2427 Encapsulation ppp Use RFC1973 Encapsulation to support PPP over FR protocol Optional protocol information for remote end,
The DLCI types are as follows: cisco (Consortium, by default), ietf (uses RFC 1490/RFC 2427 encapsulation), ppp (uses RFC 1973 encapsulation to support PPP over Frame Relay), and protocol.
NOTE
An interesting discussion about different ppp options can be found in RFC 1490, Multiprotocol Interconnect over Frame Relay, by Bradley (July 1995). The ppp option is available in Cisco IOS version 12.0(1).T and later versions. The interesting part about ppp encapsulation is related to the auto recognition of ppp frames and proposed options for LCP, authentication, and compression techniques.
509
The rst potential problem to check is the access rate denition. The service module denition congures the line as a 2 64-kbps access rate service. If there is any mismatch between both sides of the UNI interface, the report of the line shows the output in Example 17-23.
Example 17-23 This Output Shows That if the Protocol Layer is Down, the Access Rate Conguration Can Be a
Potential Problem
1604-frame#show ip interface brief Interface IP-Address OK? Method Status <output omitted> Serial1 unassigned YES NVRAM up Serial1.37 unassigned YES unset down Protocol down down
The second important factor is to make sure that the interface is congured with proper encapsulation, and that it matches the encapsulation in the near-end and far-end:
1602-frame(config-if)#encapsulation frame-relay [cisco
ietf]
The available options in Cisco routers are as follows:
ciscoUses Ciscos own encapsulation. ietfThe encapsulation complies with the Internet Engineering Task Force (IETF) standard (RFC 1490). If the chosen encapsulation is IETF, this is an indication that the conguration is designated for a multivendor environment.
NOTE
If the encapsulation is not dened under the serial interface, an attempt to create a subinterface will not work because the default Cisco encapsulation in the serial interface is Cisco Proprietary high-level data link control (HDLC), which does not support subinterfaces.
The correct PVC conguration depends on several factors. The core of the PVC is the DLCI, so you must ensure that the conguration uses the proper DLCI, as it is assigned by the LEC. The DLCI has a local signicance, and can be different at each end. At the same time, the DLCI is bound to a certain port on the switch and it cannot be used without the proper settings. When the switch receives a frame, it performs a series of predened operations. First, it recalculates the FCS and if the value does not match the FCS of the frame, it drops the packet. At the same time, the switch checks the DLCI and the length of the frame. If the DLCI is not correct or the frame is too long, too short, or falls beyond the byte boundary, it discards the frame. After the rst check is passed, the switch checks its routing/switching table for proper routing. This routing table consists of port-to-DLCI values, with each pair associated with input or output ows. After the entry is found, the switch changes the incoming DLCI in the frame with the DLCI from the output portion of
510
the table. Using this approach, the incoming DLCI x becomes the outgoing DLCI y and matches the far-end of the connection. Before sending the frame, the switch recalculates the new frame check sequence (FCS), replaces this portion in the outgoing frame, and sends the frame out. If the remote users equipment is congured with an incorrect DLCI, the indication from the down protocol shows a problem with the DLCI. The line protocol shows down in point-to-point congurations. If the DLCI is miscongured, the line protocol does not show down if the conguration is point-to-multipoint. Cisco routers ease the DLCI troubleshooting process. An example of the output from an incorrect DLCI conguration is shown in Example 17-24. In this example, the LECs switch is congured for DLCI 16, but the router is congured with DLCI 17. Theres more than one indication that the conguration is not correct, as shown in the example.
Example 17-24 The Focus Points, Indicating That There Is an Active DLCI, But There Is Also a Conguration Issue
1602-frame#show frame-relay pvc PVC Statistics for interface Serial0 (Frame Relay DTE) ! For Serial 0, there is one deleted and one active DLCI ! This should be your first point of attention. Active Inactive Deleted Static Local 0 0 1 0 Switched 0 0 0 0 Unused 1 0 0 0 ! Note that DLCI=16 is active, but unused. ! This should be your second point of attention. DLCI = 16, DLCI USAGE = UNUSED, PVC STATUS = ACTIVE, INTERFACE = Serial0 input pkts 3 output pkts 0 in bytes 918 out bytes 0 dropped pkts 0 in FECN pkts 0 in BECN pkts 0 out FECN pkts 0 out BECN pkts 0 in DE pkts 0 out DE pkts 0 out bcast pkts 0 out bcast bytes 0 Num Pkts Switched 0 pvc create time 00:02:45, last time pvc status changed 00:02:45 ! Why is the DLCI reported deleted? ! This should be your third point of attention. DLCI = 17, DLCI USAGE = LOCAL, PVC STATUS = DELETED, INTERFACE = Serial0.17 input pkts 0 output pkts 1 in bytes 0 out bytes 312 dropped pkts 0 in FECN pkts 0 in BECN pkts 0 out FECN pkts 0 out BECN pkts 0 in DE pkts 0 out DE pkts 0 out bcast pkts 1 out bcast bytes 312 pvc create time 00:03:44, last time pvc status changed 00:02:50 1602-frame#
NOTE
511
NOTE
When checking the DLCI, the other end of the connection is not relevant because DLCI only has a local signicance.
NOTE
Remember that if the PVC is reported as inactive or deleted, and even if LMI is congured correctly, LMI still does not send packets over the DLCI. The rst group of data (the overall status of the PVCs) provided by the last LMI shows that the serial line has one local and deleted PVC and one active but unused DLCI. (Later in the discussion, you see that LMI must provide the status of all PVCs congured on the interface on every full status message.) The second indication of the DLCI status is its description (see PVC STATUS line). As shown, the congured DLCI = 17 under subinterface Serial0.17 is not correct and the correct one is DLCI = 16. The overall status of the PVC can be analyzed by using the #show frame-relay pvc command as displayed in Example 17-24. Table 17-3 contains a description of the output from this command.
Table 17-3 Output
Output and Description From the #show frame-relay pvc Command Description
This Section Shows the Standard Output DLCI DLCI USAGE PVC STATUS INTERFACE Input pkts Output pkts in bytes out bytes dropped pkts in FECN pkts in BECN pkts out FECN pkts out BECN pkts DLCI numbers for the PVC. Lists SWITCHED when the router or access server is used as a switch, or LOCAL when used as a DTE. Status of the PVC: ACTIVE, INACTIVE, or DELETED. Specic subinterface associated with this DLCI. Number of packets received on this PVC. Number of packets sent on this PVC. Number of bytes received on this PVC. Number of bytes sent on this PVC. Number of incoming and outgoing packets dropped by the router at the Frame Relay level. Number of packets received with the FECN bit set. Number of packets received with the BECN bit set. Number of packets sent with the FECN bit set. Number of packets sent with the BECN bit set. continues
512
Table 17-3 Output in DE pkts out DE pkts out bcast pkts out bcast bytes
Output and Description From the #show frame-relay pvc Command (Continued) Description Number of DE packets received. Number of DE packets sent. Number of output broadcast packets. Number of output broadcast bytes. Time the PVC was created. Time the PVC changed status (active to inactive).
pvc create time last time pvc status changed
This Section Appears if Voice Is Congured for This PVC Service-type congured voice bandwidth used voice bandwidth Voice reserved queues Fragment type Type of service performed by this PVC. Can be Voice over Frame Relay or Voice over Frame Relay-cisco. Amount of bandwidth in bits per second reserved for voice trafc on this PVC. Amount of bandwidth in bits per second currently being used for voice trafc. Queue numbers reserved for voice trafc on this PVC. This eld was removed in Cisco IOS Release 12.0(5)T. Type of fragmentation congured for this PVC. The possible types are as follows: Voice over Frame Relay-ciscoFragmented packets contain the Cisco proprietary header. Voice over Frame RelayFragmented packets contain the FRF.11 Annex C header. End-to-endFragmented packets contain the standard FRF.12 header. Fragment size Size of the fragment payload in bytes.
This Section Appears if the Trafc Shaping Map Class Is Applied to this PVC (Refer to End-toEnd Issues Later in This Chapter) Cir Bc Be Limit Interval Current CIR, in bits per second. Current committed burst size, in bits. Current excess burst size, in bits. Maximum number of bytes transmitted per internal interval (excess plus sustained). Interval being used internally (can be smaller than the interval derived from Bc/ CIR; this occurs when the router determines that trafc ow is more stable with a smaller congured interval). Minimum CIR for the PVC. Number of bytes that can be sustained per internal interval. Frame Relay has backward explicit congestion notication (BECN) adaptation congured.
Mincir Byte increment BECN response
513
Table 17-3 Output Pkts Bytes Pkts delayed Bytes delayed Shaping Shaping drops
Output and Description From the #show frame-relay pvc Command (Continued) Description Number of packets associated with this PVC that went through the trafc shaping system. Number of bytes associated with this PVC that went through the trafc shaping system. Number of packets associated with this PVC that were delayed by the trafc shaping system. Number of bytes associated with this PVC that were delayed by the trafc shaping system. Shaping is active for all PVCs that are fragmenting data; otherwise, shaping is active if the trafc sent exceeds the CIR for this circuit. Number of packets dropped by the trafc shaping process. Statistics showing the size of packets, the maximum number of packets, and the number of packets dropped in the special voice queue created by using the framerelay voice bandwidth command queue keyword. Maximum number of packets that can be stored in each packet queue. If additional packets are received after a queue is full, they are discarded. Number of packet queues reserved for best-effort trafc. Number of packet queues reserved for voice trafc. Size in bytes of each output queue. Maximum number of packets of all types that can be queued in all queues. Number of frames dropped by all output queues.
Voice queuing stats
Discard threshold Dynamic queue count Reserved queue count Output queue size max total Drops
LMI Issues
The PVC status reports the static or snapshot information, and the LMI provides the dynamics for the troubleshooting process. Some explanations are necessary to understand the outputs on the screen. For troubleshooting purposes, it is important to understand the difference between formats and the underlying concept of LMIs. Local Management Interfaces (LMIs) provide information about the DLCI values and the status of virtual circuits. Three different standards for LMI messages exist: cisco LMI (default), which users DLCI 1023 for connection management, ANSI LMI, which uses DLCI 0 for connection management, and Q933a (ITU). The Consortium LMI denes two messages: status enqiry and status. The general format of LMI type cisco (Consortium) is shown in Figure 17-2. Both messages are sent in HDLC Unnumbered Information (UI) frames, with a Control eld value of 03h. The message header, based on Q.931, is three octets and includes protocol
514
discriminator 09h, call reference value 00h (Dummy Call reference), and message type indicator for the message type: status enquiry 75h (0111 0101) or status 7Dh (0111 1101).
Figure 17-2 LMI Message Format (Consortium)
1 Flag 01111110
2 Address
2 FCS
1 Flag 0111110
1
Consortium Message Header 1 1 1 Protocol Call Message Descriminator Reference Type* (09h) (00h)
n IE1
n IE2
n IE...
* The Message Type Can Be 0111 1101 Status 0111 0101 Status Inquiry
The Consortium LMI Status Enquiry Message Format

The Consortium LMI operates by periodically polling the network, and by using status enquiry messages. The Consortium document denes the polling period as the variable nT1, which ranges from 5 to 30 seconds, where 10 seconds is the default. The message contains two IEs: Report Type and Keepalive Sequence (see Figure 17-3).
Figure 17-3 LMI Status Enquiry Message Format (Consortium)
1 Flag 01111110
2 Address
2 FCS
1 Flag 01111110
Consortium Message Header (Mandatory)

1 Control UI Frame 03h
1 Protocol Descriminator (09h)
1 Call Reference (00h)
1 Message Type
3 Report Type (Mandatory)
4 Keepalive Sequence (Mandatory)
515
When used with the status enquiry message, the report type denes the content of the networks Status message. The report type IE is identied by 01H in the rst byte. The second byte species the length of the contents, and the third one identies the report type. A report type of 00H indicates a full status message, and 01h indicates a sequence number exchange, which veries the integrity of the link.
NOTE
The Consortium format of the report type is the same as for AnnexD. The difference is AnnexD denes an additional report type, which is the Single PVC Asynchronous Status Report, 02h.
The Keepalive Sequence IE is identied by a 03h in the rst octet. The second octet species the length of the contents in bytes (02 stands for the second octet), and the last two bytes are Current and Last received sequence numbers. Each time the router or network sends a status enquiry message, it increments its internal sequence number and places the value in the Current received sequence number (byte three). The last sequence number received from the other end of the link is paced in the Last received sequence number (byte four).
NOTE
Less frequently, the Frame Relay access device (router) requests a full status message, which adds one PVC status IE for each PVC congured on the interface. This polling period is dened by the variable nN1, which ranges from 1 to 255 intervals of nT1, with a default of six intervals.
The Consortium LMI Status Message Format

The network sends the status message to the CPE in response to the status enquiry message. Figure 17-4 shows the status message format. Report type and keepalive sequence IEs are always transmitted with the status message. PVC IEs are added, one per congured PVC, to the status message when the full status message is requested. The PVC status IE is identied by 07h in the rst octet and it is either 5 or 8 bytes long. The second octet species the length of the contents (3 or 6 bytes). The third and fourth octets carry the DLCI for this PVC, and the fth octet contains status-bit coding that identies whether the PVC is new (N = 1) or Active (A = 1). The Consortium dened octets 6 through 8 to optionally carry a 24-bit number, which represents the minimum bandwidth in bits per second that the network has allocated for this PVC.
516
Figure 17-4 LMI Status Message (Consortium) Format
1 Flag 01111110
2 Address
2 FCS
1 Flag 01111110
Consortium Message Header (Mandatory) 1 Control UI Frame 03h 1 Protocol Descriminator (09h) 1 Call Reference (00h) 1 Message Type 3 Report Type * (Mandatory) 4 Keepalive Sequence (Mandatory) 5 or 8 PVC Status (Optional)
* The Report Type IE Includes
LMI Type ANSIT1.617 AnnexD

The Consortium status enquiry messages contain the report type and keepalive sequences, and the AnnexD status enquiry messages contain report type and link integrity verication IEs, as shown in Figure 17-5. The link integrity verication IE has the value of 03h in the Control UI Frame eld.
Figure 17-5 AnnexD Status Enquiry Message
1 Flag 01111110
2 Address
2 FCS
1 Flag 01111110
AnnexD Message Header (Mandatory) 1 Control UI Frame 03h 1 Protocol Descriminator (08h) 1 Call Reference (00h) 1 Message Type 1 Locking Shift (95h) 3 Report Type (Mandatory) 4 Link Integrity Verification (Mandatory)
The link integrity verication IE has an identication ID in the rst byte, the length of the integrity verication content in the second byte, send sequence number in the third byte, and receive sequence number in the fourth byte.
517
The AnnexD status message uses a similar format as Consortium, as shown in Figure 17-6.
Figure 17-6 AnnexD Status Message Format
1 Flag 01111110
2 Address
2 FCS
1 Flag 01111110
AnnexD Message Header (Mandatory) 1 Control UI Frame 03h 1 Protocol Descriminator (08h) 1 Call Reference (00h) 1 Message Type 1 Locking Shift (95h) 3 4 Report Link Integrity Type Verification (Mandatory) (Optional) 5-7 PVC Status
The Report Type IE Coding Is as Follows: 0000 0000 Full Status (Status of all PVCs on the Bearer Channel) 0000 0001 Link Integrity Verification Only 0000 0010 Single PVC Asynchronous Status All Other Values Are Reserved
The LMI type conguration is crucial for Frame Relay service. If the DTE conguration does not match the switch conguration, the LMI autosense mode is used, which is supported by Cisco. If the conguration of LMI is not congured explicitly, the router sends out a full status enquiry in all three LMI types to the switch. The order is ANSI, ITU, and Cisco. Cisco can listen on DLCI 0 and DLCI 1023 simultaneously. One of the enquiries receives a status message, but if the autosense is unsuccessful, another status enquiry message is sent every N391 interval (the default is 60 seconds: 6 attempts every 10 seconds) to try to dene the LMI type. After a status message is received, Cisco IOS decodes the message and congures the router with the correct LMI type. When the LMI type is congured, you can use either of the following two options to see the details of the LMI exchange:
1602-frame#show frame-relay lmi 1602-frame#debug frame-relay lmi
The rst command reports the statistics for the time period, after clearing the interface counters, as shown in Example 17-25 and explained in Table 17-4.
Example 17-25 Output from the show frame-relay lmi Command
7206-frame#show frame-relay lmi LMI Statistics for interface Serial3/0:0 (Frame Relay DTE) LMI TYPE = ANSI Invalid Unnumbered info 0 Invalid Prot Disc 0
continues
518
Example 17-25 Output from the show frame-relay lmi Command (Continued)
Invalid dummy Call Ref 0 Invalid Status Message 0 Invalid Information ID 0 Invalid Report Request 0 Num Status Enq. Sent 5570 Num Update Status Rcvd 0 Invalid Msg Type 0 Invalid Lock Shift 0 Invalid Report IE Len 0 Invalid Keep IE Len 0 Num Status msgs Rcvd 5570 Num Status Timeouts 0
Table 17-4
Output and Description of the #show frame-relay lmi Command Output LMI Statistics Invalid Unnumbered info 0 Invalid Prot Disc 0 Invalid Dummy Call Ref 0 Invalid Msg Type 0 Invalid Status Message 0 Invalid Lock Shift 0 Description Signaling or LMI specication: CISCO, ANSI, or ITU-T. Number of received LMI messages with invalid unnumbered information eld. Number of received LMI messages with invalid protocol discriminator. Number of received LMI messages with invalid dummy call references. Number of received LMI messages with invalid message type. Number of received LMI messages with invalid status message. Number of received LMI messages with invalid lock shift type. Refer to the LMI ANSI message type. Invalid Information ID 0 Invalid Report IE Len 0 Invalid Report Request 0 Invalid Keep IE Len 0 Num Status Enq. Sent 5570 Number of received LMI messages with invalid information identier. Number of received LMI messages with invalid Report IE Length. Number of received LMI messages with invalid Report Request. Number of received LMI messages with invalid Keep IE Length. Number of LMI status inquiry messages sent. Number of status enquiries successfully sent after the last clear counters command. Num Status Msgs Rcvd 5570 Number of LMI status messages received. Number of status enquiries successfully received after the last clear counters command. Num Update Status Rcvd 0 Num Status Timeouts 0 Number of LMI asynchronous update status messages received. Number of times the status message was not received within the keepalive time value. Number of resets trying to trigger the exchange.
519
For troubleshooting purposes, you need to identify non-zero values and, based on the provided gures, analyze the connection. An important consideration is the keepalive (Invalid Keep IE Len) messages and timeouts for status enquiry messages (Num Status Enq. Timeouts), which reect the number of resets when the interface tries to trigger the exchange within the T392 time interval. All parameters depend on Frame Relay timers and counters, which are listed in Table 17-6.
NOTE
If there are no LMI-related errors, expect Num Status Enq. Sent = 5570 and Num Status msgs Rcvd = 5570 to be the same. In erroneous conditions, Num Status Enq. Sent = Num Status msgs Rcvd + Num Status Timeouts Expect performance issues when this occurs.
The second troubleshooting tool is debug frame-relay lmi. The output of this command is not chatty, so it can be used without concern for use of the main CPU in the router. The output from a serial line of 1544 kbps, with Cisco encapsulation for Frame Relays, LMI DLCI 0 with a LMI type of ANSI AnnexD, and the router is DTE, as shown in Example 17-26.
Example 17-26 Full Status Request Message
7206-frame#debug frame-relay lmi Aug 26 11:03:25 PDT: Serial4/2:0(out): StEnq, myseq 183, yourseen 182, DTE up (OUT) Report for serial interface 4/2:0. STATUS ENGUIRY message; myseq=183, yourseen=182 out; DTE up. Aug 26 11:03:25 PDT: datagramstart = 0x7000214, datagramsize = 14 (OUT) Start of the next datagram; size of the datagram Aug 26 11:03:25 PDT: FR encap = 0x00010308 (OUT) Frame Relay encapsulation 0x00010308 cisco; ( 0xFCF10309 IETF) Aug 26 11:03:25 PDT: 00 75 95 01 01 00 03 02 B7 B6 Aug 26 11:03:25 PDT: Aug 26 11:03:25 PDT: Serial4/2:0(in): Status, myseq 183 (IN) STATUS message from the switch;myseq 183 Aug 26 11:03:25 PDT: RT IE 1, length 1, type 0 (IN) Report Type (RT) Information Element 1, length 1, type 0 Aug 26 11:03:25 PDT: KA IE 3, length 2, yourseq 183, myseq 183 (IN) Keep Alive (integrity verification message); length, yourseq, myseq. Aug 26 11:03:25 PDT: PVC IE 0x7 , length 0x3 , dlci 35, status 0x2 Aug 26 11:03:25 PDT: PVC IE 0x7 , length 0x3 , dlci 37, status 0x2 Aug 26 11:03:25 PDT: PVC IE 0x7 , length 0x3 , dlci 38, status 0x2 Aug 26 11:03:25 PDT: PVC IE 0x7 , length 0x3 , dlci 40, status 0x2 Aug 26 11:03:25 PDT: PVC IE 0x7 , length 0x3 , dlci 45, status 0x2 Aug 26 11:03:25 PDT: PVC IE 0x7 , length 0x3 , dlci 46, status 0x2 Aug 26 11:03:25 PDT: PVC IE 0x7 , length 0x3 , dlci 55, status 0x2 Aug 26 11:03:25 PDT: PVC IE 0x7 , length 0x3 , dlci 56, status 0x2 Aug 26 11:03:25 PDT: PVC IE 0x7 , length 0x3 , dlci 59, status 0x2 Aug 26 11:03:25 PDT: PVC IE 0x7 , length 0x3 , dlci 64, status 0x2
continues
520
Example 17-26 Full Status Request Message (Continued)

Aug 26 11:03:25 PDT: PVC IE 0x7 , length 0x3 , dlci 67, status Aug 26 11:03:25 PDT: PVC IE 0x7 , length 0x3 , dlci 68, status Aug 26 11:03:25 PDT: PVC IE 0x7 , length 0x3 , dlci 72, status Aug 26 11:03:25 PDT: PVC IE 0x7 , length 0x3 , dlci 75, status Aug 26 11:03:25 PDT: PVC IE 0x7 , length 0x3 , dlci 84, status Aug 26 11:03:25 PDT: PVC IE 0x7 , length 0x3 , dlci 90, status Aug 26 11:03:25 PDT: PVC IE 0x7 , length 0x3 , dlci 92, status ! All PVCs are listed because full status message was used. 0x2 0x2 0x2 0x2 0x2 0x2 0x2
You must know what to expect from various outputs; the expected LMI code values are shown in Table 17-5.
Table 17-5 LMI Code Values Message Type Status Status enquiry Update status Information Element ID Keep Alive Sequence Report Type PVC status/Modied PVC status Multicast status Information Denitions Report Type Full status message Sequence number exchange Reserved PVC Status Bit Coding New status PVC already present PVC active PVC inactive Modied PVC Status Bit Codings PVC Present 000000XX 00001RXR 00000RXR** 00000R1R 00000R0R 00000000 00000001 RAll other values 00000011 00000001 00000111 00000101 Binary Value* 01111101 01110101 01111011
521
Table 17-5
LMI Code Values (Continued) Message Type PVC deleted DLCI added PVC active PVC inactive PVCs buffers above threshold PVCs buffers below threshold Multicast Status Bit Codings Multicast Channel Present Multicast Channel Deleted DLCI added Multicast active Multicast inactive
* Rreserved; Xdoes not matter. ** Note the PVC status reporting; the PVC present is 0000RXR and is either active or inactive.
Binary Value* 000001XX 000010XX 0000XX1X 0000XX0X 0000XXX1 0000XXX0
000000XX 000001XX 000010XX 0000XX1X 0000XX0X
For more information, see Frame Relay Networking by Gilbert Held (John Wiley and Sons, Inc., 1999).
NOTE
Some common status indications based on the output include status 0xa, which represents a PVC and indicates that the DLCI is passing trafc to the far end; status 0x2, which indicates that the PVC is added and passing trafc; status 0x0, which indicates that the PVC is added but inactive; status 0x4, which identies that the PVC as deleted; and status 0x8, which indicates that the new PVC is not active.
The appearance of the full status message in the LMI debug is a congurable parameter that is controlled by the value of n391 timers. Because many of the parameters in this exchange are congurable, the optional values and conguration commands are shown in Table 17-6. The importance of the LMI timer and counter parameters is obvious. One additional aspect to be considered is the situation when you see keepalive mismatches, where both sides of the connection use different keepalive intervals. This solution requires attention to prevent the line from apping.
522
Table 17-6
LMI Timers and Counters Timers N391dte Description The full status-polling interval, which transmits a status enquiry after expiration. It records an error if STATUS is not received. Set DCE and NNI interface error threshold (declared down), which after expiration, records the error, increments, and restarts. Set DTE and UNI interface error threshold (declared down), which after expiration, records the error, increments, and restarts. Set DCE and NNI monitored event count. Set DTE and UNI monitored event count (>than N392dte). Set the polling verication timer in the NNI interface. The maximum number of outstanding or unacknowledged IEs. The maximum number for retransmission of a frame. The maximum length of the I-frame in LAPF. The maximum retransmission timer value. The idle timer value (has to be T203>T200). 116,384 1100 165,535 Range 1255 Default 6 Cong Command frame-relay lmi-n391dte keep-exchange
N392dce
110
frame-relay lmi-n392dce threshold
N392dte
110
frame-relay lmi-n392dte threshold
N393dce N393dte T392dce K
110 110 530 1127
2 4 15 7
frame-relay lmi-n393dce events frame-relay lmi-n393dte events frame-relay lmi-t392dce seconds frame-relay lapf t203 k
N200 N201 T200 T203
3 260 bytes 15 30
frame-relay lapf n200 reties frame-relay lapf n201 bytes frame-relay lapf t200 sec/ 10 frame-relay lapf t203 seconds
NOTE
For troubleshooting purposes, you might sometimes consider verifying the PVC information. One tool to use here is the full status message, which regularly appears every 60 seconds. You can change this interval by using the Cisco IOS command frame-relay lmi-n391dte 1. This command requests a Local Management Interface (LMI) full status update every 10 seconds instead every 60 seconds (the default). Remember to turn off the command at the end of the troubleshooting process because this command adds more processing to the router and should be used only if it cannot be avoided.
523
Some of the timer and counter settings are shown in the output in Example 17-27. Even if SVC is disabled, and as a result the LAPF control protocol is down, some of the timer and counter settings show in the output, as in Example 17-27.
Example 17-27 Verifying the Status of the LAPF Protocol
1602-frame#show frame-relay lapf Interface = Serial1 (up), LAPF state = TEI_ASSIGNED (down) SVC disabled, link down cause = SVC disabled, #link-reset = 0 T200 = 1.5 sec., T203 = 30 sec., N200 = 3, k = 7, N201 = 260 I-frame xmt = 0, I-frame rcv = 0, I-frame reXmt = 0 I xmt dropped = 0, I rcv dropped = 0, Rcv pak dropped = 0 RR xmt = 0, RR rcv = 0, RNR xmt = 0, RNR rcv = 0 REJ xmt = 0, REJ rcv = 0, FRMR xmt = 0, FRMR rcv = 0 DM xmt = 0, DM rcv = 0, DISC xmt = 0, DISC rcv = 0 SABME xmt = 0, SABME rcv = 0, UA xmt = 0, UA rcv = 0 V(S) = 0, V(A) = 0, V(R) = 0, N(S) = 0, N(R) = 0 Xmt FRMR at Frame Reject
The parameters in Table 17-6 are related to one of the common techniques used by engineers to check the serial line when the LMI exchange is not available and as a result the Frame Relay protocol is reported down. The technique includes setting the encapsulation to HDLC (temporarily) on both ends of the link and then to run the command #debug interface serial from the DTE to determine if the keepalive message exchange is successful.
NOTE
The reason for temporarily changing the encapsulation is that LMI carries keepalive messages, and as soon as LMI is not functional, there is no keepalive exchange. To change the encapsulation from Frame Relay to HDLC, just negate the Frame Relay encapsulation. Cisco proprietary HDLC is the default encapsulation in serial lines. The other option is to dene HDLC explicitly by entering 1602-frame(cong-if)#encapsulation hdlc.
Example 17-28 shows the output of the debug interface serial command with LMI on.
Example 17-28 Output of the debug interface serial Command with LMI On
1602-frame#debug interface serial 6w6d: Serial1(out): StEnq, myseq 137, yourseen 136, DTE up (OUT) STATUS ENQUIRY, keepalive send by DTE (myseq 137), keepalive sent by the other side (yourseen 136), DTE is up. 6w6d: Serial1(in): Status, myseq 137 (IN) STATUS, DTE keepalive seen by the other side. 6w6d: Serial1(out): StEnq, myseq 138, yourseen 137, DTE up
continues
524
Example 17-28 Output of the debug interface serial Command with LMI On (Continued)
6w6d: Serial1(in): Status, 6w6d: Serial1(out): StEnq, 6w6d: Serial1(in): Status, 6w6d: Serial1(out): StEnq, 6w6d: Serial1(in): Status, 6w6d: Serial1(out): StEnq, 6w6d: Serial1(in): Status, 6w6d: Serial1(out): StEnq, 6w6d: Serial1(in): Status, 6w6d: Serial1(out): StEnq, 6w6d: Serial1(in): Status, 1602-frame# myseq myseq myseq myseq myseq myseq myseq myseq myseq myseq myseq 138 139, 139 140, 140 141, 141 142, 142 143, 143 yourseen 138, DTE up yourseen 139, DTE up yourseen 140, DTE up yourseen 141, DTE up yourseen 142, DTE up
Example 17-29 shows the output of the debug interface serial command with LMI off and HDLC on.
Example 17-29 Output of the debug interface serial Command with LMI Off and HDLC On
1602-frame#debug interface serial *Sep 16 01:26:57 PDT: Serial2/0/1:0: yourseen 20316, line up *Sep 16 01:27:07 PDT: Serial2/0/1:0: yourseen 20317, line up *Sep 16 01:27:17 PDT: Serial2/0/1:0: yourseen 20318, line up *Sep 16 01:27:27 PDT: Serial2/0/1:0: yourseen 20319, line up *Sep 16 01:27:37 PDT: Serial2/0/1:0: yourseen 20320, line up *Sep 16 01:27:47 PDT: Serial2/0/1:0: yourseen 20321, line up *Sep 16 01:27:57 PDT: Serial2/0/1:0: yourseen 20322, line up *Sep 16 01:28:17 PDT: Serial2/0/1:0: yourseen 20324, line up HDLC myseq 20158, mineseen 20158*, HDLC myseq 20159, mineseen 20159*, HDLC myseq 20160, mineseen 20160*, HDLC myseq 20161, mineseen 20161*, HDLC myseq 20162, mineseen 20162*, HDLC myseq 20163, mineseen 20163*, HDLC myseq 20164, mineseen 20164*, HDLC myseq 20166, mineseen 20166*,
*Sep 16 01:28:20 PDT: Illegal HDLC serial type code 34915, PC=0x601B7E8C
NOTE
It is common at the end of this output to see the message illegal serial line type xxx. The message indicates that the encapsulation is Frame Relay or HDLC, and the router attempts to send a packet with an unknown packet type.
If the (OUT) myseq message matches the other sides (IN) myseq message, the line is up. For N392dte keepalive exchanges, which count N393dte events, if the values do not match, the interface is reported down, the N392dte increments, and the interface restarts. In other
525
words, if in four consecutive exchanges the values do not match, the interface is reported down. The keepalive sequence IE (Consortium) is identied by a 03h in the rst octet. The second octet species the length of the contents in bytes (01 stands for 1 octet), and the last two bytes are current and last received sequence numbers. Each time the router or network sends a status enquiry message, it increments its internal sequence number and places the value in the current sequence number (byte three) (see Figure 17-7 and Figure 17-8). The last sequence number received from the other end of the link is placed in the last received sequence number (byte four). Both types of messages are four bytes in length and differ slightly in format, but work the same way.
Figure 17-7 Keepalive Sequence IE (Consortium)
8 0 0
7 0 0
6 0 0
5 0 0
4 0 0
3 0 0
2 1 0
1 1 1
Keepalive Sequence IE Identifier Length of Keepalive Contents Current Sequence Number Last Received Sequence Number
Figure 17-8 Link Integrity Verication IE (ANSI)
8 0
7 0
6 0
5 0
4 0
3 0
2 1
1 1
Link Integrity Verification IE Identifier Length of Link Integrity Verification Contents Send Sequence Number Receive Sequence Number
Several commands trim the keepalive messages, as shown in Table 17-7. These commands require a good understanding of the implication that they can have on the Frame Relay functionality and should be used with caution.
526
Table 17-7
IOS Keepalive Conguration Commands IOS Command frame-relay end-to-end keepalive error-threshold [send | receive] count frame-relay end-to-end keepalive event window [send | receive] size frame-relay end-to-end keepalive mode [bi-directional | request | reply | passive-replay] frame-relay end-to-end keepalive success-events [send | receive] count frame-relay end-to-end keepalive timer [send | receive] interval Description Modies the error threshold value. Modies the keepalive event window. When the keepalive mode is enabled, default values depend on which mode is selected. Modies the keepalive success events. Modies the keepalive timer value. 32/2 /10,15 Max/Default 32/2 32/3
These conguration commands can be part of the Frame Relay map-class denitions to trim the parameters of the service. Every single command has an output, which can be displayed if you enter the following:
3640#show frame-relay end-to-end keepalive interface serial 1
The full description of Cisco IOS Frame Relay conguration commands and their output can be found in Cisco IOS 12.0 Wide Area Networking Solutions (Cisco Press, 1999).
Performance Problems
Frame Relay performance problems include apping links, end-to-end problems, shaping problems, and compression over Frame Relay problems. They are described in detail in this section.
Flapping Links
One of the typical problems of poor performance is that the computers connected to the router lose their connection or experience high delay or slow performance. The issue is related to instability in the second layer and the protocol constantly going up and down. The rst step in troubleshooting this problem is to check both sides of the connection. The users end reports the output in Example 17-30.
Example 17-30 The Status of the Interfaces of the Remote Users Router
1602-frame#show ip interface brief Interface IP-Address Ethernet0 10.70.194.209 Loopback0 unassigned OK? Method Status YES NVRAM up YES NVRAM up Protocol up up
527
Example 17-30 The Status of the Interfaces of the Remote Users Router (Continued)
Serial1 Serial1.37 1602-frame# unassigned 10.70.194.209 YES NVRAM YES unset up up up up
Meanwhile, the core router is reporting the output in Example 17-31.

Example 17-31 The Status of the Interfaces of the Core Router
7026-frame#show ip interface brief Serial4/1:0 unassigned YES NVRAM up up <output omitted> !This interface - Serial 4/1:0.37 - is the peer of the remote users ! Serial 1.37 interface in this point-to-point configuration. Serial4/1:0.37 10.68.88.1 YES unset up up Serial4/1:0.41 10.68.88.1 YES unset up up Serial4/1:0.44 10.68.88.1 YES unset up up
Check the output carefully. If you compare both parts of the history of the PVC (see Chapter 14 to double-check who provides the history information), you can see a signicant difference between the time that the PVC is created and the last time the PVC was changed. Enter either of the following commands:
1602-frame#show frame-relay pvc 72060- frame#show frame-relay pvc 37
The following PVC information is displayed:
PVC create timeTime the PVC was created Last time PVC status changedTime the PVC changed status (active to inactive)
The full display of the output is shown in Example 17-32.

Example 17-32 Checking the History of Serial 1.37 on a Remote Users Router
1602-frame#show frame-relay pvc 37 PVC Statistics for interface Serial1 (Frame Relay DTE) DLCI = 37, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial1.37 input pkts 708285 output pkts 97790 in bytes 354082477 out bytes 20908266 dropped pkts 0 in FECN pkts 0 in BECN pkts 0 out FECN pkts 0 out BECN pkts 0 in DE pkts 708285 out DE pkts 0 out bcast pkts 22619 out bcast bytes 2437086 ! The next line shows the PVC was created 7w2d ago, but ! flapped 05:05 minutes ago pvc create time 7w2d, last time pvc status changed 00:05:05 ! There is no process in Frame Relay that requires the ! PVC to go down systematically. 1602-frame#
528
In Example 17-32, the rst time the end users router was turned on is 7w2d ago, and for some reason, 00:05:05 hours ago the PVC went down again. If you continue to monitor, you will see this measurement going up and down, which is known as apping. You can monitor Frame Relay permanent virtual circuits (PVCs) status better if you use the following commands under the serial 0(1) interface:
1602-frame(config-if)#logging event ? dlci-status-change DLCICHANGE messages link-status UPDOWN and CHANGE messages subif-link-status Sub-interface UPDOWN and CHANGE messages 1602-frame#
NOTE
These command parameters enable you to report any change in the status of the DLCI, link, or subinterface. This way, you can review the log the following day and be precise in your information as to how many times and when the PVC has changed its status. Remember to set the router clock before testing. You do not need to check if both sides are reacting the same way. You should not forget that the UNI is a local interface. Common sense dictates that whichever connection is apping is the one experiencing local loop or other problems. This can be resolved by working with the LEC.
End-to-End Problems
End-to-end issues in Frame Relay are related to factors including congestion, overuse or oversubscription of lines, or incorrect or apping routes. These factors can be recognized by some indicators such as degradation of performance during a particular time of day or after a period of normal operations. Although the routing problems are the subject of a wide variety of Cisco Press books (such as CCIE Professional Development: Advanced IP Network Design, by Retana, Slice, and White [Cisco Press, 1999]), the Frame Relay IOS troubleshooting techniques are the main objective of this section. The enhanced output of #show interfaces serial 1 provides a wealth of information for analysis. One indicator of excessive use is the reliability 255/255. The comparison between 5 minute input rate 0 bits/sec, 2 packets/sec and 5 minute output rate 0 bits/sec, 0 packets/sec and their reliability is a sign of excessive use. Every instance of reliability that trends away from 100 percent raises a red ag. The rst end-to-end tool to use is to check the status of the PVC. When trafc shaping is not on and the interface is inactive, the information in Example 17-33 appears on the screen.
NOTE
529
Example 17-33 The End-To-End Status of PVC

7206-frame#show frame-relay pvc <output omitted> DLCI = 65, DLCI USAGE = UNUSED, PVC STATUS = INACTIVE, INTERFACE = Serial3/2:0 input pkts 0 output pkts 0 in bytes 0 out bytes 0 dropped pkts 0 in FECN pkts 0 in BECN pkts 0 out FECN pkts 0 out BECN pkts 0 in DE pkts 0 out DE pkts 0 out bcast pkts 0 out bcast bytes 0 switched pkts 0 Detailed packet drop counters: no out intf 0 out intf down 0 no out PVC 0 in PVC down 0 out PVC down 0 pkt too big 0 shaping Q full 0 pkt above DE 0 policing drop 0 pvc create time 3w0d, last time pvc status changed 3w0d <output omitted>
NOTE
Some of the results of this output can also be displayed using #show frame-relay route.
When you want to see the status of any particular PVC, the command requires a DLCI number. Example 17-34 shows a sample of this output and includes all PVCs, with DLCI = 37.
Example 17-34 Verifying the Status of PVCs = 37
7206-frame#show frame-relay pvc 37 <output omitted> DLCI = 37, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial3/2:0.37 input pkts 243555 output pkts 253526 in bytes 32877370 out bytes 158986875 dropped pkts 264 in FECN pkts 0 in BECN pkts 0 out FECN pkts 0 out BECN pkts 0 in DE pkts 243555 out DE pkts 0 out bcast pkts 22834 out bcast bytes 6850200 pvc create time 3w2d, last time pvc status changed 3d21h cir 56000 bc 56000 be 0 byte limit 875 interval 125 mincir 28000 byte increment 875 Adaptive Shaping none pkts 253265 bytes 158969188 pkts delayed 130549 bytes delayed 130688876 shaping inactive traffic shaping drops 0 Queuing strategy: fifo Output queue 0/40, 264 drop, 130549 dequeued <output omitted>
Besides #show frame-relay pvc, an important troubleshooting tool is #debug frame-relay [packet | events], as shown in Example 17-35.
530
NOTE
The #debug frame-relay [packet | events] command is chatty, so when conducting remote troubleshooting it is good practice to have two telnet/SSH sessions open. One session should have both the #terminal monitor command and the #debug frame-relay packet command. The second session should have the #undebug all command ready to enter if necessary. Use these commands only if the routers utilization is low (below 25 percent).
Example 17-35 Output from the #debug frame-relay packet Command

1602-frame#debug frame-relay packet Frame Relay packet debugging is on 1602-frame# 7w3d: Serial1(i): dlci 37(0x853), NLPID 0x3CC(IP), datagramsize 146 incoming (i), dlci 37(0x851), network layer protocol ID = 3CCh, datagramsize 146 7w3d: Serial1(i): dlci 37(0x853), NLPID 0x3CC(IP), datagramsize 146 7w3d: Serial1(i): dlci 37(0x853), pkt type 0x2000, datagramsize 300 7w3d: Serial1.37(o): dlci 37(0x853), NLPID 0x3CC(IP), datagramsize 580 7w3d: Serial1.37(o): dlci 37(0x851), NLPID 0x3CC(IP), datagramsize 580 7w3d: Serial1.37(o): dlci 37(0x851), NLPID 0x3CC(IP), datagramsize 81 7w3d: Serial1(i): dlci 37(0x851), NLPID 0x3CC(IP), datagramsize 44 7w3d: Serial1(i): dlci 37(0x851), NLPID 0x3CC(IP), datagramsize 44 7w3d: Serial1.37(o): dlci 37(0x851), NLPID 0x3CC(IP), datagramsize 580 7w3d: Serial1.37(o): dlci 37(0x851), NLPID 0x3CC(IP), datagramsize 66 7w3d: Serial1(i): dlci 37(0x851), NLPID 0x3CC(IP), datagramsize 44 7w3d: Serial1.37(o): dlci 37(0x851), NLPID 0x3CC(IP), datagramsize 255 7w3d: Serial1(i): dlci 37(0x851), NLPID 0x3CC(IP), datagramsize 44 7w3d: Serial1.37(o): dlci 37(0x851), NLPID 0x3CC(IP), datagramsize 184 7w3d: Serial1(i): dlci 37(0x851), NLPID 0x3CC(IP), datagramsize 44 7w3d: Serial1.37(o): dlci 37(0x851), NLPID 0x3CC(IP), datagramsize 184 7w3d: Serial1(i): dlci 37(0x851), NLPID 0x3CC(IP), datagramsize 44 7w3d: Serial1.37: Broadcast on DLCI 37 link 65(CDP) ! The router broadcasts on dlci 37, using link 65 7w3d: Serial1.37(o): dlci 37(0x851), pkt type 0x2000(CDP), datagramsize 312 outgoing (o), dlci 37(0x851), packet type 2000h (CDP), datagramsize 312 7w3d: broadcast dequeue 7w3d: Serial1.37(o):Pkt sent on dlci 37(0x851), pkt type 0x2000(CDP), datagramsize 312 7w3d: Serial1.37(o): dlci 37(0x851), NLPID 0x3CC(IP), datagramsize 427 7w3d: Serial1(i): dlci 37(0x851), NLPID 0x3CC(IP), datagramsize 44
Refer to the beginning of the output, and you can see two different hexadecimal values for the same DLCI. This is not an error. To understand the output, see Figure 17-9, where the DLCI format is shown. If the format of the DLCI is 2 bytes, the values are shown in Figure 17-9. In this example, the DLCI = 37 (decimal) and the next value is also DLCI = 37 (decimal). The two messages differ because of the value of the DE bit (DE = 1 for the 0x853 message and DE = 0 for the x0851 message). In exactly the same way as Q.922 hexadecimal addresses, examples of the conversion include the following: 50 represents 0x0c21, 60 represents 0x0cc1, and 70 represents 0x1401.
531
Figure 17-9 Determining the DLCI from the #debug frame-relay packet Command
0x853 (853h) 0 0 0 0 0 1 0 1 and 1 0 0 0 0 1 0 1 0 0 0 1 0x851 (851h) 0 0 1 0 0 1 0 0
0 0
0 1
0 0 0 0 1 0 0 1 0 1
0 0 0 0 1 0 0 1 0 1
Another troubleshooting tool is the chatty #debug frame-relay events command, which helps to analyze the incoming packets. It is a useful command when trying to differentiate between the incoming types of trafc. Another useful command is #debug frame-relay packets to monitor the outgoing and incoming trafc, as shown in Example 17-36.
NOTE
Both commands generate a high volume of output and should only be used in cases where the overall use on the router is lower than usual. Use 7206-frame#show processes cpu to ensure that the CPU utilization for ve seconds, one minute, and ve minutes is low.
Example 17-36 Debugging the Frame Relay Packets

7206-frame#debug frame-relay packet Sep 1 08:32:41 PDT: Serial4/2:0.72(o): dlci 72(0x1081), pkt type 0x800(IP), datagramsize 146 Outgoing (o) packet over serail4/2:0.72 subinterface, using DLCI=72, packet type IP, datagramsize 146 Sep 1 08:32:41 PDT: Serial4/0:0.76(o): dlci 76(0x10C1), NLPID 0x3CC(IP), datagramsize 48 Sep 1 08:32:41 PDT: Serial4/0:0.97(o): dlci 97(0x1811), pkt type 0x800(IP), datagramsize 68 Sep 1 08:32:41 PDT: Serial4/0:0.86(o): dlci 86(0x1461), pkt type 0x800(IP), datagramsize 272 Sep 1 08:32:41 PDT: Serial4/0:0(i): dlci 53(0xC53), pkt type 0x2000, datagramsize 309 Incoming (i) traffic over DLCI=53, subinterface serial4/0:0, packet type CDP (0x2000), datagramsize 309 Sep 1 08:32:41 PDT: Serial4/0:0.97(o): dlci 97(0x1811), pkt type 0x800(IP), datagramsize 68 Sep 1 08:32:41 PDT: Serial3/0:0(i): dlci 30(0x4E3), pkt type 0x800, datagramsize 52 Sep 1 08:32:41 PDT: Serial3/0:0.30(o): dlci 30(0x4E1), pkt type 0x800(IP), datagramsize 52 Sep 1 08:32:41 PDT: Serial4/2:0.72(o): dlci 72(0x1081), pkt type 0x800(IP), datagramsize 154 Sep 1 08:32:42 PDT: Serial4/0:0.97(o): dlci 97(0x1811), pkt type 0x800(IP), datagramsize 60
continues
532
Example 17-36 Debugging the Frame Relay Packets (Continued)

Sep Sep Sep Sep Sep 1 08:32:42 PDT: Serial4/0:0.202(o): dlci 202(0x30A1), pkt type 0x800(IP), datagramsize 48 1 08:32:42 PDT: Serial4/0:0.47(o): dlci 47(0x8F1), pkt type 0x800(IP), datagramsize 1504 1 08:32:42 PDT: Serial4/0:0.97(o): dlci 97(0x1811), pkt type 0x800(IP), datagramsize 68 1 08:32:42 PDT: Serial4/2:0.72(o): dlci 72(0x1081), pkt type 0x800(IP), datagramsize 140 1 08:32:42 PDT: Serial3/1:0(i): dlci 118(0x1C61), pkt encaps 0x0300 0x8000 0x0000 0x2000(CDP), datagramsize 316
Other messages you can see from this output include the following:
0x308Signaling message, valid with DLCI = 0 (AnnexD) 0x309LMI message of Consortiums DLCI = 1023 0x3CC IP, 0x0800Internet Protocol (IP) in a 10-Mbps network 0x201IP in a 3-Mbps network 0x0806IP Address Resolution Protocol (ARP) 0x0808Frame Relay ARP 0x8035Reverse Address Resolution Protocol (RARP) 0x809bApple EtherTalk 0x80f3AppleTalk ARP 0x8038Spanning tree 0x8137Internetwork Packet Exchange (IPX) 0x200CDP 0x9000Loopback packet 0x1A58IPX 0xFEFEConnectionless Network Service (CLNS) 0xEFEFIntermediate System-to-Intermediate System (IS-IS) 0x1998Uncompressed Transmission Control Protocol (TCP) (header compression) 0x1999Compressed TCP (header compression) 0x6558Bridge packets
The Ethernet-type codes are the following:
If the encapsulation is HDLC, the possible packet codes are the following:
Another end-to-end troubleshooting command is #show frame-relay map. In point-tomultipoint designs, it is a useful tool to see the end-to-end settings and to check the
533
functionality. The Frame Relay mapping information is shown in Example 17-37 and is explained in Table 17-8.
Example 17-37 End-to-End Settings of DLCI 37
1602-frame# show frame-relay map <output omitted> Serial1.37 (up): point-to-point dlci, dlci 37(0x25,0x850), broadcast, IETF status defined, active 1602-frame# <output omitted> ! Or 1602-frame# show frame-relay map <output omitted> Serial 1 is up: ip 121.118.117.111 dlci 37 (0xB1,0x2C10), static, broadcast, CISCO TCP/IP Header Compression (inherited), passive (inherited) <output omitted> ! Or 7206-frame#show frame-relay map Serial3/1:0.120 (down): point-to-point dlci, dlci 120(0x78,0x1C80), broadcast status deleted Serial3/1:0.112 (up): point-to-point dlci, dlci 112(0x70,0x1C00), broadcast, BW = 56000 status defined, active Serial3/1:0.17 (up): point-to-point dlci, dlci 17(0x11,0x410), broadcast, BW = 128000 status defined, active Serial3/1:0.121 (up): point-to-point dlci, dlci 121(0x79,0x1C90), broadcast, BW = 56000 status defined, active Serial3/1:0.114 (up): point-to-point dlci, dlci 114(0x72,0x1C20), broadcast, BW = 56000 status defined, active
Table 17-8
Output from the show frame-relay map Command (The Lines Can Vary) Output Serial 1 up; Serial3/1:0.112 (up) ip 121.118.117.111 point-to-point dlci dlci 112(0x70,0x1C00) Description Identies a Frame Relay interface (subinterface) and its status (up or down). Destination IP address. Shows if this design is point-to-point. DLCI that identies the logical connection, which reaches this interface. This line displays three values: its decimal value (122), the hexadecimal value (0x70), and its value as it appears on the wire (0x1C00). continues
534
Table 17-8
Output from the show frame-relay map Command (The Lines Can Vary) (Continued) Output Static/dynamic Cisco/IETF Broadcast status deleted/status denedactive BW = 128000 TCP/IP Header Compression (inherited), passive (inherited) Description Indicates whether this is a static or dynamic entry. Indicates the encapsulation type for this entry. Indicates if it is broadcast/non-broadcast. If the interface is down, it reports a status of deleted. If not, it is dened and active. Denes the bandwidth dened for this map. Indicates whether the TCP/IP header compression characteristics were inherited from the interface or were explicitly congured for the IP map.
Frame Relay Shaping Problems

The trafc shaping feature of Frame Relay is a derivative from the nature of the technology. It is related to the classes of service dened for different types of trafc (see Chapter 16 for more details). If trafc shaping is not congured as part of the initial conguration settings (see the next chapter), they are reported accordingly by the IOS. As previously mentioned, the #show frame-relay pvc DLCI-number, reports if trafc shaping is on and what the status is of this particular PVC. For convenience, the trafc shaping part of the output is described in Table 17-9.
Table 17-9 Lines of Output and Descriptions of Trafc Shaping Parameters (This Section Appears if the Trafc Shaping Map Class Is Applied to This PVC) Output Cir Bc Be Limit Interval Description Current CIR, in bits per second. Current committed burst size, in bits. Current excess burst size, in bits. Maximum number of bytes transmitted per internal interval (excess plus sustained). Interval used internally (can be smaller than the interval derived from Bc/CIR; this occurs when the router determines that trafc ow is more stable with a smaller congured interval). Minimum CIR for the PVC. Number of bytes that are sustained per internal interval. Indicates if the adaptive shaping is ON. Frame Relay has BECN adaptation congured.
Mincir Byte increment Adaptive shaping none BECN response
535
Table 17-9
Lines of Output and Descriptions of Trafc Shaping Parameters (This Section Appears if the Trafc Shaping Map Class Is Applied to This PVC) (Continued) Output Pkts Bytes Pkts delayed Bytes delayed Shaping Trafc shaping drops Queuing strategy Output queue 0/40, 264 drop, 130549 dequeued Description Number of packets associated with this PVC that went through the trafc shaping system. Number of bytes associated with this PVC that went through the trafc shaping system. Number of packets associated with this PVC that were delayed by the trafc shaping system. Number of bytes associated with this PVC that were delayed by the trafc shaping system. Shaping is active for all PVCs that are fragmenting data; otherwise, shaping is active if the trafc being sent exceeds the CIR for this circuit. Number of packets dropped by the trafc shaping process. The queuing strategies can be FIFO, weighted fair, priority queuing, none, or custom. The size of the output queue number/maximum slots and number of drops. Number of dequeued packets.
You must know the use of BECNs and forward explicit congestion notications (FECNs) and their interaction with the Frame Relay switch because a growing number of delays or drops can severely affect performance.
User and Network Reactions to FECNs

The router compares the number of frames in which the FECN bit is set to 1, to the number of frames in which the FECN bit is set to 0 during Tc. If during this period, the number of BECN = 1 > = BECN = 0, the router reduces the throughput to 0.875 of its previous value. Conversely, if the number of frames with BECN = 1 < the number of frames with BECN = 0, the router increases the transmission by 1/16 of its throughput, performing slow start operations. Tc is set to four times the end-to-end transit delay. The network switch and afliated software constantly monitors the size of each queue, based on the regeneration cycle. This cycle begins when a queue on an outgoing port goes from idle to busy, and the average queue is computed during the measurement period. When the size exceeds a predened threshold, the circuit is considered in a state of incipient congestion. At this time, the FECN is set to 1 and remains in this state until the average value is below the threshold. ANSI T1.618 denes an algorithm to compute the average queue length (refer to the ANSI T1.618 standard for more details).
536
User and Network Reactions to BECNs

If the user receives n consecutive frames with BECN = 1, the trafc from the user is reduced by a step below the current offered rate. This step count (S) is reduced by 0.675 times the throughput, then 0.5 times the throughput, and nally, 0.25 times the throughput. Likewise, trafc can build up after receiving n/2 consecutive frames with BECN = 0, and the rate is then increased by a factor of 0.125 times throughput. The network applies ow control before the trafc becomes a factor and, therefore, it sets BECN = 1 preemptively.
NOTE
The router knows that the data owing in its direction is experiencing congestion. It cannot control this process, but it can inuence it by delaying the acknowledgments. This can delay the ow of incoming data.
You must pay attention to three signicant factors when analyzing the possible trafc shaping issues:
The ratio between the total number of output packets and out bytes to packets delayed and bytes delayed. The higher the ratio, the better. Ratios under 2:1 should be investigated. The number of dropped packets should also be analyzed. Remember that DE = 1 indicates eligibility and does not mean a mandatory drop, even in CIR =0 services. Two lines in the beginning of the output that are indicators of line issues are as follows:
dropped pkts Queuing strategy: FIFO Output queue 8/40, ...drop, ...dequeued
Buffer misses and other software problems, especially when implementing voice, compression, and multicast can cause problems. The wrong multicast conguration, for example, can shut the interfaces down and have nothing to do with any kind of line or end-to-end Frame Relay problems.
The recommended action list to overcome the performance issues because of trafc shaping includes the following:
Work with the LEC to resolve the problem. Reduce broadcast trafc. Implement priority queuing. Adjust the hold queues and buffered sizes. Use a protocol analyzer to check if any of your devices are generating specic trafc. Check for buffer types and sizes to trim their number.
537
Troubleshooting Compression Over Frame Relay

Before starting to troubleshoot compression, it is useful to follow some preliminary tips (more detailed information about compression is provided in Chapter 16). Using #show hardware or #show version allows you to check what type of compression is available in the router. A Cisco router enables compression in several ways, depending on the product:
If the router contains a compression service adapter (CSA), compression is performed in the CSA hardware (hardware compression). If a CSA is not available, compression is performed in the software installed on the VIP2 card (distributed compression). If a VIP2 card is not available, compression is performed in the routers main processor (software compression).
If hardware compression is available, it is identied in the output in Example 17-38.

Example 17-38 How to Check What Kind of Compression Is Available
3640-frame#show version Cisco Internetwork Operating System Software IOS (tm) 7200 Software (C7200-IS-M), Version 12.2(1), RELEASE SOFTWARE (fc2) Copyright 1986-2001 by cisco Systems, Inc. Compiled Fri 27-Apr-01 19:23 by cmong Image text-base: 0x60008960, data-base: 0x6131C000 <output omitted> Last reset from power-on Bridging software. X.25 software, Version 3.0.0. Primary Rate ISDN software, Version 1.1. 2 FastEthernet/IEEE 802.3 interface(s) 6 Serial network interface(s) 8 Channelized T1/PRI port(s) ! This line shows that the router 7206 has two ! compression service adapters installed. 2 Compression service adapter(s) 125K bytes of non-volatile configuration memory. 4096K bytes of packet SRAM memory.
Hardware compression starts in the core router, after the router is rebooted or is turned on. Among the rst messages to be displayed (if you are using a console connection) is Compressor is up and Decompressor is up. Subsequently, a message is displayed that indicates that the CSA module or data compression advanced integration module (AIM) has started successfully (see www.cisco.com/univercd/cc/td/doc/pcat/3660__p1.htm). This option is not always available because the router cannot be rebooted every time to see if the compression module is starting. However, you can check the router conguration by using the command in Example 17-39.
538
Example 17-39 Diagnostic Information for Compression Engine, Installed on Port 2

7206-frame#show diag 2 Slot 2: Compression engine 3M Port adapter ! This next line usually shows that the module functions properly. Port adapter is analyzed Port adapter insertion time 3w1d ago EEPROM contents at hardware discovery: Hardware revision 1.0 Board revision A0 Serial number 6942323 Part number 73-1868-02 Test history 0x0 RMA number 00-00-00 EEPROM format version 1 EEPROM contents (hex): 0x20: 01 18 01 00 00 69 EE 73 49 07 4C 02 00 00 00 00 0x30: 50 00 00 00 99 03 12 00 FF FF FF FF FF FF FF FF
Before choosing any kind of compression for implementation, it is good to know which one is most appropriate for your particular core router. Because of various reasons (including IOS incompatibility) even if the router conguration is correct, compression might not work properly. As a result, instead of increasing performance, it might degrade it. It is recommended to take a look at the core routers output by using the command 7206frame#show compress. The number of resyncs or resets usually shows a condition, where the router tries to synchronize the content of the vocabularies on both sides. Initially, this process is very intensive and generates a lot of trafc. However, if the trend of incrementing the counter is almost linear, it is not recommended to use this type of compression. When you are about to congure compression, it is best to shut down the interfaces or subinterfaces rst. Otherwise, you see a signicant increase in response time, or possibly no end-to-end connection. Shutting down the interface or subinterface prior to adding or changing compression techniques is not required, but it ensures it is reset for the new data structures, and the two vocabularies start their synchronization from the beginning. Always remember the scalability factor when applying compression. Cisco proprietary packet-to-packet compression takes about 0.5 percent utilization per DCLI, and FRF9 stac software compression shows 6 percent peak utilization per DLCI in short-term reports. The hardware compression module CSA version 2, provides compression for 256 users, and the router and IOS can support more than one module. The test results over some commonly used le types are provided in Figure 17-10. Dont forget that compression is a trafc-dependant function. If the prevailing type of user trafc is pre-compressed or redundant (IOS images, for example), you cannot expect a high compression ratio from the implementation.
539
Figure 17-10 Test Results of Frame Relay Compression

300 250 200
Time [s] 150
100 50 0 mix bmp exe jpg mp3 doc

No Compression Software Compression Packet-to-Packet Hardware Compression
The router reports compression in different ways. As shown earlier in Table 17-8, one of the options for header compression is to use the 7206-frame#show frame-relay map command, which displays the resulting compression and encapsulation characteristics; the IP map has inherited passive TCP/IP header compression. Another option is to use the command 7206-frame#sh frame-relay ip tcp header-compression. The output is displayed in Example 17-40 and an explanation is provided in Table 17-10.
Example 17-40 The Status of Header Compression for DLCI = 37
7206-frame# show frame-relay ip tcp header-compression DLCI 37 Link/Destination info: ip 10.70.194.209 Interface Serial1: Rcvd: 40 total, 36 compressed, 0 errors 0 dropped, 0 buffer copies, 0 buffer failures Sent: 0 total, 0 compressed 0 bytes saved, 0 bytes sent Connect: 16 rx slots, 16 tx slots, 0 long searches, 0 misses, 0% hit ratio Five minute miss rate 0 misses/sec, 0 max misses/sec
Table 17-10 Header Compression Field Descriptions from the #show frame-relay ip tcp header-compression Command Output Rcvd Total compressed Errors Description Table of details concerning received packets. Sum of compressed and uncompressed packets received. Number of compressed packets received. Number of errors caused by errors in the header elds (version, total length, or IP checksum). continues
540
Table 17-10 Header Compression Field Descriptions from the #show frame-relay ip tcp header-compression Command (Continued) Output dropped buffer copies buffer failures Sent Total compressed bytes saved bytes sent Connect rx slots, tx slots Description Number of packets discarded; seen only after line errors. Number of times a new buffer was needed for the uncompressed packet. Number of times a new buffer was needed but was not obtained. Table of details concerning sent packets. Sum of compressed and uncompressed packets sent. Number of compressed packets sent. Number of bytes reduced because of the compression. Actual number of bytes transmitted. Table of details about the connections. Number of states allowed over one TCP connection. A state is recognized by a source address, a destination address, and an IP header length. Number of times the connection ID in the incoming packet was not the same as the previous one processed. Number of times a matching entry was not found within the connection table and a new entry had to be entered. Percentage of times a matching entry was found in the compression tables and the header was compressed. Miss rate computed over the most recent ve minutes and the maximum per-second miss rate during that period.
long searches Misses hit ratio Five minute miss rate
For payload compression, the show compress command provides the sample output in Example 17-41.
Example 17-41 Compression Statistics per DLCI 37
3640-frame#show compress <output omitted> Serial4/1:0 - DLCI: 37 Software compression enabled ! The total amount of data to be transmitted before compression uncompressed bytes xmt/rcv 1962361561/132244042 compressed bytes xmt/rcv 498585954/87588960 1 min avg ratio xmt/rcv 0.705/0.705 5 min avg ratio xmt/rcv 0.715/0.718 10 min avg ratio xmt/rcv 0.715/0.722 no bufs xmt 0 no bufs rcv 87
541
Example 17-41 Compression Statistics per DLCI 37 (Continued)

resyncs 448 Additional Stacker Stats: ! The total amount of data to be transmitted after applying compression Transmit bytes: Uncompressed = 45109432 Compressed = 348114663 Received bytes: Compressed = 76914754 Uncompressed = 0 <output omitted>
In Table 17-11, some of the descriptions of the line-by-line output are shown from the previous command.
Table 17-11 Payload Compression Output from #show compress and Field Descriptions Output Serial4/1:0 - DLCI: 37 Software compression enabled Uncompressed bytes xmt/rcv 1962361561/132244042 Compressed bytes xmt/rcv 498585954/87588960 1 min avg ratio xmt/rcv 0.000/0.000 5 min avg ratio xmt/rcv 0.001/0.001 10 min avg ratio xmt/rcv 0.002/0.001 no bufs xmt 0 no bufs rcv 0 Description Identies a Frame Relay subinterface for software compression. Type of compression. Byte count for sent and received uncompressed data. Byte count for sent and received compressed data. Ratio of the data throughput gained or lost in the compression routine. Any number less than one indicates that the compression is actually slowing down data throughput. It does not reect how compressed the data is. Indicates the number of times the compression routine was not able to allocate a transmit or receive buffer to compress or decompress a packet. Number of times the compression routine detected that the dictionaries were out of sync and restarted building a dictionary. Line errors are a common cause of restarts. The uncompressed value is the amount of data not able to be compressed, which was sent in uncompressed format. The compressed value is the byte-count of the data after it was compressed. The sum of these two values represents the actual number of bytes transmitted on the interface, minus the second layer encapsulation overhead. The compressed value is the byte-count of the compressed data received. The uncompressed value is the amount of data that is received in uncompressed format. The sum of these two values represents the actual byte count received on the interface, minus the Layer 2 encapsulation overhead.
resyncs 118
Additional Stacker Stats: Transmit bytes: Uncompressed = 45109432 Compressed = 348114663 Received bytes: Compressed = 76914754 Uncompressed = 0
542
To interpret the transmit output and compression ratio for software compression, there are some simple rules for the calculation. Based on the information from Example 17-41 and Table 17-11, you can perform the following calculations:
The total amount of data to be transmitted before you apply the compression routine, based on the following lines, is as follows: 1962361561 + 45109432 = 2007470993:
uncompressed bytes xmt/rcv 1962361561/132244042 Transmit bytes: Uncompressed = 45109432 Compressed = 348114663
The total amount of data to be transmitted after you apply the compression based on the following line is 45109432 + 348114663 = 393224095:
Transmit bytes: Uncompressed = 45109432 Compressed = 348114663
Therefore, the overall data compression ratio is as follows: 2007470993 / 393224095 = 5.1:1
NOTE
The listed numbers do not represent the real compression ratios, but rather they represent a snapshot gure with redundant trafc types. You should not expect compression ratios higher than 2:1 over a long period of usage, with a variety of trafc types.
The precise calculations of the total amount of output in bytes, can be performed by using the results from the #show compress command and by using the number of outgoing/ incoming packets from the command #show interfaces serial 1:
1 Calculate the total number of transmit bytes from the output of the #show compress
command.
2 Multiply the number of outgoing packets from the output of the #show interfaces
serial 1 command by 6. (For a 2-byte DLCI frame, the overhead is a 2-byte Flag, a 2-byte Address, and a 2-byte FCS).
3 Add the two results from the previous steps and the resulting number should match
the number of total bytes of output in the serial interface from the output of #show interfaces serial 1. In the case of hardware compression, the output is similar with one important exception. The compression ratio is calculated by the compression engine, and some of the calculations are not necessary. Example 17-42 shows the hardware compression statistics for DLCI 64.
543
Example 17-42 Hardware Compression Statistics for DLCI 62

7206-frame#show compress detail-ccp Serial4/2:0 - DLCI: 64 Hardware compression enabled CSA in slot 2 in use uncompressed bytes xmt/rcv 316009631/178259458 compressed bytes xmt/rcv 185779090/236163882 Compressed bytes sent: 185779090 bytes 1 Kbits/sec ratio: 1.700 Compressed bytes recv: 236163882 bytes 1 Kbits/sec ratio: 0.754 ! Resync represents the number of times the compression routine detected ! that the dictionaries were out of sync and restarted building a dictionary. ! Line errors are a common cause of restarts. resyncs 7509 last clearing of counters: 1211408 seconds Additional Stacker Stats: Transmit bytes: Uncompressed = 88971017 Compressed = 92164757 Received bytes: Compressed = 52030283 Uncompressed = 177870511
NOTE
The compression ratio is lower than in software compression. If you are using the same type of compression (stacker) in both cases, you will notice that the compression ratios differ signicantly. Compare the resyncs in both cases. It is obvious that the hardware compression experiences issues and that the constant resync of vocabularies causes poor performance.
Unlike the previously explained precise calculations of the compression parameters, for troubleshooting purposes it is sometimes useful to see if the compression works at all. Some preliminary indicators follow:
Non-zero values from the #show compress command
A difference between the ve minute rate in the WAN (serial) and local-area network (LAN) (Ethernet) interfaces, as shown in the following example: 1602-frame#show interfaces serial 1 | include 5 min
5 minute input rate 8000 bits/sec, 9 packets/sec 5 minute output rate 2000 bits/sec, 4 packets/sec 1602-frame#show interfaces ethernet 0 | include 5 min 5 minute input rate 12000 bits/sec, 2 packets/sec 5 minute output rate 0 bits/sec, 0 packets/sec
Non-linear increments of the round-trip time (RTT) of the output (using the ping 1602-frame packet_size command) when linearly incrementing the size of the ping packets
For practical purposes, it is convenient to imagine that the compressor-decompressor engine is located between the WAN and LAN interfaces. As soon as the incoming packet hits the WAN interface (serial interface), it gets decompressed and switched to the LAN interface (Ethernet interface) and vice versa. Every outgoing Ethernet packet gets
544
compressed, sent to the serial interface, sent compressed over the serial link, and decompressed by the other partys decompressor.
End Notes
1
Cough, L. Digital and Analog Communications Systems. Prentice Hall, 1997.
Summary
For every troubleshooting process in this chapter, it is recommended that you start with the maximum information about the existing service. The minimum amount of information that you need to have before even starting to troubleshoot includes the characteristics of the service: point-to-point or point-to-multipoint design, routing or bridging, remote and local DLCIs, access rate (link rate), CIR value, IP addressing scheme, and so on. The chapter follows the recommended layer-by-layer troubleshooting process, including physical layer and data link layer problems, performance problems, PVC and LMI-related troubleshooting, and troubleshooting of trafc shaping and compression over Frame Relay.
Review Questions
1 What are the signals on the physical layer provided by DTE? 2 What are the two available options for 56-kbps congurations for Cisco routers? 3 In the command service-module 56k network-type dds, what is DDS and what are
the data rates provided by DDS?

4 Serial 1 is congured with the command service-module t1 timeslots 1-2. What is
the congured bandwidth on Serial 1?

5 Name the WIC T1 Pinouts (8 pin RJ48S). 6 What is the command to loopback your equipment? 7 Name two checkpoints for a failing CSU. 8 In the show frame-relay map IOS command, if the DLCI is dened and active, what
does this mean?

9 What happens with the incoming DLCI in the switch? 10 How do you know if the DLCI is active but not congured in the router?
Review Questions
545
11 Under what conditions does the properly congured LMI in a Cisco router not send
packets over the DLCI?

12 Which LMI message reports the PVC status for each PVC congured on the
interface?
13 What is the order of the Cisco LMI autosense full status enquiry message? 14 How are Num Status Enq. Sent, Num Status msgs Rcvd, and Num Status
Timeouts related in erroneous conditions?

15 When debugging the serial interface, what does the message illegal serial line type
xxx mean?
CHAPTER
18
Frame Relay Troubleshooting Scenarios

This chapter includes some common, real-life scenarios that are designed to demonstrate the Frame Relay troubleshooting techniques covered in Chapter 17, Frame Relay Troubleshooting. Another objective of this chapter is to give troubleshooting engineers some practical recommendations that deal with Frame Relay troubleshooting issues and to increase their practical knowledge about typical Frame Relay problems. The greatest advantage of enterprise troubleshooting is that you always see both sides of the connection, and the necessary information about the development of the service is available to you. It is important that you have access to the proper data to fully understand the environment that you are troubleshooting. This includes the provisioning information, the requirements for the design, the conguration solution, and nally, the expected baseline. It is also important to understand the use of different IOS commands and tools, because the screen outputs from some of the recommended commands may or may not provide the information you require. The scenarios provided in this chapter represent some of the most common Frame Relay issues that you might experience when working with different service providers, routers, and solutions. Five troubleshooting scenarios are provided in this chapter. Each scenario covers the most common troubleshooting issues that occur and how to pinpoint the exact causes of the problems. The topics covered in this chapter are as follows:
Scenario 1: New Install Issues Scenario 2: Mismatched DLCI Settings Scenario 3: Performance Issues from Flapping Lines and Trafc Shaping Issues Scenario 4: IP Multicast Issues in Frame Relay Scenario 5: Frame Relay Host Migration
548
Chapter 18: Frame Relay Troubleshooting Scenarios
NOTE
Most troubleshooting engineers recommend that you have two telnet sessions open for some of the more chatty IOS commands. The reason behind this is that you can force the router to crash if you dont know how much output to expect. One of the sessions is used with the #terminal monitor or (cong)#logging console command and the appropriate debug command. For the second telnet session, have the undebug all command ready in case use exceeds reasonable levels. The logging console command only logs to the console, so you must have a telnet session open or be directly connected to the console port. Logging to the console is more processor intensive than logging to the terminal because of the default slow speed of the console port. Another alternative is to send the log messages to a syslog server and then view them there without logging on the router at all.
Scenario 1: New Install Issues

To troubleshoot new install issues, you must clearly understand what stage of the installation process you are troubleshooting. The most common scenario is when the provisioning process is complete, and the conrmation of circuit installation is received from the service provider, which indicates that the termination device is installed in the minimum point of entry (MPOE), or the sometimes-called Demarcation Point (D-mark). Also as part of the scenario, the local loop is checked and the technician reports that the line is installed. The rst situation here is when you have an administratively down situation for interfaces. A user might have forgotten to not shut the interface (shutdown is the default condition for a new interface that has not been congured). However, this is a basic step that most engineers wont miss to unshut the interface. If the end users router conguration is correct, three typical indicators exist for new install issues:

NOTE
The line is down, the protocol is down. The line is up, the protocol is down. The line is up, the protocol is up, the router cannot pass data.
In explanations throughout this chapter, you see references to up and down states. When there are two references to these states (such as up, up), the rst is referring to the line status and the second is referring to the protocol layer status.
Example 18-1 shows the rst case. Example 18-2 shows the second case. Finally, Example 18-3 shows the third case. In the rst case, if the line to the MPOE is reported as operational, you might be dealing with internal wiring problems (IW in the local exchange carriers [LECs] terminology) or router cable problems. Review the information pertaining to these problems in Chapter 17.
549
Example 18-1
The Line Is Reported Down, the Protocol Layer Is Down

1602-frame#show ip interface brief Interface IP-Address Ethernet0 10.84.14.169 Serial0 unassigned Serial0.37 10.84.14.169 1602-frame# OK? YES YES YES Method NVRAM NVRAM unset Status up down down Protocol up down down
Example 18-2
The Line Is Reported Up, the Protocol Layer Is Down

1602-frame#show ip interface brief Interface IP-Address Ethernet0 10.84.14.169 Serial0 unassigned Serial0.62 10.84.14.169 1602-frame# OK? YES YES YES Method NVRAM NVRAM unset Status up up down Protocol up down down
Example 18-3
The Line Is Reported Up, the Protocol Layer Is Up, but the Router Cannot Pass Data
1602-frame#show ip interface brief Interface IP-Address Ethernet0 10.84.14.169 Serial0 unassigned Serial0.62 10.84.14.169 1602-frame# OK? YES YES YES Method NVRAM NVRAM unset Status up up up Protocol up up up
A more interesting case for troubleshooting purposes is the second case, where the line is reported up but the protocol layer is reported down. An initial checklist of possible issues include (following the described methodology in Chapter 16, Basic and Advanced Frame Relay Congurations):
Conguration issues: Local router conguration errors Core router conguration errors Existing loopback from the core side
Service provider issues: The permanent virtual circuit (PVC) is not mapped The switch is in maintenance mode The access rate requirements do not match The Local Management Interface (LMI) type does not match
550
NOTE
For the purposes of the explanation, both sides are congured to use data-link connection identier (DLCI) = 62; however, the number does not have to be the same on both ends because DLCI only has a local signicance.
Starting with the conguration issues, when analyzing both sides, you see the following. The remote users router is congured correctly for 56 kbps, it is dened as Frame Relay Internet Engineering Task Force (IETF) encapsulation, and it is set up for LMI type AnnexD. It also reports the output listed in Example 18-2 with line up and protocol down. The remote users router is congured as shown in Example 18-4.
Example 18-4
Fragment of the Remote User Conguration

1602-frame#show running-config <output omitted> interface Serial0 no ip address ! The Frame Relay encapsulation is IETF: encapsulation frame-relay IETF service-module 56k clock source line service-module 56k network-type dds ! The LMI type is ANSI: frame-relay lmi-type ansi ! interface Serial0.62 point-to-point bandwidth 56 ip unnumbered Ethernet0 ! The encapsulation of DLCI 62 is IETF because the Serial0 is IETF frame-relay interface-dlci 62 <output omitted>
The core router reports the output shown in Example 18-5.

Example 18-5
Core Router Output

3640-frame#show ip interface brief Interface IP-Address OK? Method Status Protocol FastEthernet0/0 10.84.5.111 YES manual up up FastEthernet1/0 unassigned YES NVRAM up up Serial3/2:0.65 unassigned YES unset deleted down Serial3/2:0.66 10.84.5.111 YES unset up up <output omitted> Serial3/3:0.59 10.84.5.111 YES unset up up Serial3/3:0.60 10.84.5.111 YES unset down down Serial3/3:0.61 10.84.5.111 YES unset up up Serial3/3:0.62 10.84.5.111 YES unset up up ! The connection serial3/3:0.62 is the one that requires troubleshooting: Serial3/3:0.70 unassigned YES unset deleted down Serial3/3:0.138 10.84.5.111 YES unset up up Serial4/0:0 unassigned YES NVRAM up up Serial4/0:0.17 unassigned YES unset deleted down
551
The output in Example 18-6 shows the status of DLCI = 62 on the core router.
Example 18-6
From the Core Router Perspective, DLCI 62 Is Reported Up, Up

3640-frame#show interfaces serial 3/3:0.62 Serial3/3:0.62 is up, line protocol is up Hardware is Multichannel T1 Description: frame to 1602-frame: 10.84.14.169 Interface is unnumbered. Using address of FastEthernet0/0 (10.84.5.222) MTU 1500 bytes, BW 1536 Kbit, DLY 20000 usec, reliability 255/255, txload 6/255, rxload 1/255 Encapsulation FRAME-RELAY IETF 3640-frame#
The service from the core side is congured as point-to-point with unnumbered IP, as shown in Example 18-7.
Example 18-7
How to Check if the Conguration Is Correct

3640-frame#show running-config interface serial s3/3:0.62 ! The configuration of the serial interface matches the ! Encapsulation Frame Relay IETF. Building configuration... Current configuration: 236 bytes ! ! Matches the remote users router settings: interface Serial3/3:0.62 point-to-point description frame-relay service for 1602-frame: 10.84.14.169 ! The bandwidth matches: bandwidth 56 ip unnumbered FastEthernet0/0 no ip route-cache ! DLCI IETF matches the local switch: frame-relay interface-dlci 62 IETF end 3640-frame#
Obviously, the core side is connected to the local switch and the User-Network Interface (UNI) is functioning correctly.
NOTE
The way the loopback is set up can affect the way the router reports it. The core router can report the line and protocol up for remote loopback, or if you set a local loopback, it can report looped instead of up. However, if the service providers test technician sets loopback on the interface, the core router does not indicate loopback and the switch must be checked.
552
Start with the remote users router to identify what it is reporting (see Example 18-8).
Example 18-8
Debugging the LMI

1602-frame#debug frame-relay lmi Frame Relay LMI debugging is on Displaying all Frame Relay LMI data 1602-frame# ! The DTE sends myseq 55. It does not receive anything from the switch. ! The DTE is down: 3d07h: Serial0(out): StEnq, myseq 55, yourseen 0, DTE down 3d07h: datagramstart = 0x2B9CD48, datagramsize = 14 ! The Frame Relay encapsulation is 0x00010308 (Cisco), (0xFCF10309 IETF): 3d07h: FR encap = 0x00010308 3d07h: 00 75 95 01 01 00 03 02 37 00 3d07h: ! The DTE sends myseq 56. It does not receive anything from the switch. ! The DTE is down: 3d07h: Serial0(out): StEnq, myseq 56, yourseen 0, DTE down 3d07h: datagramstart = 0x2B9CD48, datagramsize = 14 3d07h: FR encap = 0x00010308 3d07h: 00 75 95 01 01 00 03 02 38 00 3d07h: ! The DTE sends myseq 57. It does not receive anything from the switch. ! The DTE is down: 3d07h: Serial0(out): StEnq, myseq 57, yourseen 0, DTE down <output omitted>
Change the encapsulation to high-level data link control (HDLC) and try again (see Example 18-9).
Example 18-9
Debug of the Serial Interface, After Changing the Encapsulation to HDLC

1602-frame-frame# debug serial interface Serial network interface debugging is on 1602-frame# 3d07h: Serial0: attempting to restart 3d07h: QUICC_SERIAL(0): Reset from 0x200C8FE 3d07h: Serial0(out): StEnq, myseq 62, yourseen 0, DTE down 3d07h: Serial0(out): StEnq, myseq 63, yourseen 0, DTE down 3d07h: Serial0(out): StEnq, myseq 64, yourseen 0, DTE down ! Increase the number of errors; restart the interface: 3d07h: Serial0: attempting to restart 3d07h: QUICC_SERIAL(0): Reset from 0x200C8FE 3d07h: Serial0(out): StEnq, myseq 65, yourseen 0, DTE down 3d07h: Serial0(out): StEnq, myseq 66, yourseen 0, DTE down 3d07h: Serial0(out): StEnq, myseq 67, yourseen 0, DTE down ! Increase the number of errors; restart the interface: 3d07h: Serial0: attempting to restart 3d07h: QUICC_SERIAL(0): Reset from 0x200C8FE 3d07h: Serial0(out): StEnq, myseq 68, yourseen 0, DTE down 1602-frame#
553
Change the encapsulation back to Frame Relay because the report is the same. When working with the service provider, the technician explicitly denes the LMI type from none to ANSI to match the remote users router settings. As a result, the message in Example 18-10 on the screen shows the protocol coming back up.
Example 18-10 Changing the LMI Type to ANSI Brings the Protocol Layer to Up
1602-frame#show ip interface brief Interface IP-Address OK? Method Ethernet0 10.84.14.169 YES NVRAM Serial0 unassigned YES NVRAM Serial0.62 10.84.14.169 YES unset 1602-frame# ! The line protocol changed state to up: 3d07h: %LINEPROTO-5-UPDOWN: Line protocol on Interface 1602-frame# Status up up down Protocol up down down
Serial0, changed state to up
Consequently, the output in Example 18-11 is shown.

Example 18-11 Checking the Status of the Interfaces of a Remote Users Router
1602-frame#show ip interface brief Interface IP-Address Ethernet0 10.84.14.169 Serial0 unassigned Serial0.62 10.84.14.169 OK? YES YES YES Method NVRAM NVRAM unset Status up up up Protocol up up up
The last thing to do is to test the new service, as shown in Example 18-12.
Example 18-12 Check if the Service Is Functioning Properly and Check the LMI Reports
1602-frame#show interfaces <output omitted> Serial0 is up, line protocol is up Hardware is QUICC Serial (with onboard CSU/DSU) MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec, reliability 255/255, txload 1/255, rxload 1/255 Encapsulation FRAME-RELAY IETF, loopback not set Keepalive set (10 sec) LMI enq sent 28694, LMI stat recvd 20, LMI upd recvd 0, DTE LMI up LMI enq recvd 0, LMI stat sent 0, LMI upd sent 0 LMI DLCI 0 LMI type is ANSI Annex D frame relay DTE FR SVC disabled, LAPF state down Broadcast queue 0/64, broadcasts sent/dropped 5/0, interface broadcasts 1 Last input 00:00:00, output 00:00:00, output hang never Last clearing of show interfaces counters 3d07h Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0 Queuing strategy: weighted fair Output queue: 0/1000/64/0 (size/max total/threshold/drops)
continues
554
Example 18-12 Check if the Service Is Functioning Properly and Check the LMI Reports (Continued)
Conversations 0/23/256 (active/max active/max total) Reserved Conversations 0/0 (allocated/max allocated) 5 minute input rate 3000 bits/sec, 6 packets/sec 5 minute output rate 4000 bits/sec, 6 packets/sec 68159 packets input, 5690460 bytes, 0 no buffer Received 0 broadcasts, 0 runts, 0 giants, 0 throttles 2629 input errors, 0 CRC, 2615 frame, 0 overrun, 0 ignored, 14 abort ! These errors were displayed when the line was down. ! Now you can ignore them because they are not increasing; ! or you may want to clear the counters and monitor again. 29578 packets output, 497773 bytes, 0 underruns 0 output errors, 0 collisions, 9558 interface resets 0 output buffer failures, 0 output buffers swapped out 2 carrier transitions DCD=up DSR=up DTR=up RTS=up CTS=up Serial0.62 is up, line protocol is up Hardware is QUICC Serial (with onboard CSU/DSU) Interface is unnumbered. Using address of Ethernet0 (10.84.14.169) MTU 1500 bytes, BW 56 Kbit, DLY 20000 usec, reliability 255/255, txload 1/255, rxload 1/255 Encapsulation FRAME-RELAY IETF 1602-frame# 1602-frame#show frame-relay lmi LMI Statistics for interface Serial0 (Frame Relay DTE) LMI TYPE = ANSI Invalid Unnumbered info 0 Invalid Prot Disc 0 Invalid dummy Call Ref 0 Invalid Msg Type 0 Invalid Status Message 0 Invalid Lock Shift 0 Invalid Information ID 0 Invalid Report IE Len 0 Invalid Report Request 0 Invalid Keep IE Len 0 ! All invalid message counters are reporting 0s Num Status Enq. Sent 28699 Num Status msgs Rcvd 28699 Num Update Status Rcvd 0 Num Status Timeouts 0 1602-frame#
Next, run a ping test to check if the router can pass IP trafc (see Example 18-13).
Example 18-13 The Ping Test Shows that the Router Passes IP Trafc
3640-frame#ping 10.84.14.169 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.84.14.169, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 36/40/48 ms 3640-frame#ping Protocol [ip]:
555
Example 18-13 The Ping Test Shows that the Router Passes IP Trafc (Continued)
Target IP address: 10.84.14.169 Repeat count [5]: 50 Datagram size [100]: 1000 Timeout in seconds [2]: Extended commands [n]: Sweep range of sizes [n]: Type escape sequence to abort. Sending 50, 1000-byte ICMP Echos to 10.84.14.169, timeout is 2 seconds: !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
The third case occurs when the interfaces of the remote user report line up, protocol up, but the remote user cannot pass any trafc (ping, telnet, and so on) between the home network and the corporate network. This might be related to a variety of problems, including the following:
The router on the other end is not congured or not congured properly. The router network addressing scheme is incorrect. The routing protocol is not congured properly. The Frame Relay network is not mapped correctly.
The rst action to take in this case is to view both ends of the connection, focusing on the core router. Typically, the core router serial interface is up but the subinterfaces report down, as shown in Example 18-14.
Example 18-14 This Is How the Troubled Connection Serial 3/0:0.47 Looks from the Core Router Perspective
7206-frame#show interfaces serial 3/0:0.47 Serial3/0:0.47 is down, line protocol is down Hardware is Multichannel T1 Description: 1602-frame: 10.10.253.136/29 : 9833502 : 3814500206 Interface is unnumbered. Using address of Loopback2 (171.68.88.1) MTU 1500 bytes, BW 56 Kbit, DLY 20000 usec, reliability 255/255, txload 1/255, rxload 1/255 Encapsulation FRAME-RELAY 7206-frame#
If you check the interfaces from the viewpoint of the remote user, most probably it shows that the interface is up, up, and the subinterface shows up, up. Checking two endsthe remote side and the core sidepoints to a conclusion that the PVC is probably not mapped by the service provider or that the remote user is looped back instead of mapping the PVC to the other end. If everything on the physical and data link layers seems to function correctly, it makes sense to move on and look for another set of possible issues. The most typical ones are routed protocol-related mismatches. In the case of IP, there are generally three groups:
556
Duplicate IP addressesIP duplication can take place between subnets and within subnets. Large, fast-growing IP spaces can create this situation, and poor IP management, oversight, and merging networks. In the case of duplicates within a subnet, IOS usually provides a warning before assigning the IP address, when the interface is Ethernet or FastEthernet. In wide-area network (WAN) links, there is no warning (possibly because of bridge congurations). The result of the duplicate IP is either sporadic connectivity or total loss of IP connectivity. One possible action is to check the Domain Name System (DNS) server entries to ensure that there are no duplicate IP addresses (Cisco uses a web-based utility to provide access to the DNS tree). Another solution is to use #show cdp neighbor detail (see Chapter 4, Troubleshooting Approaches, Models, and Tools). Duplicate subnetsIn some cases, when you try to merge two or more subnets or to assign a larger subnet to a remote user, it might result in overlapping or duplicate subnets. This can cause loss of connectivity or intermittent connectivity. Again, the #show cdp neighbor detail, #show ip interface brief, and #show ip route commands, and available DNS utilities, are the recommended tools. Miscongured masksThe mask denes what part of the IP address is a network address, and what part is designated for host addresses. The mask plays a signicant role in all routing protocols and can be a source of different issues. It is recommended that the troubleshooting of this situation be performed in the context of the chosen routing protocol, such as Open Shortest Path First (OSPF) or Border Gateway Protocol (BGP).
For possible routing issues and overhead, see Chapter 16. DLCI and PVC issues are discussed in the following scenario.

The importance of this scenario is based on the fact that the DLCI is a super-identier in Frame Relay. Recall the extended coverage of DLCI formats in Chapter 14, Frame Relay Technology Background and the numerous standards and committees that dene the rules and scope of DLCI usage. Additionally, rules exist for the number of DLCIs that are congurable on any particular interface or router, and that are restricted by the amount of available memory. In this section, one of the simplest situations is coveredwhen the DLCI does not match the value provisioned by the local service provider. Use the #show frame-relay pvc command to clarify if you have the correct DLCI, as shown in Example 18-15.
557
Example 18-15 Output from the Core Router from the show frame-relay pvc Command
7206-frame#show frame-relay pvc <output omitted> DLCI = 54, DLCI USAGE = LOCAL, PVC STATUS = DELETED, INTERFACE = Serial3/0:0.54 input pkts 0 output pkts 0 in bytes 0 out bytes 0 dropped pkts 0 in FECN pkts 0 in BECN pkts 0 out FECN pkts 0 out BECN pkts 0 in DE pkts 0 out DE pkts 0 out bcast pkts 0 out bcast bytes 0 pvc create time 3w3d, last time pvc status changed 3w3d DLCI = 64, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial3/0:0.64 input pkts 41898 output pkts 39200 in bytes 9673029 out bytes 17274236 dropped pkts 0 in FECN pkts 0 in BECN pkts 0 out FECN pkts 0 out BECN pkts 0 in DE pkts 41898 out DE pkts 0 out bcast pkts 10818 out bcast bytes 3245400 pvc create time 3w3d, last time pvc status changed 1d17h DLCI = 67, DLCI USAGE = UNUSED, PVC STATUS = INACTIVE, INTERFACE = Serial3/0:0.67 input pkts 0 output pkts 0 in bytes 0 out bytes 0 dropped pkts 0 in FECN pkts 0 in BECN pkts 0 out FECN pkts 0 out BECN pkts 0 in DE pkts 0 out DE pkts 0 out bcast pkts 0 out bcast bytes 0 switched pkts 0 Detailed packet drop counters: no out intf 0 out intf down 0 no out PVC 0 in PVC down 0 out PVC down 0 pkt too big 0 shaping Q full 0 pkt above DE 0 policing drop 0 pvc create time 3w3d, last time pvc status changed 3w3d <output omitted>
From this command, you learn details of the DLCI and the PVC status:
DLCIThe DLCI number for this PVC. The usage of the DLCI includes the following: DLCI USAGE = LOCALLocally congured in the data terminal equipment (DTE). DLCI USAGE = UNUSEDIf the PVC status is inactive, the DLCI is not linked to an interface. DLCI USAGE = SWITCHEDThe router is congured as a Frame Relay switch.
PVC STATUSReports the status of the PVC, which can be the following: PVC STATUS = ACTIVEDLCI is active and up. PVC STATUS = INACTIVEDLCI is not active, but LMI is reporting it up.
558
PVC STATUS = DELETEDDLCI is not listed in the periodic LMI exchange.
INTERFACE = Serial3/0:0.67, or INTERFACE = Serial3/0:0.54, or INTERFACE = Serial3/0:0.64Shows which interface, or in this case subinterface, uses this DLCI.
As shown in Example 18-15, DLCI = 64 is active and appears to be fully functional. If the router (on either end of the PVC) reports differently (inactive or deleted) and the cause is because of wrong DLCI settings that are provided by the service provider, an option for resolution is contacting the provider for the correct DLCI. However, Cisco IOS provides features that help recognize the issue. The remote users router is used for this example. First and foremost, check the conguration shown in Example 18-16 to make sure that the DLCI matches the one provisioned by your provider, and that it is congured correctly.
Example 18-16 Verifying the DLCI Settings in the Router Conguration
1602-frame# show running-config <output omitted> interface Serial0 no ip address encapsulation frame-relay IETF no ip mroute-cache service-module 56k clock source line service-module 56k network-type dds frame-relay lmi-type ansi ! interface Serial0.16 point-to-point bandwidth 56 ip unnumbered Ethernet0 no ip mroute-cache frame-relay interface-dlci 17 IETF ! <output omitted>
Next, check the status of the remote users interfaces with the show ip interfaces brief command, as shown in Example 18-17.
Example 18-17 Verifying the Status of the Interfaces
1602-frame#show ip interfaces brief Interface IP-Address OK? Method Status Ethernet0 10.84.14.169 YES NVRAM up Serial0 unassigned YES NVRAM up ! Focus on the next line. What is wrong with serial0.16? Serial0.16 10.84.14.169 YES unset down 1602-frame# Protocol up up down
559
The serial line reports line up, protocol up, but the subinterface is line down, protocol down. To determine what is wrong with the subinterface, identify what the LMI exchanges report, as shown in Example 18-18.
Example 18-18 The LMI Statistics, as a Result of the debug frame-relay lmi Command
1602-frame#debug frame-relay lmi Frame Relay LMI debugging is on Displaying all Frame Relay LMI data 1602-frame# 1d21h: Serial0(out): StEnq, myseq 175, yourseen 83, DTE up 1d21h: datagramstart = 0x2B9C888, datagramsize = 14 1d21h: FR encap = 0x00010308 1d21h: 00 75 95 01 01 01 03 02 AF 53 1d21h: 1d21h: Serial0(in): Status, myseq 175 1d21h: RT IE 1, length 1, type 1 1d21h: KA IE 3, length 2, yourseq 84, myseq 175 1d21h: Serial0(out): StEnq, myseq 176, yourseen 84, DTE up 1d21h: datagramstart = 0x2B9C888, datagramsize = 14 1d21h: FR encap = 0x00010308 1d21h: 00 75 95 01 01 01 03 02 B0 54 ! The keepalive exchanges are correct and the link is operational, but ! the DLCI requires additional attention. 1d21h: 1d21h: Serial0(in): Status, myseq 176 1d21h: RT IE 1, length 1, type 1 1d21h: KA IE 3, length 2, yourseq 85, myseq 176 1d21h: Serial0(out): StEnq, myseq 177, yourseen 85, DTE up 1d21h: datagramstart = 0x2B9C888, datagramsize = 14 1d21h: FR encap = 0x00010308 1d21h: 00 75 95 01 01 00 03 02 B1 55 1d21h: 1d21h: Serial0(in): Status, myseq 177 1d21h: RT IE 1, length 1, type 0 1d21h: KA IE 3, length 2, yourseq 86, myseq 177 ! Review the next line, it shows dlci 16 1d21h: PVC IE 0x7 , length 0x3 , dlci 16, status 0x2 1d21h: Serial0(out): StEnq, myseq 178, yourseen 86, DTE up 1d21h: datagramstart = 0x2B9C888, datagramsize = 14 1d21h: FR encap = 0x00010308 1d21h: 00 75 95 01 01 01 03 02 B2 56 ! This is an output from full status enquiry, where the listed ! DLCI is 16 and the status is reported 0x2 active. ! The other value would be Inactive 0x0. 1d21h: 1d21h: Serial0(in): Status, myseq 178 1d21h: RT IE 1, length 1, type 1 1d21h: KA IE 3, length 2, yourseq 87, myseq 178 1d21h: Serial0(out): StEnq, myseq 179, yourseen 87, DTE up 1d21h: datagramstart = 0x2B9C888, datagramsize = 14 1d21h: FR encap = 0x00010308 1d21h: 00 75 95 01 01 01 03 02 B3 57
560
At the same time, the core router report shows the output in Example 18-19 (the core routers congured DLCI is 62).
Example 18-19 Verifying the Status of DLCI 62 on the Core Router
7206-frame#show ip interface brief Serial3/3:0 unassigned <output omitted> Serial3/3:0.50 10.84.5.222 Serial3/3:0.53 10.84.5.222 Serial3/3:0.55 10.84.5.222 Serial3/3:0.57 10.84.5.222 Serial3/3:0.61 10.84.5.222 ! The serial 3/3:0.62 is reporting UP, UP Serial3/3:0.62 10.84.5.222 YES NVRAM YES YES YES YES YES unset unset unset unset unset up up up up down down up up up up up down down up
YES unset
Notice that DLCI = 62 is reported as up and up. The information reported from the remote users router includes all congured PVCs, except for any PVCs with PVC STATUS = DELETED. So based on the initial service providers conrmation of the service, the provider seems to have congured DLCI = 16, but DLCI=17 is congured on the remote users router. To verify this suggestion, look at the show frame-relay pvc output, as shown in Example 18-20.
Example 18-20 Output from the Remote Users Router After the show frame-relay pvc Command
1602-frame#show frame-relay pvc PVC Statistics for interface Serial0 (Frame Relay DTE) Active 0 0 1 Inactive 0 0 0 Deleted 1 0 0 Static 0 0 0
Local Switched Unused
DLCI = 16, DLCI USAGE = UNUSED, PVC STATUS = ACTIVE, INTERFACE = Serial0 input pkts 3 output pkts 0 out bytes 0 dropped pkts 0 in BECN pkts 0 out FECN pkts 0 in DE pkts 0 out DE pkts 0 out bcast pkts 0 out bcast bytes 0 pvc create time 00:02:45, last time pvc status in bytes 918 in FECN pkts 0 out BECN pkts 0 Num Pkts Switched 0 changed 00:02:45
DLCI = 17, DLCI USAGE = LOCAL, PVC STATUS = DELETED, INTERFACE = Serial0.16 input pkts 0 output pkts 1 out bytes 312 dropped pkts 0 in BECN pkts 0 out FECN pkts 0 in DE pkts 0 out DE pkts 0 out bcast pkts 1 out bcast bytes 312 pvc create time 00:03:44, last time pvc status 1602-frame# in bytes 0 in FECN pkts 0 out BECN pkts 0
changed 00:02:50
561
You can clearly see that the non-congured Serial0.16 is ACTIVE, and that Serial0.17 is DELETED. The x is standard and quick to implement, as shown in Example 18-21.
Example 18-21 Implementing the Conguration ChangeChange DLCI = 17 to DLCI = 16
1602-frame#configure terminal Enter configuration commands, one per line. End with CNTL/Z. 1602-frame(config)#interface serial 0.16 1602-frame(config-subif)#frame-relay interface-dlci 16 ietf 1602-frame(config-fr-dlc)#end 1602-frame#write memory ! It is always good practice to check the status of interfaces after ! the change and make sure that the change is successful. ! This is shown in the following output. 1602-frame#show ip interface brief Interface IP-Address OK? Method Status Protocol Ethernet0 10.84.14.169 YES NVRAM up up Serial0 unassigned YES NVRAM up up Serial0.16 10.84.14.169 YES unset up up 1602-frame#
After shutting down Serial0.17, verify the PVC status of the remote users router with the show frame-relay pvc command, as shown in Example 18-22.
Example 18-22 Output from the Remote Users Router, Showing the PVC Status
DLCI = 16, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0.16 input pkts 2829 output pkts 1894 in bytes 505954 out bytes 524513 dropped pkts 0 in FECN pkts 19 in BECN pkts 0 out FECN pkts 0 out BECN pkts 0 in DE pkts 0 out DE pkts 0 out bcast pkts 95 out bcast bytes 30824 pvc create time 01:31:33, last time pvc status changed 01:31:33 1602-frame#
NOTE
The DLCI = 17 disappears from the conguration and from the show status commands outputs, but not immediately. It disappears only after the box is reloaded.
562
One of the most common problems related to the same issue is that the remote users router is unable to ping the core routers serial interface. The recommended steps to follow are verifying the correct network address and its mapping to the correct DLCI by using show frame-relay map:
7206-frame#show frame-relay map Serial3/3:0.62 (up): point-to-point dlci, dlci 62(0x3E,0xCE0), broadcast, IETF status defined, active
This shows the network address, DLCI number, and interface in use. The status message of dened and active can be displayed, even if the DLCI is not working. The message actually indicates that the DLCI can carry data and that the router at the far end is active, which is important end-to-end information. Another important point is to distinguish between different designs, and to realize that you cannot always ping your own Ethernet interface, especially in a multipoint Frame Relay interface. Pings to your own interface address are successful on point-to-point subinterfaces, or HDLC links because the router on the other side of the link knows where to return the Internet Control Message Protocol (ICMP) echo and echo reply packets. Thus, an ICMP is sent and received in the right direction. In point-to-multipoint designs, the multipoint interface has multiple IPs and multiple destinations assigned. Therefore, to successfully send an ICMP reply, the router must have a mapping for every destination. If mapping is not congured, do not expect to receive an ICMP reply because the router does not have any Layer-2 to Layer-3 mapping for its own address and it does not know how to encapsulate the packet. An encapsulation failure is the typical result. You cannot ping from one spoke to another in a hub and spoke conguration by using multipoint interfaces because there is no mapping for the other spokes IP addresses. Interestingly enough, the same logic applies when you use Frame Relay or ADSL over Asynchronous Transfer Mode (ATM), and use a spoke and hub conguration. Only the hubs address is learned through Inverse Address Resolution Protocol (InARP). If you congure a static map using the frame-relay map command for your IP address or the IP address of a remote spoke, you can ping your interface address and the addresses of other spokes.
Scenario 3: Performance Issues from Flapping Lines and Trafc Shaping Issues
This scenario represents one of the most common and, at the same time, most difcult to pinpoint issueswhen performance expectations are not met or the service is good for a period of time but there is no data exchange whatsoever for short periods of time. Some of the most common reasons for these problems are apping lines and trafc shaping issues.
563
Flapping Lines
Problems that result from apping lines are linked to the history of the PVC, as reported by the Frame Relay commands. As previously discussed, the Frame Relay router requests the status of all PVCs on the interface during the periodic polling cycles of LMI, which is typically every six polling cycles. The resulting full-status message response contains information on every PVC that is congured on that physical interface. The information includes the recent history of the PVC and its availability (inactive or active). The term apping lines refers to the situation when the service continually changes its state from active to inactive, or is apping. The user tries to exchange data, but the exchange is not available for a period of time, where the user cannot ping, telnet, or reach the other partys router or any partys IP address. After a while, the service comes back up and repeats the cycle. The typical reports that indicate a apping line are shown in Example 18-23.
Example 18-23 The History of the DLCI, Including the Relative Time When the Service Was Created and the Last
Time the PVC Status Was Changed

DLCI = 74, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0.74 input pkts 42832 output pkts 49616 in bytes 17904175 out bytes 9379033 dropped pkts 62 in FECN pkts 0 in BECN pkts 0 out FECN pkts 0 out BECN pkts 0 in DE pkts 42832 out DE pkts 0 out bcast pkts 2580 out bcast bytes 777846 pvc create time 3w2d, last time pvc status changed 00:15:53 ! If the PVC was created 3w2d ago, you must identify what causes ! the pvc status to be changed so often. 1602-frame# ! Use the show service-module command to verify how the line parameters ! are reported: 1602-frame#show service-module Module type is 4-wire Switched 56K in DDS mode, Receiver has no alarms. Current line rate is 56 Kbits/sec and role is DSU side, Last clearing of alarm counters 1d19h ! This report matches the previous one oos/oof : 120, last occurred 00:15:53 loss of signal : 0, loss of sealing current: 0,
continues
564
Example 18-23 The History of the DLCI, Including the Relative Time When the Service Was Created and the Last
Time the PVC Status Was Changed (Continued)

! The last time CSU/DSU was looped back (from you, or from ! the service provider) in order to test the connection CSU/DSU loopback : 107, last occurred 14:11:29 loopback from remote : 0, DTE loopback : 0, line loopback : 0, 1602-frame#
If you check the serial interfaces, you see a high volume of errors on the input portion of the statistics, as shown in Example 18-24.
Example 18-24 To See the Number of Input and Output Errors and Their Type, Use the show interfaces Command
in Enabled Mode
1602-frame#show interfaces Serial0 is up, line protocol is up Hardware is QUICC Serial (with onboard CSU/DSU) MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec, reliability 255/255, txload 1/255, rxload 1/255 Encapsulation FRAME-RELAY, loopback not set Keepalive set (10 sec) LMI enq sent 15696, LMI stat recvd 15107, LMI upd recvd 0, DTE LMI up LMI enq recvd 0, LMI stat sent 0, LMI upd sent 0 LMI DLCI 0 LMI type is ANSI Annex D frame relay DTE <output omitted> 5 minute input rate 2000 bits/sec, 4 packets/sec 5 minute output rate 2000 bits/sec, 3 packets/sec 59692 packets input, 19967056 bytes, 0 no buffer Received 0 broadcasts, 0 runts, 6 giants, 0 throttles ! Look to the extensive number of errors and especially number of aborts. 201794 input errors, 11665 CRC, 159475 frame, 0 overrun, 0 ignored, 30654 abort 65338 packets output, 9595695 bytes, 0 underruns ! The number of interface resets is extremely high as well 0 output errors, 0 collisions, 11137 interface resets 0 output buffer failures, 0 output buffers swapped out 0 carrier transitions DCD=up DSR=up DTR=up RTS=up CTS=up
This output shows that you are dealing with second-layer problems, which is the reason that the service went down. Identify which layer of the service is affected and not the rst layer. Examine the output from the #show service-module command, which shows that the DTE never loses the signal (loss of signal : 0). Also, no carrier transitions exist (0 carrier transitions), which is typical when the line is out of sync. Obviously, the rst layer is not affected; thus, focus on the protocol layer and its components and determine which one is causing the service to go down. Recall the way that LMI works and reports the DTE down, then increments the counter and resets the interface. Check the number of interface resets
565
to conrm that the counters were incremented. The number of interface resets does not match the carrier transitions, but CRC and frame errors, which leads you to determine that you are dealing with second-layer issues. Remembering that, verify how the other party the core routerreports the status of the PVC. The core router is congured for DLCI = 74 in Serial4/1:0. Its status is shown in Example 18-25.
Example 18-25 Verifying the Status of PVC 74 on the Core Router
7206-frame#show frame-relay pvc 74 PVC Statistics for interface Serial4/1:0 (Frame Relay DTE) DLCI = 74, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial4/1:0.74 input pkts 167039 output pkts 157077 in bytes 26896506 out bytes 79023826 dropped pkts 116 in FECN pkts 0 in BECN pkts 0 out FECN pkts 0 out BECN pkts 0 in DE pkts 167039 out DE pkts 0 out bcast pkts 9748 out bcast bytes 2924400 pvc create time 3w0d, last time pvc status changed 00:17:09 cir 56000 bc 56000 be 0 byte limit 875 interval 125 mincir 28000 byte increment 875 Adaptive Shaping none pkts 156956 bytes 78972226 pkts delayed 51275 bytes delayed 56957021 shaping inactive traffic shaping drops 0 Queuing strategy: fifo Output queue 0/40, 116 drop, 51275 dequeued 7206-frame#
There is nothing unusual from the core side to affect or reect the issues that the remote side is experiencing. Further actions to x the service include the following steps on the remote users router:
Check the performance parameters of the router with #show processes cpu. Check for possible hardware problems using #show diag module_number. Check for failing buffers with #show buffers fail. Work with the service provider to eliminate the failing device or equipment.
After the successful resolution of this issue, it is good practice to check the status of the service from both sides the next day with the following commands:
1602-frame#show frame-relay pvc 74 7206-frame#show frame-relay pvc 74
566
The remote users router reports the output shown in Example 18-26.
Example 18-26 The Core Router Report for the Troubled PVC 74
PVC Statistics for interface Serial0 (Frame Relay DTE) Active 1 0 0 Inactive 0 0 0 Deleted 0 0 0 Static 0 0 0
DLCI = 74, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial4/1:0.74 input pkts 186908 output pkts 175377 in bytes 29752740 out bytes 89258825 dropped pkts 116 in FECN pkts 0 in BECN pkts 0 out FECN pkts 0 out BECN pkts 0 in DE pkts 186908 out DE pkts 0 out bcast pkts 11055 out bcast bytes 3316500 ! The last time the pvc status has changed is 17:44.54. pvc create time 3w1d, last time pvc status changed 17:44:54 cir 56000 bc 56000 be 0 byte limit 875 interval 125 mincir 28000 byte increment 875 Adaptive Shaping none pkts 175256 bytes 89207225 pkts delayed 57828 bytes delayed 64737774 shaping inactive traffic shaping drops 0 Queuing strategy: fifo Output queue 0/40, 116 drop, 57828 dequeued 7206-frame#
The last time the PVC changed is reported after the x is implemented (the last time the PVC status changed was 17:44:54). If the number and type of errors is not incrementing from where they were before the changes were implemented, you can consider the case closedthe troubleshooting actions have corrected the problem.
Trafc Shaping Issues

Another important cause of performance issues is related to trafc shaping settings. The two basic cases are no trafc shaping and wrong trafc shaping; both equally affect performance of the service. The conguration for trafc shaping is covered in Chapter 16. It is a necessary feature if you need to prioritize different types of trafc by trimming the timers and counters, or conguring Bc, Be, and timing intervals.
567
NOTE
The Enhanced Local Management Interface (ELMI) is an interesting Cisco feature that is well-known for enabling Frame Relay quality of service (QoS) by using the 7206frame(cong-if)# frame-relay qos-autosense command. By turning this command on and off, it can perform dynamic trafc shaping. The feature enables the automated exchange of Frame Relay QoS parameter information, between the Cisco router and the Cisco switch (BPX/MGX and IGX platforms). The router uses the QoS values from the switch that are congurable to establish trafc shaping. More about this Cisco IOS feature can be found at www.cisco.com. Because of the use of trafc shaping, performance issues are recognized in three typical scenarios:
Unacceptable high round-trip time (RTT) The line that was provisioned for certain access rates provides less than expected performance Flapping routes
High RTT Numbers

An example of the rst case is when the user and the core router are located in the same area, but the test is performed from a remote geographic location. The local carriers are X and Y, and the IXC (long-distance carrier) carries the trafc with one-way latency of about 80 ms. The local loop latency is denitely lower than the two-way latency of the longdistance carrier, given the locations and distance. If you assume that two local loops (core side and the remote users side) each have latency equal to one-way latency of the local carrier (3 80), you can expect a RTT of about 240 ms. Now, to check the actual results, perform a ping with 64 bytes, which means that there is no need for fragmentation/ defragmentation (see Example 18-27).
Example 18-27 A Ping Test Performed to Find Out the RTT
UNIX.cisco.com:/users/pnedeltc> ping 1602-frame PING 1602-frame.cisco.com: 56 data bytes 64 bytes from 1602-frame.cisco.com (10.84.11.73): 64 bytes from 1602-frame.cisco.com (10.84.11.73): 64 bytes from 1602-frame.cisco.com (10.84.11.73): 64 bytes from 1602-frame.cisco.com (10.84.11.73): 64 bytes from 1602-frame.cisco.com (10.84.11.73): 64 bytes from 1602-frame.cisco.com (10.84.11.73): 64 bytes from 1602-frame.cisco.com (10.84.11.73): 64 bytes from 1602-frame.cisco.com (10.84.11.73): 64 bytes from 1602-frame.cisco.com (10.84.11.73):
icmp_seq=0. icmp_seq=1. icmp_seq=2. icmp_seq=3. icmp_seq=4. icmp_seq=5. icmp_seq=6. icmp_seq=7. icmp_seq=8.
time=6191. ms time=7424. ms time=9101. ms time=11448. ms time=13887. ms time=16244. ms time=18760. ms time=22428. ms time=27199. ms
continues
568
Example 18-27 A Ping Test Performed to Find Out the RTT (Continued)
64 bytes from 1602-frame.cisco.com (10.84.11.73): icmp_seq=9. time=34426. ms .................. 64 bytes from 1602-frame.cisco.com (10.84.11.73): icmp_seq=376. time=114440. ms ^C ----1602-frame.cisco.com PING Statistics---493 packets transmitted, 135 packets received, 72% packet loss round-trip (ms) min/avg/max = 6191/112398/133134
As you can see from the output, the RTT values are inconsistent and signicantly exceed your expectations. If you trace the path (see Example 18-28), you see that the long-distance provider carries the trace to the remote site in 80 ms; however, the local service provider carries the trace within a local area in 200 ms. There is a problem with performance on the local loop.
Example 18-28 A Trace Route Test, Performed to Find the Highest RTT
Starting trace - Aug 27, 2001 10:19:40 Tracing to 1602-frame [10.84.11.73].... Hops IP Address RTT(ms) DNS Name 1 161.71.86.2 0 hop-dtb-gw1.cisco.com 2 161.71.241.153 0 hop-sbb4-gw1.cisco.com 3 161.71.241.37 0 hop-rbb-gw3.cisco.com 4 161.69.7.217 0 hop-rbb-gw1.cisco.com 5 161.69.7.158 0 hop-gb4-g0-0.cisco.com 6 161.68.86.58 81 hop-sj-pos.cisco.com 7 10.184.5.89 80 hop-rbb-gw1.cisco.com ! The trace reaches the other end, which is the core router. 8 10.84.5.222 80 7206-frame.cisco.com ! The trace reaches the remote users router 9 10.84.11.73 200 1602-frame.cisco.com Host reached ! The last hop is 200 ms RTT
The tests of the users router show no buffer or hardware failures. However, if you check whether trafc shaping is applied to DLCI = 60, you can see that DLCI = 60 is not listed, as shown in Example 18-29.
Example 18-29 Verifying if DLCI = 60 Is Listed Among DLCIs, with Applied Trafc Shaping
7206-frame#show traffic-shape Interface Se3/0:0 Access Target VC List Rate 38 56000 34 56000 33 56000
Byte Limit 875 875 875
Sustain bits/int 7000 7000 7000
Excess bits/int 0 0 0
Interval (ms) 125 125 125
Increment (bytes) 875 875 875
Adapt Active -
569
Example 18-29 Verifying if DLCI = 60 Is Listed Among DLCIs, with Applied Trafc Shaping (Continued)
32 22 16 56000 56000 56000 875 875 875 7000 7000 7000 0 0 0 125 125 125 875 875 875 -
Interface Se3/0:0.17 Access Target VC List Rate 17 56000 Interface Se3/0:0.18 Access Target VC List Rate 18 56000 Interface Se3/0:0.20 Access Target VC List Rate 20 56000 Interface Se3/0:0.23 Access Target VC List Rate 23 56000 Interface Se3/0:0.24 Access Target VC List Rate 24 56000 <output omitted> Interface Se3/0:0.62 Access Target VC List Rate 62 384000
Byte Limit 875
Sustain bits/int 7000
Excess bits/int 0
Interval (ms) 125
Increment Adapt (bytes) Active 875 -
Byte Limit 875
Excess bits/int 0
Interval (ms) 125
Byte Limit 875
Excess bits/int 0
Interval (ms) 125
Byte Limit 875
Excess bits/int 0
Interval (ms) 125
Byte Limit 875
Excess bits/int 0
Interval (ms) 125
Byte Limit 6000
Excess bits/int 0
Interval (ms) 125
The rst conclusion about this case can lead you to Scenario 1, local loop problems, or apping links. After working with LEC, you might conclude that this is a trafc-shaping issue. The required x is to implement the appropriate trafc-shaping map class.
Slow Performance
The second trafc shaping issue is when performance is lower than what the user is expecting. In this scenario, the service is provisioned for an access rate of 384-kbps, but performance characteristics are closer to a 56-kbps circuit. The service is operational, the serial lines do not report any errors, and both the remote users and the core routers congurations are set up correctly, and report normal. The output in Example 18-30 shows the DLCI = 98 parameters.
570
Example 18-30 Verifying the Serial 4/0:0.98 Conguration on the Core Router
7206-frame#show interfaces serial 4/0:0.98 Serial4/0:0.98 is up, line protocol is up Hardware is Multichannel T1 Description: 1604-frame: 10.21.56.8/29 : 23161309 : 3844600235 Interface is unnumbered. Using address of Loopback2 (171.68.88.1) MTU 1500 bytes, BW 256 Kbit, DLY 20000 usec, reliability 255/255, txload 24/255, rxload 5/255 Encapsulation FRAME-RELAY
The output from 7206-frame#show frame-relay pvc 98 is shown in Example 18-31.

Example 18-31 Verifying if PVC 98 Has Trafc Shaping Applied to It
7206-frame#show frame-relay pvc 98 DLCI = 98, DLCI USAGE = UNUSED, PVC STATUS = ACTIVE, INTERFACE = Serial4/0:0 input pkts 167755 output pkts 167552 in bytes 13750582 out bytes 189232810 dropped pkts 71 in FECN pkts 0 in BECN pkts 0 out FECN pkts 0 out BECN pkts 0 in DE pkts 167755 out DE pkts 0 out bcast pkts 16392 out bcast bytes 4967386 pvc create time 5d16h, last time pvc status changed 5d16h ! These are the parameters, defining the performance. cir 28000 bc 7000 be 0 limit 875 interval 125 mincir 28000 byte increment 875 Adaptive Shaping none pkts 167481 bytes 189226266 pkts delayed 128118 bytes delayed 171119678 shaping inactive traffic shaping drops 0 Serial4/0:0.98 dlci 98 is first come first serve default queuing Output queue 0/40, 71 drop, 128118 dequeued
Next, you need to take some measurements from the interfaces Ethernet0 and Serial1 of the remote users router, then ping from the core router or from any server in the same area with a packet size of 3000 bytes. Measure the end users ve-minute rate by entering the following two commands, as shown in Example 18-32:
1602-frame#show interfaces ethernet 0 1602-frame#show interfaces serial 1
include 5 min
include 5 min
Example 18-32 Measuring the Input and Output Rate on Ethernet0 and Serial1 Interfaces of a Remote Users
Router
1602-frame#show interfaces ethernet 0 | include 5 min 5 minute input rate 7000 bits/sec, 13 packets/sec 5 minute output rate 8000 bits/sec, 18 packets/sec 1602-frame#show interfaces serial 1 | include 5 min
571
Example 18-32 Measuring the Input and Output Rate on Ethernet0 and Serial1 Interfaces of a Remote Users
Router (Continued)
5 minute input rate 4000 bits/sec, 22 packets/sec 5 minute output rate 6000 bits/sec, 14 packets/sec 1602-frame#
It is a good idea to monitor the RXD and TXD, and the reliability reports (reliability 255/ 255) of the 1602-frame router:
Serial1 is up, line protocol is up Hardware is QUICC Serial (with FT1 CSU/DSU WIC) MTU 1500 bytes, BW 128 Kbit, DLY 20000 usec, reliability 255/255, txload 7/255, rxload 85/255
If you go back to review the previous outputs, you will notice that for a 384-kbps circuit, the core router reports the following:
pvc create time 5d16h, last time pvc status changed 5d16h cir 28000 bc 7000 be 0 limit 875 interval 125 mincir 28000 byte increment 875 Adaptive Shaping none
The new cong inherits the default settings of Serial4/0:0, where trafc shaping is dened with no classes. The x is easy to apply. First, create a map class, as shown in Example 18-33.
Example 18-33 Example for Class Denition Called class-384-new
map-class frame-relay class-384-new no frame-relay adaptive-shaping frame-relay cir 384000 frame-relay bc 384000 frame-relay be 128000 frame-relay mincir 256000
Next, apply the map class, as shown in Example 18-34.

Example 18-34 The Class class-384-new Is Applied to the Interface
interface Serial4/0:0.98 point-to-point description 1604-frame frame: 10.21.56.8/29 : 23161309 : 3844600235 bandwidth 384 ip unnumbered Loopback2 no ip route-cache frame-relay class class-384-new frame-relay interface-dlci 98 IETF
Repeat the status commands and compare the results, as shown in Example 18-35.
572
Example 18-35 Check the Status of PVC 98

7206-frame#show frame-relay pvc 98 PVC Statistics for interface Serial4/0:0 (Frame Relay DTE) DLCI = 98, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial4/0:0.98 input pkts 536361 output pkts 659230 in bytes 100680624 out bytes 165617202 dropped pkts 68 in FECN pkts 0 in BECN pkts 0 out FECN pkts 0 out BECN pkts 0 in DE pkts 536361 out DE pkts 0 out bcast pkts 23237 out bcast bytes 1886266 pvc create time 2d04h, last time pvc status changed 1d05h ! The CIR now is 384000, bc=384000, be=128000. cir 384000 bc 384000 be 128000 limit 4000 interval 125 mincir 256000 byte increment 4000 Adaptive Shaping none pkts 659213 bytes 122881018 pkts delayed 20415 bytes delayed 19232012 shaping inactive traffic shaping drops 0 Serial4/0:0.98 dlci 98 is first come first serve default queuing Output queue 0/40, 29 drop, 20415 dequeued
Finally, repeat the ping test and compare the results, as shown in Example 18-36.
Example 18-36 Measuring the Input and Output Rate on Ethernet0 and Serial1 Interfaces of the Remote Users
Router, After Implementing the Map Class

1602-frame#show interfaces ethernet 0 | include 5 min 5 minute input rate 8000 bits/sec, 15 packets/sec 5 minute output rate 192000 bits/sec, 30 packets/sec 1602-frame#show interfaces serial 1 | include 5 min 5 minute input rate 70000 bits/sec, 29 packets/sec 5 minute output rate 6000 bits/sec, 16 packets/sec
The performance has improved signicantly.
Flapping Routes
Flapping routes occur during the convergence process when there is instability in the network. Different routing protocols pose different requirements for Frame Relay, but sometimes even a lack of memory on the core router when the number of subscribed users increases can cause this issue. One symptom of network instability is when trace commands use different paths to reach the destination, indicating either a slow convergence process, or a change in the topology and a related change in the routing table. All the routers in the network must converge on the new topology when changes exist in the network. Toward this end, they begin sharing routing information, and each update
Scenario 4: IP Multicast Issues in Frame Relay
573
nullies the previous decision and triggers another update to the other routers. These routers, in turn, adjust their own routing tables and generate new updates, which cause apping routes. The recommended way of dealing with this situation is far more complex than it appears, and requires additional troubleshooting. One possible solution is powering down the affected routers and slowly allowing convergence in your network, one router at a time. For more information, check www.cisco.com. Powering down production routers is not always feasible. Also, depending on the size and conguration of the routers, it might not work to do it router by router. In extremely large networks, with large routing tables, it might be necessary to shut down all interfaces, power cycle the box, and bring it back online one interface at a time.

Because multicast is a specic area of expertise, it is necessary that you rst have a clear understanding of the terminology and underlying concepts of IP multicast. Internet Group Management Protocol (IGMP), Protocol Independent Multicast (PIM), dense mode, sparse mode, sparse-dense mode, rendezvous point (RP), Distance Vector Multicast Routing Protocol (DVMRP), Reverse Path Forwarding (RPF), shortest path tree (SPT) and their interactions are the key elements for troubleshooting multicast in Frame Relay. It is important to have a clear understanding of the group ags, and their role in the management of the process. The group ags include the following:
DDense SSparse BBidir Group CConnected LLocal PPruned RRP-bit set FRegister ag TSPT-bit set JJoin SPT MMSDP created entry XProxy Join Timer Running AAdvertised through Multicast Source Discovery Protocol (MSDP)
Recall that IP multicast, unlike unicast and broadcast, provides a scheme where a host sends packets to a subset of all hosts (group transmission), which are known as group members. Instead of listing all the IP addresses of the group members, all members are identied by a single multicast group address. Multicast packets are delivered to a group using
574
best-effort reliability. In this environment, some members send multicast streams and others only listen, but while any host (whether a member of the group or not) can send to the group, only the members of a group receive the multicast streams. Membership in a multicast group is dynamic; hosts can join and leave at any time. A host can be a member of more than one multicast group at a time. For further information about multicast see Developing IP Multicast Networks, Volume I, by Beau Williamson (Cisco Press, 2000). Some of the most common symptoms of existing problems with multicast are documented here. The remote user thats congured under Serial3/2:0.83 interface of the core router does not receive multicast trafc. The multicast software (such as Cisco IP/TV for example), regardless of the conguration efforts, does not report any incoming multicasts, or there is voice but no video. The rst action is to check if the SPT exists. Always start the troubleshooting process with the upstream neighbor of the remote users router, and check if there is multicast trafc by checking the PIM neighbors using the command in Example 18-37. In this case, the upstream neighbor is the core router.
Example 18-37 Checking if There Is an Upstream PIM Neighbor Available
7206-frame#show ip pim neighbor PIM Neighbor Table Neighbor Interface Uptime/Expires Address 161.70.192.10 FastEthernet0/0 00:04:20/00:01:24 161.70.192.24 FastEthernet0/0 00:04:24/00:01:21 161.70.192.15 FastEthernet0/0 00:04:25/00:01:18 ! One of the PIM neighbors IP is 161.70.192.15. ! The IP is learned through the F0/0 interface. ! The uptime of the neighbor is 04:25 minutes and the timer ! expires after 01:18 minutes. The PIM is version 2. 161.70.192.11 FastEthernet0/0 00:04:33/00:01:41 161.70.192.1 FastEthernet0/0 00:04:33/00:01:41 161.70.192.16 FastEthernet0/0 00:04:35/00:01:40 161.70.192.12 FastEthernet0/0 00:04:37/00:01:37
Ver v2 v2 v2
DR Prio/Mode 1 / B S N / 1 / B S
v2 v2 v2 v2
1 / B S N / 1 / B S 1 / B S
Checking the PIM neighbors is an important step to ensure that the upstream router or switch provides multicast for the core router. The availability of the downstream multicast can be checked by using the show ip mroute command, as shown in Example 18-38.
Example 18-38 Checking the Availability of the Downstream Multicast
7206-frame#show ip mroute 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 - Advertised via MSDP, U - URD, I - Received Source Specific Host Report
575
Example 18-38 Checking the Availability of the Downstream Multicast (Continued)

Outgoing interface flags: H - Hardware switched Timers: Uptime/Expires Interface state: Interface, Next-Hop or VCD, State/Mode <output omitted> ! The RP cannot be recognized RP 0.0.0.0 (*, 239.255.255.253), 09:39:29/00:02:27, RP 0.0.0.0, flags: S ! Sparse mode indicated RPF neighbor 0.0.0.0 Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Serial3/2:0.83, Forward/Sparse-Dense, 09:39:29/00:02:27 <output omitted> (*, 224.0.1.39), 3d13h/00:02:00, RP 0.0.0.0, flags: D Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Serial4/1:0.37, Forward/Sparse-Dense, 3d13h/00:00:00 Serial3/2:0.83, Forward/Sparse-Dense, 09:40:01/00:00:00 Serial4/0:0.89, Forward/Sparse-Dense, 02:08:12/00:00:00 FastEthernet0/0, Forward/Sparse-Dense, 00:03:55/00:00:00 FastEthernet1/0, Forward/Sparse-Dense, 00:03:43/00:00:00 <output omitted>
In the second part of the output, the ag S-Sparse indicates sparse mode and shows RPF neighbor 0.0.0.0. You can also see that the remote user connected through Serial3/2:0.83 issued a join request and, as a result, an outgoing entry is created in the multicast routing table. A similar situation is listed in the third group, where more interfaces (members) have joined, but the incoming interface still reports 0.0.0.0. It seems that the ip pim sparsedense-mode command is missing in the upstream interfaces, which in this case, is a FastEthernet interface. After conguring the interfaces, take a look at the multicast routing table, as shown in Example 18-39.
Example 18-39 Now the FastEthernet 1/0 Interface Sees Its Upstream Neighbor
7206-frame#show ip mroute 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 - Advertised via MSDP, U - URD, I - Received Source Specific Host Report Outgoing interface flags: H - Hardware switched Timers: Uptime/Expires Interface state: Interface, Next-Hop or VCD, State/Mode <output omitted> ! The FastEthernet 1/0 interface sees its upstream neighbor (*, 239.255.255.255), 4w3d/00:00:00, RP 10.68.10.13, flags: SJCL Incoming interface: FastEthernet1/0, RPF nbr 161.70.192.33 Outgoing interface list:
continues
576
Example 18-39 Now the FastEthernet 1/0 Interface Sees Its Upstream Neighbor (Continued)
FastEthernet0/0, Forward/Sparse-Dense, 00:25:50/00:00:00 Serial3/2:0.83, Forward/Sparse-Dense, 00:25:50/00:00:00 Serial4/0:0.89, Forward/Sparse-Dense, 00:25:51/00:00:00 Serial4/1:0.37, Forward/Sparse-Dense, 00:25:51/00:00:00 <output omitted> (192.168.165.15, 224.0.1.39), 00:00:51/00:02:08, flags: PTA Incoming interface: FastEthernet1/0, RPF nbr 161.70.192.33 Outgoing interface list: FastEthernet0/0, Prune/Sparse-Dense, 00:00:51/00:02:08 Serial3/2:0.83, Prune/Sparse-Dense, 00:00:55/00:02:07 Serial4/0:0.89, Prune/Sparse-Dense, 00:00:55/00:02:07 Serial4/1:0.37, Prune/Sparse-Dense, 00:00:55/00:02:06 <output omitted>
The incoming interface reports a valid IP source, and the join messages from downstream members (including Serial3/2:0.83) are registered as an outgoing interface. Next, check the remote users router on the other end. The remote users service is operational, but is experiencing trouble with multicast. The primary focus is on the remote users conguration. If it is correct, the next action to take is to launch Cisco IP/TV (or any other multicast software), and check if the user issues a join request to the group (see Example 18-40).
Example 18-40 Check the IGMP Group Members
1602-frame#show ip igmp group IGMP Connected Group Membership Group Address Interface 239.193.0.10 Ethernet0 239.193.0.5 Ethernet0 224.0.1.40 Ethernet0 1602-frame#
Uptime 00:00:44 00:00:45 5w4d
Expires 00:02:39 00:02:35 never
Last Reporter 10.10.253.125 10.10.253.125 10.10.253.121
The result is positive, so it is time to check if the core router has registered the join request, and identies the downstream router as a neighbor (see Example 18-41).
Example 18-41 Check the IP PIM Neighbors of the Core Router
7206-frame#show ip pim neighbor PIM Neighbor Table Neighbor Interface Uptime/Expires Ver Address <output omitted> 161.70.192.47 FastEthernet1/0 16:33:17/00:01:20 v2 161.70.192.44 FastEthernet1/0 16:33:17/00:01:17 v2 161.70.192.43 FastEthernet1/0 16:33:17/00:01:16 v2 161.70.192.48 FastEthernet1/0 16:33:17/00:01:39 v2 ! The core router sees the downstream neighbor Serial 3/2:0.83
DR Prio/Mode 1 1 1 1 / / / / B B B B S S S S
577
Example 18-41 Check the IP PIM Neighbors of the Core Router (Continued)
10.10.253.121 10.21.56.193 161.70.194.209 7206-frame# Serial3/2:0.83 Serial4/0:0.89 Serial4/1:0.37 00:27:41/00:01:23 v2 16:33:15/00:01:43 v2 16:33:13/00:01:34 v2 N / N / N /
The result is positive, so now check how the remote users router sees the upstream neighbors (see Example 18-42).
Example 18-42 Check if the Remote Users Router Sees the Upstream Neighbor, RP and RPF
1602-frame#show ip mroute IP Multicast Routing Table Flags: D - Dense, S - Sparse, B - Bidir 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 - Advertised via MSDP Outgoing interface flags: H - Hardware switched Timers: Uptime/Expires Interface state: Interface, Next-Hop or VCD, State/Mode (*, 239.193.0.10), 00:18:26/00:02:49, RP 10.68.10.13, flags: SJC ! There is a incoming interface, outgoing interface and a neighbor Incoming interface: Serial1.83, RPF nbr 161.68.122.1 Outgoing interface list: Ethernet0, Forward/Sparse-Dense, 00:03:36/00:02:49 (*, 239.193.0.5), 00:18:27/00:02:41, RP 10.68.10.13, flags: SJC Incoming interface: Serial1.83, RPF nbr 161.68.122.1 Outgoing interface list: Ethernet0, Forward/Sparse-Dense, 00:03:38/00:02:41 <output omitted> 1602-frame#
Next, recall the RPF procedure. For trafc owing down the source tree, the RPF check follows several steps. First, the router examines the source address of the arriving multicast packet to determine whether the packet arrived through an interface that is on the reverse path back to the source. If the check is successful, it forwards the packet; otherwise, it drops it. In the case of the PIM protocol, it typically uses the existing unicast routing table to determine the RPF check. The obvious next step is to compare the trace information between the two trace tools, which are available in the remote users router. A unicast trace uses the existing routing table, and the report is similar to that in Example 18-43. The multicast trace report is different and it clearly reports the problem. The multicast stream is expected from 161.68.88.1, but the next hop is 161.68.86.70 (see Example 18-44).
578
Example 18-43 Using Unicast Trace for Multicast Troubleshooting

1602-frame# trace 10.68.10.13 ! This address (10.68.10.13) points to the Rendezvous Point Type escape sequence to abort. Tracing the route to sj-mbone-loopback0.cisco.com (10.68.10.13) 1 7206-frame.cisco.com (161.68.88.1) 88 msec 84 msec 84 msec 2 access-gw1.cisco.com (161.70.192.1) 84 msec 88 msec 84 msec 3 bbi1-gw2.cisco.com (161.70.192.217) 84 msec 136 msec 128 msec <output omitted> -9 sj-mbone-loopback0.cisco.com (10.68.10.13) 1602-frame#
Example 18-44 Using the Multicast Trace (mtrace Command) for Multicast Troubleshooting
1602-frame#mtrace 10.68.10.13 Type escape sequence to abort. Mtrace from 10.68.10.13 to 10.10.253.121 via RPF From source (sj-mbone-loopback0.cisco.com) to destination (1602-frame.cisco.com) Querying full reverse path... 0 1602-frame.cisco.com (10.10.253.121) -1 1602-frame.cisco.com (10.10.253.121) PIM [default] ! This !RPF! indication should not be missed. -2 161.68.86.70 PIM !RPF!161.68.122.1 [default] -3 161.68.86.69 PIM [default] <output omitted> -9 sj-mbone-loopback0.cisco.com (10.68.10.13) 1602-frame#
The mtrace command output is reporting -2 161.68.86.70 PIM !RPF!161.68.122.1 [default], which indicates some issues with the RPF. RPF is based on the routing table information. Check the routing conguration again. The routing section is congured as shown in Example 18-45.
Example 18-45 The Conguration of the Static Route in the Remote Users Router
1602-frame#show running-config <output omitted> ip classless ip route 0.0.0.0 0.0.0.0 161.68.122.1 ip route 10.10.253.120 255.255.255.248 Ethernet0 <output omitted>
The mtrace command is based on the routing statement of the router that points to IP address 161.68.122.1, which is not on the reverse path, and consequently, the packets are discarded.
579
Finally, replace the routing statement and bound the next hop address in the static route with the outgoing interface, rather than with the IP address of the next hop. Another approach is to replace 161.68.122.1 with 161.68.88.1. After the conguration change, check the result with #show ip mroute, as shown in Example 18-46.
Example 18-46 Output from the show ip mroute Command Shows a New Neighbor
1602-frame#show ip mroute IP Multicast Routing Table Flags: D - Dense, S - Sparse, B - Bidir 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 - Advertised via MSDP Outgoing interface flags: H - Hardware switched Timers: Uptime/Expires Interface state: Interface, Next-Hop or VCD, State/Mode (*, 239.193.0.10), 00:30:56/00:02:14, RP 10.68.10.13, flags: SJC Incoming interface: Serial1.83, RPF nbr 171.68.88.1 Outgoing interface list: Ethernet0, Forward/Sparse-Dense, 00:16:06/00:02:14 (*, 239.193.0.5), 00:30:57/00:02:59, RP 10.68.10.13, flags: SJC Incoming interface: Serial1.83, RPF nbr 171.68.88.1 Outgoing interface list: Ethernet0, Forward/Sparse-Dense, 00:16:07/00:02:18 <output omitted>
Consequently, the output of the mtrace command is as shown in Example 18-47.

Example 18-47 Output from the mtrace Command
1602-frame#mtrace 10.68.10.13 Type escape sequence to abort. Mtrace from 10.68.10.13 to 10.10.253.121 via RPF From source (sj-mbone-loopback0.cisco.com) to destination (1602-frame.cisco.com) Querying full reverse path... 0 1602-frame.cisco.com (10.10.253.121) -1 1602-frame.cisco.com (10.10.253.121) PIM [default] ! The next line shows that the upstream neighbor has changed. -2 7206-frame-1.cisco.com (171.68.88.1) PIM [default] -3 161.70.192.33 PIM [default] -4 161.70.192.221 PIM [10.68.10.13/32] <output omitted> -10 sj-mbone-loopback0.cisco.com (10.68.10.13)
NOTE
Another recommended command is 1602-frame#mstat 10.10.253.121 10.68.10.13.
580
The result after the conguration changes conrms that the multicast feature is on and the multicast applications are passing IP trafc. The example provided is one of the possible scenarios, and it is designed to demonstrate the methodology for troubleshooting IP multicast in Frame Relay rather than including all possible issues and their solutions.
Scenario 5: Frame Relay Host Migration

During the ebb and ow of business cycles and reorganizations, many consolidations in plant and ofce locations can take place. These include ofce moves and closures, which require existing remote access infrastructures to be relocated. In a small to medium-sized remote access Frame Relay environment, it occasionally might become necessary to rehome your remote users to a new location. The following scenario describes how to manage such a move and the required steps to implement a seamless transition between two Frame Relay hosts in different locations. The example here works on the premise that an ofce located in Austin, TX, will be closed in a matter of months and relocated to Phoenix, AZ. Fourty remote access circuits are currently congured on a host in the Austin ofce. These circuits must be remapped to a host in Phoenix.
Working with Your Vendor

One of the rst steps is to speak to your vendor to provision a host circuit in the new location. In this case, a Frame Relay T1 is ordered for Phoenix and it is also necessary to map the endpoints onto this host. The end-user locations are most likely geographically dispersed. Service management is simplied if there is one vendor that provisions and installs the endpoint and host circuits because they most likely cross LEC boundaries. If you anticipate the time frame necessary for the vendor to deliver the service, you can request that the DLCIs be provisioned on top of existing circuits. This means that although you might currently have an existing DLCI mapped onto the end-user circuit, the vendor has the means of conguring another DLCI and mapping it back to Phoenix. This allows you to carry several point-to-point circuits on one Frame Relay line. You must provide the vendor with new DLCI numbers for the remote users that differ from the previous ones. Make sure that they are sequential and coincide with the way you want to see the mappings. For example, you might want to choose the DLCI range of 100139. This provides a simplied migration when building the new host. At this point, the vendor must perform a series of tasks to migrate the host from Austin to Phoenix. Initially, they must install the host circuit in Phoenix. Secondly, they must build and provision the new mappings for the remote users, which creates another virtual circuit (VC) at the remote end that points back to the Phoenix host while keeping the existing maps
581
back to Austin. After this is completed, you are ready to perform the tasks required to migrate.
Preparing the Host

Supposing that the vendor performed the required tasks, you are now ready to begin the process of migration. In this example, a 3640 host is used with 1602s at the remote users premise. Initially, you must congure and set up the new host circuit in Phoenix. Essentially, it should look like the existing installation in Austin, unless features and functionality have been added or removed. For the purposes of this example, start by conguring the T1 controller (see Example 18-48).
Example 18-48 Conguration Commands that Provide Basic Signaling Services for the Frame Relay Host
3640-frame-phoenix#configure terminal 3640-frame-phoenix(config)# controller T1 1/0 3640-fram(config-controller)# description Frame Relay T1-Phoenix, AZ, Vendor M Circuit # 83XXXXXXXX 3640-fram(config-controller)# framing esf 3640-fram(config-controller)# fdl ansi 3640-fram(config-controller)# linecode b8zs 3640-fram(config-controller)# channel-group 0 timeslots 1-24 speed 64
The vendor provides a circuit that runs coding schemes such as Extended Superframe (ESF) framing and bipolar 8-zero substitution (B8ZS) linecoding.
NOTE
It is a recommended practice to use a description of the circuit in the conguration, in case any issues exist with the line.
Next, the corresponding serial interface must be congured to split the host circuit into its corresponding subinterfaces and DLCIs. Traditional Frame Relay lines look like what is shown in Example 18-49.
Example 18-49 These Conguration Commands Allow the Serial Interface to Interact with the Controller
Previously Congured
3640-frame-phoenix#config terminal 3640-frame-phoenix(config)#interface Serial1/0:0 3640-frame-phoenix(config-if)# description T1 Frame Relay Phoenix, AZ: Vendor M / Circuit #: 83XXXXXXXX 3640-frame-phoenix(config-if)# no ip address 3640-frame-phoenix(config-if)# encapsulation frame-relay IETF 3640-frame-phoenix(config-if)# ip mroute-cache 3640-frame-phoenix(config-if)# frame-relay lmi-type ansi
582
An IP address is not used for the host circuit. Frame Relay encapsulation is ANSI LMI. After it is congured, you can check to see if you have the appropriate signaling by performing a show interfaces command (see Example 18-50).
Example 18-50 Output from the show interfaces Command Should Show the Status of the Serial Interface, the Type
of Frame Relay Encapsulation and the Type of LMI

3640-frame-phoenix#show interfaces Serial1/0:0 Serial1/0:0 is up, line protocol is up Hardware is DSX1 Description: T1 Frame Relay Phoenix, AZ: Vendor M / Circuit #: 83XXXXXXXX MTU 1500 bytes, BW 1536 Kbit, DLY 20000 usec, reliability 255/255, txload 2/255, rxload 1/255 Encapsulation FRAME-RELAY IETF, loopback not set Keepalive set (10 sec) LMI enq sent 103431, LMI stat recvd 103431, LMI upd recvd 0, DTE LMI up LMI enq recvd 0, LMI stat sent 0, LMI upd sent 0 LMI DLCI 0 LMI type is ANSI Annex D frame relay DTE Broadcast queue 0/64, broadcasts sent/dropped 2304560/0, interface broadcasts 2011528 <output omitted> 3640-frame-phoenix#
You must also begin the task of conguring the subinterfaces that are mapped to this new host. Enter the commands in Example 18-51, which specify the appropriate subinterfaces and their corresponding DLCIs. The numbering scheme in this example allows the subinterface to correspond to the DLCI of the PVC.
Example 18-51 These Commands Allow Conguration of the Subinterface. It Is a Good Idea to Create These
Subinterfaces from a Text File Template

interface Serial1/0:0.100 point-to-point description fr 56k frame to johnsmith ip unnumbered loopback1 frame-relay interface-dlci 100 ! interface Serial1/0:0.101 point-to-point description 56k frame to nshumpar ip unnumbered loopback1 frame-relay interface-dlci 101 ! interface Serial1/0:0.102 point-to-point description 128k frame to okaabipo ip unnumbered loopback1 frame-relay interface-dlci 102 ! interface Serial1/0:0.103 point-to-point description 56k frame to djohnson ip unnumbered loopback1 frame-relay interface-dlci 103
583
Further in this example, Loopback1 provides addressing for the subinterfaces (see Example 18-52).
Example 18-52 Interface Loopback1 Provides a Routing Pointer for the Endpoints and Conserves Address Space
3640-frame-phoenix#config terminal 3640-frame-phoenix(config)# interface Loopback1 3640-frame-phoenix(config-if)# description Vendor M Frame Relay address placeholder 3640-frame-phoenix(config-if) ip address 10.10.0.1 255.255.255.252
This loopback interface allows communication with the rest of the network as it forwards trafc to the connected serial and Ethernet interfaces.
Routing Options
Based on the assumption that no readdressing is going to be performed and that the new environment will mirror the old, two approaches can be taken with respect to routing.
Method 1: Moving Routes with Ethernet Interface in Shutdown State

This method requires the Ethernet interface to be administratively shutdown. A console must be set up on the Phoenix router to bypass the Ethernet interface, which should be shut down to avoid any adverse routing consequences that might result from having both routes in different locations. After all the subinterfaces are created and the Ethernet interface is administratively shut down, it is a good idea to copy and paste the IP routes from one router to another. When the transition is complete, the Ethernet interface can be turned up to allow routes to be forwarded if necessary.
Method 2: Host by Host Migration

If a previous method creates too much downtime, it is also possible to enter the routes individually as they are migrated. They must also be removed from the router in Austin. This method brings the users up as soon as the route statement is placed in the Phoenix router. The decision on which method to use is subjective because it depends on the window of time necessary to migrate the remote users. If the rst method is used, the larger the number of endpoints, the longer the downtime for users as the migration proceeds. After the subinterfaces are ready, the task of migrating the remote users can begin.
584
Endpoint Migration
The host is now ready and work can begin on migrating the endpoints to this new circuit. The endpoint serial conguration for a 56-k frame line is similar to Example 18-53.
Example 18-53 These Are the Common Command Entries to Congure Endpoint Routers
1602-frame#config terminal 1602-frame(config)# interface Serial0 1602-frame(config-if)# no ip address 1602-frame(config-if)# encapsulation frame-relay IETF 1602-frame(config-if)# service-module 56k clock source line 1602-frame(config-if)# service-module 56k network-type dds 1602-frame(config-if)# frame-relay lmi-type ansi !
The subinterface on 1602 can be congured with an unnumbered interface to conserve IP addresses (see Example 18-54).
Example 18-54 Subinterface Conguration Commands for Endpoint Routers
1602-frame#config terminal 1602-frame(config)# interface Serial0.1 point-to-point 1602-frame(config-if)# ip unnumbered Ethernet0 1602-frame(config-if)# frame-relay interface-dlci 16
To congure a new subinterface, you must use the same commands with a different DLCI. Following the numbering guidelines given to the vendor, the task of conguring new subinterfaces can begin. To congure a new subinterface for the DLCI that is mapped to the host in Phoenix, you can enter the commands in Example 18-55. End with CNTL/Z.
Example 18-55 New Conguration Commands for the Endpoint Router
1602-frame# configure terminal 1602-frame(config)#interface serial0.100 1602-frame(config-if)# ip unnumbered Loopback 1 1602-frame(config-if)# frame-relay interface-dlci 100 1602-frame(config-if)# end 1602-frame#
Perform a show interfaces command to make sure that the line is operational and has been turned up by the vendor (see Example 18-56). After it is veried that the PVC is up, the routing should be changed to the new line. For example, assuming static routes, the routing accounts for a default route to the host network, and one back to the remote network. Example 18-57 shows the conguration for the existing network.
Summary
585
Example 18-56 Verifying Proper Conguration and PVC Establishment

1602-frame# show interfaces serial0.100 Serial0.100 is up, line protocol is up Hardware is QUICC Serial (with onboard CSU/DSU) Interface is unnumbered. Using address of Ethernet0 (10.84.5.105) MTU 1500 bytes, BW 56 Kbit, DLY 20000 usec, reliability 255/255, txload 1/255, rxload 1/255 Encapsulation FRAME-RELAY 1602-frame#
Example 18-57 Endpoint and Host Routing Conguration

1602-frame#configure terminal 1602-frame(config)# ip route 0.0.0.0 0.0.0.0 Serial 0.1 1602-frame(config)# ip route 10.10.10.0 255.255.255.248 Ethernet0
To migrate this service over the new PVC, a simple routing command must be entered to the core router conguration to complete the migration of this PVC:
3640-frame-phoenix(config)#ip route 10.10.10.0 255.255.255.248 Serial 0.100
By entering this command, you can now route data over the new PVC rather than the old. If the route statements already exist in the Phoenix host, this service is now operational. The default routes for the old host are replaced in favor of routes to the new host. Additionally, routes from the Austin router must be removed prior to reenabling the interfaces. Now, the Austin router is ready to be decommissioned. If Method 1 is used to migrate, after all the remote users are moved over, the routes can be removed from the Austin router, and the Ethernet interface for Phoenix can be turned up to advertise the new routes in a different location. As long as the routes are placed in the new host, the endpoint is reachable from the new location.
Summary
The focus of the scenarios in this chapter is troubleshooting Frame Relay connections. The scenarios focused on end-user issues, particularly the following:
New install issues Mismatch DLCI settings Performance issues Flapping lines Trafc shaping issues
586
For trafc shaping issues and IP Multicast issues in Frame Relay, you can see that there are also advantages to troubleshooting in enterprise portions of the connection. You need to understand both sides of the connection. The last scenario covers Frame Relay host migration. It gives a clear example for engineers who want to rehost the service from one location to another, where because of the permanent nature of PVCs, some troubleshooting situations might arise.
PART
VPN
Chapter 19 VPN Technology Background Chapter 20 Remote Access VPN Design and Conguration Solutions Chapter 21 Remote Access VPN Troubleshooting Chapter 22 Remote Access VPN Troubleshooting Scenarios Appendix A Answers to Review Questions
CHAPTER
19
VPN Technology Background

A Virtual Private Network (VPN) involves transmitting private data over public networks. It is not a new term for data communications. The term VPN initially came from the specic carriers design, where a part of the carriers network (referred to as a cloud) is separated from other parts and is leased by an enterprise for purposes of voice, data, and video communications (see Chapter 3, The Cloud, for more information). Today, VPN is more like a wire in the cloud type of connection, which is explained in this chapter. Understanding VPN and its complexities is more challenging than for most other technologies on the market because of the many complex mathematical algorithms, and the wide range and types of both deployed and emerging solutions. In this chapter, you learn about service provider-based VPNs and enterprise VPNs, and their classications and categories. The focus of this book is on remote access solutions, so information on service provider VPNs is provided solely for the purpose of discussion. The main topics of the chapter are related to the overview and classication of the existing industry VPN solutions; however, the main focus is on IP Security (IPSec). The chapter presents a concise description of the following topics:
Service provider VPNs Enterprise VPNs VPNs on the data link layer and on the network layer of Open System Interconnection (OSI) IPSec and security associations IPSec modes and protocols Key exchange, hashing, and encryption in IPSec
Service Provider, Dedicated, and Access VPNs

In the old world, service providers emphasized lower-layer transport services, such as leased lines and Frame Relay. In the new world, service providers work with business customers to meet their networking requirements through the use of VPNs. The service provider VPNs, otherwise called provider dependant VPNs, are one of the key technologies
592
Chapter 19: VPN Technology Background
that service providers will use to stay competitive in the years ahead. VPNs deliver enterprise-scale connectivity that is deployed on a shared infrastructure with the same policies that are deployed in a private network. A VPN can be built on the Internet or on a service providers IP, Frame Relay, or Asynchronous Transfer Mode (ATM) infrastructure. Today, this solution is known as a dedicated VPN. It is related to legacy VPNs, and is built on virtual leased lines. Another service offering is called Remote Access to Multiprotocol Label Switching Virtual Private Network (RA to MPLS VPN), 1 which enables remote users to connect to the corporate network. This service handles remote access connectivity for mobile users, telecommuters, and small ofces through dial, ISDN, DSL, cable, and wireless technologies. This solution is also known as an access VPN. It is shown in Figure 19-1.
Figure 19-1 The Service Provider Virtual Private Network (VPN)
Application Hosting
Cisco VPN Solution Center
VPN 34 VPN 97 Internet MPLS or IPSec Backbone IPSec
SOHO
Secure Extranet IPSec/L2TP or PPTP IPSec or MPLS Partner B Partner C Partner A
Secure Remote Access
From the standpoint of the service provider, the MPLS is typically a full or partial mesh or hub and spoke topology, depending on how the customer wants to connect their sites. From the standpoint of the potential user, MPLS is typically offered by a service provider as a site-to-site VPN service. The provider builds a private IP-based network, and offers multiple customers IP connectivity between their sites across this network. The technology allows individual customers to view the MPLS service as if they had a private IP network connecting their sites. This scenario offers customers the same advantages of a Layer 2
Enterprise VPNs Overview
593
private network, such as Frame Relay or ATM, but with the scalability and the manageability of a Layer 3 network. Also, because MPLS runs across a private IP-based network rather than the Internet, the service provider can provide differentiated levels of service (quality of service [QoS]) and service-level agreements (SLAs) to its customers. However, because MPLS is based on a service providers private network, the reach of the service is limited to locations where the provider operates. The RA to MPLS VPN solution provides exible options to the existing MPLS VPN. Currently, a service provider can create a scalable and efcient VPN across the core of its network for each customer with MPLS VPN through dialup, DSL, and Data-over-Cable Service Interface Specications (DOCSIS).
NOTE
In January 2002, Cisco received notication that its uBR7246VXR Universal Broadband Router passed CableLabs qualication for DOCSIS 1.1. Based on this qualication, the Cisco uBR7246VXR is the rst Layer-3 routed cable modem termination system (CMTS) to receive DOCSIS 1.1 qualication.
With the introduction of RA to their MPLS VPN service, the service provider can now integrate various additional access methods into their VPN services. This permits the service provider to offer an extended bundle of end-to-end VPN service to its Internet service provider (ISP) or enterprise customers. Major new directions are new media, such as wireless and satellite, and multiprotocol VPNs. The newly announced Cisco Any Transport Over MPLS (AToM)2 integrates Layer 2 tunneling and MPLS networks. By using IP-based MPLS with IPSec/Layer 2 Tunnel Protocol (L2TP) solutions, providers can create virtual leased lines that improve scalability, and implement QoS features that are typical for MPLS.
Enterprise VPNs Overview

Provider-independent or enterprise VPNs provide connectivity that is deployed on a shared (public) infrastructure with the same policies as a private network, where users expect the same or similar performance, applications, and connectivity. Cisco classies existing solutions into three major VPN types (see Figure 19-2):
Cisco remote access VPN solutions Cisco site-to-site VPN solutions Cisco extranet VPN solutions
594
Figure 19-2
Major Cisco VPN Types
Extranet Business Partner Mobile User Remote Users POP Internet DSL Cable Home Telecommuter
VPN
Central Site
Site-to-Site Remote Office
Remote access and site-to-site VPN solutions provide an alterna-tive to building a carrierbased private network for enterprise communication. Companies can cost-effectively extend the corporate network to locations that might not have been justied before because they operate across a shared infrastructure rather than a private network. For example, in many domestic applications and most international applications, VPNs provide signicant cost savings over private wide-area network (WAN) connections. Also, rather than having multiple independent circuits terminating at the corporate headend, VPNs allow all trafc to be aggregated into a single connection. This scenario usually results in increased bandwidth and cost savings at the headend, and further savings is achieved from not having to maintain a private network. VPNs provide the opportunity for additional cost reduction both within and external to the company. The Internet, as a super-medium, allows the enterprise to change the way its networks operate in the following key directions:
For intranets, most companies, especially large enterprises, maintain costly WANs. It remains to be seen if the constant cost reductions of dedicated leased lines can compete with the VPNs potential cost savings. For extranets, the recent solution for large businesses and their business partners require dedicated lines, or slow legacy connections. VPN over the Internet should be seriously considered as an alternative. For remote access, rather than using slow dialup links, or more costly services, such as ISDN and Frame Relay, full-time and part-time telecommuters can take advantage of VPN technology through the following: Higher-speed access from DSL and cable services offered by local providers
Enterprise VPN Categories
595
ISDN, dial, Frame Relay, or FT1 as a local service that is offered by the local exchange carrier (LEC) with at rate pricing Mobile users can also take advantage of higher-speed Ethernet connections found in many hotels, airports, and convention centers for access to the enterprise network through the Internet and VPN. The cost savings alone, from not having to pay long-distance telephone charges, might justify the use of VPNs in such cases. Another benet of VPN is that companies can take advantage of the technology to enable new applications and business processes, such as e-commerce, supply chain management, and virtual ofce concepts. The Internet, as a supermedia, is not an all-purpose remedy or alternative. Some key components, such as security, QoS, reliability, and manageability are some of the factors currently limiting it from becoming a super-alternative.

Every new technology requires some type of classication to distinguish it from a wide variety of solutions, proposals, and views. Cisco classies the existing variety of VPN solutions into two main categories:
Functional, which emphasizes the particular design consideration of the VPN Technological, which denes VPN solutions based on the OSI-layered structure and protocol suites for every layer
Functional VPN Categories

The three Cisco enterprise functional groups are remote access VPN, site-to-site VPN, and rewall-based VPN solutions. Each is discussed in the following sections.
NOTE
Each VPN classication has distinguishing features. Other valid classications of VPNs are remote access VPNs, intranet VPNs, and extranet VPNs. As noted in the article, SAFEguard for Smaller Networks (Cisco Packet, Q1, 2002), Cisco SAFE categories include 800 series access routers, 1700 series modular routers, PIX rewalls, 3002 VPN Hardware Clients, the VPN Software Client, and the Intrusion Detection System (IDS).
Remote Access VPNs

Remote access VPNs refer to implementations for individual remote users that are running the VPN client software to access the corporate intranet through a gateway, or VPN concentrator, which is also referred to as a server. For this reason, this solution is often called a client/server solution, where telecommuters or mobile users can use traditional
596
methods to start tunnels back to the corporation. These methods include dialup connections to a local service provider or the use of any high-speed or broadband service. The Cisco last-mile solution, called Ethernet to the First Mile (EFM) (see Ciscos 575 LRE customer premises equipment (CPE) and Cisco last-mile solutions in Chapter 3), when it becomes available, might change the way remote access VPNs are designed. Another relatively recent development in remote access VPNs is the wireless remote access VPN (see Ciscos Aironet product series), where a mobile worker accesses the corporate network through a wireless connection on a personal digital assistant (PDA). In this design, the wireless connection needs to connect to a wireless termination point and then to the corporate wired network at the remote location. In all cases, the client software on the PC or PDA provides a secure connection, referred to as a tunnel, back to the corporate network. An important part of this solution is the design of the initial authentication, which is designed to ensure a request to establish a tunnel from a trusted source. Usually, this initial phase relies on the same authentication security policies and remote access controls to access corporate resources, including procedures, techniques, and servers (such as Remote Authentication Dial-In User Service [RADIUS], Terminal Access Controller Access Control System Plus [TACACS+], and so on).
Site-to-Site or LAN-to-LAN VPN

Site-to-site or LAN-to-LAN VPN refers to implementations where the network of one location is connected to the network of another location through VPN. In this situation, the initial authentication process for trusted users is between devices on the network, where an initial VPN connection is established between them. These devices then act as gateways, securely passing trafc destined for the other site. Routers or rewalls with VPN capability, and dedicated VPN concentrators all provide this functionality. LAN-to-LAN VPNs can be considered as intranet or extranet VPNs, from the policy management point of view. If they are under one authority, it can be considered an intranet VPN; otherwise, they are considered as an extranet. Access between sites should be tightly controlled by both entities at their respective sites. The site-to-site solution is not a remote access solution, but was added here for completeness. The distinction between remote access VPNs and LAN-to-LAN VPNs is rather symbolic, and it is provided solely for the purposes of further discussion. One example is the new hardware-based VPN devices (see the Cisco 3002, described later), where this classication can be interpreted both ways because the hardware-based client can appear as if a single device is accessing the network, although there might be a network with several devices behind the VPN device. Another example includes the extension-mode of the EzVPN solution, by using 806 and 17xx routers.
597
Firewall-Based VPNs
Firewall-based VPNs are solutions where either the enterprises security organization owns both the rewall and VPN implementation, or service providers offer enhanced rewall systems to support VPN services. In general, they are based on the Cisco PIX series rewalls, including the PIX 506 for small ofce, home ofce (SOHO) environments, the PIX 515 for small- to medium-sized businesses, and the PIX 525 and 535 for enterprise and service provider implementations. Cisco provides several remote access solutions for VPN clients. These solutions meet different enterprise requirements and are designed for each of the covered functional groups. These solutions include the following:
Concentrator-based VPN clientsCisco VPN Client 3.x.x and the VPN 3002 software and hardware client Cisco IOS(router)-based VPN solutionsCisco 806 and 17xx end-user routers, and EzVPN Cisco PIX rewall-based solutionsCisco PIX 501
Another view of Cisco VPN solutions from a software-hardware point of view is as follows (for more details on what operating systems are supported, see www.cisco.com): Software clients: VPN client for Microsoft VPN client for Solaris VPN client for Linux VPN client for wireless devices
Hardware clients: Easy VPN VPN 3002 806 Router PIX 501
The introduction of the PIX 501 VPN solution expands the available choices for the remote user. The hardware options are further dened in Table 19-1. The full list of available VPN 3000 concentrator series products can be found under www.cisco.com/univercd/cc/td/doc/ pcat/3000.htm#xtoc1d7.
598
Table 19-1 VPN Group
Cisco Enterprise VPN Options Large Enterprise VPN 3060 VPN 3080 Concentrators 7200 7100 Medium Enterprise VPN 3030 Concentrators Small Enterprise Branch VPN 3015 VPN 3005 Concentrators 7100 3600 3600 2600 1700 800 900 SOHO 3002 Hardware Client VPN Software Client
Cisco remote access VPN 3000
Site-to-site IOS router
Firewall-based VPN PIX rewall
PIX 535 PIX 525
PIX 525 PIX 515
PIX 515 PIX 506
PIX 501
NOTE
Recently, Cisco announced a comparative approach for classifying remote access VPNs that is based on key element ratings. The key elements are resiliency, scalability, client OS support, management, identity, and a consolidated solution. This classication is more suitable for practical purposes and better reects the functional category.
Technology Category
From a technology perspective, VPN is not running special types of electrons over the shared switch or network, but it is running packets over networks, which are encrypted and authenticated in a way that distinguishes them from other packets. Often, this is associated with a tunnel in the network. Earlier solutions included the physical layer division of the circuits in the carriers switches and main distribution frames (MDFs), which prevents unauthorized access between dedicated lines for separate enterprises, and creates a VPN. Later solutions included implementing the Secure Socket Layer (SSL) protocol for web browsers and other applications, which enables every application to be protected and provides application condentiality. This is an encryption VPN solution that resides on the application layer of the Transmission Control Protocol/Internet Protocol (TCP/IP) suite. But in the OSI seven-layer model, the presentation layer is responsible for translation, encryption/decryption, authentication, and compression. To prevent confusion, it is most appropriate to refer to this solution as an upper-layer encryption (see Figure 19-3).
599
Figure 19-3
The Layered Models and Encryption

Application Upper Layer Encryption Application Desktop Computer Desktop Computer VPN Concentrator Laptop Computer Presentation Session Process TELNET, FTP, SMTP
Laptop Computer
Network Layer Encryption
TCP AND UDP
Transport
Host-to-Host TCP UDP Internet IP
IP
Network
Data Link Link Layer Encryption Physical TCP/IP Protocol Suite
Data Link Physical OSI Model
Network Access Ethernet ARP FDDI DoD Model
For years, military implementations have used hardware-based link-layer encryption that addresses authentication concerns differently. Every termination of a communication link is protected with end devices. Although it ensures security protection, this solution is difcult to manage and almost impossible to implement in a large-scale public network.
Data Link Layer VPNs

In the public network environment, data-link encryption can be implemented in devices within the private network; however, users must encrypt the trafc before it enters the router or switch. Obviously in this scenario, the trafc must be either bridged or encrypted/ decrypted at every hop because the second layer does not provide a unique IP-type addressing scheme. As a result, the data (frames) needs to be encrypted/decrypted several times, which results in increased latency and concerns about trusted providers. ATM and Frame Relay networks are sometimes referred to as VPN networks because they use a shared infrastructure to provide private network services to a large number of users; however, they are viewed more as private network implementations. Data-link VPN technologies are designed to run on the second layer of the OSI model and include the following:
Point-to-Point Tunneling Protocol (PPTP) and generic routing encapsulation (GRE) L2TP
600
PPTP and GRE

PPTP is dened by the Internet Engineering Task Force (IETF) in RFC 2637.3 It is designed by Microsoft to enable a low-cost, private connection to a corporate network through the public Internet. The PPTP session can provide a secure connection through the Internet to the corporate network when dialing a local ISPs phone number, or when using an ISDN device. The local call connects into a hardware device (front-end processor [FEP]), which in turn connects to a Windows NT Server through a WAN connection. The FEP connects by transmitting Point-to-Point Protocol (PPP) packets from the end user, and tunneling them through the WAN. Because PPTP supports multiple protocols (IP, Internetwork Packet Exchange [IPX], and Network Basic Input/Output System Extended User Interface [NetBEUI]), it can access a wide variety of existing LAN infrastructures. This architectural description includes a typical client/server architecture, where the client is the remote users PC, running PPTP. On the server side, there is a dial-in router, VPN concentrator, or actual application server. Both sides can start a tunnel. When the remote user starts the tunnel, it is called voluntary mode. When the tunnel is started by the network access server (NAS), it is often referred to as compulsory mode. A NAS can start a tunnel even if the remote user is not running PPTP, which raises security concerns and it is not recommended. The PPTP encapsulates PPP frames into IP datagrams for transmission over an IP-based network, such as the Internet or a private intranet. PPTP, which is derived from the PPP protocol, inherits the encryption, compression, or both from the PPP protocol. PPTP requires the availability of an IP internetwork between a PPTP client (a VPN client using the PPTP tunneling protocol) and a PPTP server (a VPN server using the PPTP tunneling protocol). The PPTP client might already be attached to an IP internetwork that can reach the PPTP server, or the client might dial into a NAS to establish IP connectivity, as in the case of dialup Internet users. PPTP uses a TCP connection (known as the PPTP control connection) to create, maintain, and terminate the tunnel. PPTP also uses a modied version of GRE to encapsulate the PPP frames as tunneled data. The payloads of the encapsulated PPP frames can be encrypted, or compressed, or both. GRE is dened in RFCs 1701 and 1702, and is simply a mechanism for performing encapsulation of an arbitrary network layer protocol over another arbitrary network layer protocol. It was designed to provide a simple, lightweight, general-purpose mechanism for encapsulating data sent over IP networks. Therefore, PPTP can transport various Layer 3 protocols, such as IP, IPX, and NetBEUI. PPTP assumes the availability of an IP internetwork between a PPTP client and a PPTP server. The client might already be attached to an IP internetwork that can reach the server, or the PPTP client might dial into a NAS to establish IP connectivity, as in the case of dialup Internet users.
601
Authentication that occurs during the creation of a PPTP-based VPN connection uses the same authentication mechanisms as PPP connections, such as Password Authentication Protocol (PAP) and Challenge Handshake Authentication Protocol (CHAP), which are not considered particularly strong. PAP sends passwords across the link in clear text and is not secure. CHAP is considered more secure than PAP because CHAP issues an encrypted challenge to which the other side must respond to authenticate. An enhanced version of CHAP, called MS-CHAP, was created by Microsoft to use information within NT domains for security. Another option for authentication is IETFs PPPExtensible Authentication Protocol (EAP) (refer to RFC 2284). Microsoft has also incorporated a protocol called Microsoft Point-to-Point Encryption (MPPE)4 to encrypt the trafc across a PPTP link. MPPE is based on the Rovest, Shamir, and Adelman (RSA) RC4 encryption algorithm and provides only link encryption, not end-to-end encryption. Endto-end encryption is data encryption between the client application and the server that is hosting the resource or service accessed by the client application. If end-to-end encryption is required, IPSec can encrypt IP trafc from end-to-end after the PPTP tunnel is established. For Windows 2000, either EAP-Transport Level Security (EAP-TLS) or MS-CHAP must be used for PPP payloads to be encrypted using MPPE. PPTP Control Connection and Tunnel Maintenance The PPTP control connection is between the IP address of the PPTP client that is using a dynamically allocated TCP port, and the IP address of the PPTP server that is using the reserved TCP port 1723. The PPTP control packet (called a connection packet) carries the PPTP call control and management messages that maintain the PPTP tunnel (see Figure 19-4).
Figure 19-4 PPTP Control Connection Packet Format
Data Link Header
IP
TCP
PPTP Control Message
Data Link Trailer
After the initial negotiation, two parties exchange a series of messages that include 12 standard call and connection management messages. For more information about the structure of PPTP control connection messages, see RFC 2637. PPTP Data Tunneling PPTP data tunneling is performed through multiple levels of encapsulation. The structure is shown in Figure 19-5. The initial PPP payload is encrypted and encapsulated with a PPP header to create a PPP frame. The PPP frame is then encapsulated with a modied GRE header. GRE uses client protocol ID number 47.
602
Figure 19-5
PPTP Data Tunneling
Data Link Header
IP Header
GRE Header
PPP Header
Encrypted PPP Payload (IP Datagram, IPX Datagram, NetBEUI Frame)
Data Link Trailer
NOTE
For troubleshooting purposes, it is important to remember that PPTP uses the reserved TCP port 1723. The PPTP control connection carries PPTP call control and management messages that maintain the PPTP tunnel. The GRE protocol ID is 47.
L2TP
L2TP is addressed in IETFs RFC 2661 standard. It combines the best features of two existing tunneling protocols: Ciscos Layer 2 Forwarding (L2F) and Microsofts PPTP.5 L2TP is an extension of PPP and is an important component for VPNs. L2TP is considered more scalable than PPTP and it also operates in client-server mode. Similar to PPTP, the L2TP tunnel can be started from the remote PC back to the L2TP network server (LNS), or from the L2TP-enabled access concentrator (LAC) to the LNS (see Figure 19-6). Although L2TP still uses PPP, it denes its own tunneling protocol, depending upon the transport media rather than using GRE.
Figure 19-6 L2TP Architecture Model
PPP Remote User LAC PSTN or ISDN ISP or Public Network L2TP Tunnel LNS Corporate Network
AAA Server (RADIUS/TACACS+)
AAA Server (RADIUS/TACACS+)
603
L2TP can also transport various Layer 3 protocols other than IP, although not all implementations support this feature. L2TP can use PAP, CHAP, and EAP for authentication; however, a major difference is support for the use of IPSec, which can secure trafc all the way from the end users PC to the corporate network. L2TP uses two types of messages: control and data (see Figure 19-7). Control messages are used in the establishment, maintenance, and clearing of tunnels and calls. Data messages encapsulate PPP frames that are carried over the tunnel. Control messages use a reliable control channel within L2TP to guarantee delivery, while data messages are not retransmitted when packet loss occurs.
Figure 19-7 L2TP Protocol Structure
PPP Frames
L2TP Data Messages
L2TP Control Messages
L2TP Data Channel (Unreliable)
L2TP Control Channel (Reliable)
Packet Transport (UDP, FR, ATM, and So On)
PPP frames are passed over an unreliable data channel and are rst encapsulated by an L2TP header, and then by a packet transport such as User Datagram Protocol (UDP), Frame Relay, or Asynchronous Transfer Mode (ATM). Control messages are sent over a reliable L2TP control channel that transmits packets in-band over the same packet transport. Sequence numbers are required in all control messages. The numbers provide reliable delivery on the control channel because the packets can be reordered to detect lost packets. An example for L2TP encapsulation over high-level data link control (HDLC) and IP is shown in Figure 19-8, and a general tunnel structure is shown in Figure 19-9. The L2TP protocol is dened in RFC 2661 and is referred to as L2TPv2. The IETF Extension Group recently released version 3. The new standard includes PPP-related changes and the transition from both a 16-bit session ID and control connection ID, to 32bit IDs. The new RFC 3193 covers Securing L2TP using IPSec, to build private and authenticated PPP connections over the Internet. This feature is already implemented in IOS 12.2(4).T and results in the interoperability between Windows 2000 and XP, and Cisco routers. (The Microsoft version is called L2TP+IPSec.)
604
Figure 19-8
L2TP Encapsulation over HDLC and IP, Where the Maximum Size Is 1500 Bytes (L2TP Encapsulation Is in Dark Gray)
IP Data
PPP
L2TP
UDP
IP
HDLC
1450 Bytes
4 Bytes
6 Bytes
8 Bytes
20 Bytes
7 Bytes
Figure 19-9
The General Tunnel Structure of L2TP

Corporate Network
Remote User
PSTN Cloud
LAC ISP
Internet Cloud
LNS
= LT2P = PPP = IP
The recent developments in the VPN industry are closely related to Layer 3 and especially IPSec tunneling. The following section focuses on this topic.
Network Layer (Layer 3) VPNs

This section covers the following topics:
Layer 3 tunneling Security associations and security policy for Internet Key Exchange (IKE) and IPSec Internet Security Association and Key Management Protocol (ISAKMP) and IPSec phases and modes Mutable and immutable elds and the Integrity Check Value (ICV) Fragmentation, path maximum transmission unit (MTU) discovery, and Internet Control Message Protocol (ICMP) processing IPSec modes IPSec protocols Authentication in VPN
605
Layer 3 Tunneling
Because of the abundance of available literature about Layer 3 tunneling, only a short description is provided in the following sections to cover the basics of the technology. A more in-depth analysis would require a separate book. Layer 3 VPN technologies are designed to run at the network layer of the OSI model. Typically, these VPNs use the IP protocol as the network layer protocol, and they can include Layer 3 VPNs such as Multiprotocol Label Switching (MPLS) or IPSec, which is the IETF standard for encryption and encrypted tunnels. MPLS was covered earlier in this chapter. IPSec on Layer 3 is covered in the following sections. RFC 2764 denes the framework for VPNs running across IP backbones. An IP tunnel operates as an overlay across the IP backbone, and the trafc sent through the tunnel is incomprehensible to the underlying IP backbone. In effect, the IP backbone is used as a link-layer technology, and the tunnel forms a point-to-point connection. Numerous IP tunneling mechanisms exist because Layer 3 tunneling is not a new technology. In fact, GRE with RFC 1701 has existed for a long time. Some protocols were initially not considered as tunneling protocols, such as IP/IP, GRE, and L2TP. Cisco rst supported tunneling technology in Cisco IOS version 9.21, and provided IPSec support in Cisco IOS version 11.3(3)T and later versions. Originally, IPSec was conceived as an extension for IPv4 with added security features. Now, IPSec is a framework of open standards for ensuring secure private communications over IP networks. It is based on an architecture model dened in RFC 2401, which covers the security features and architecture model for IPv4 and IPv6.6 Now, IPSec VPNs use the services dened within IPSec to ensure condentiality, integrity, and authenticity of data communications across public networks.
Security Associations and Security Policy for IKE and IPSec

IPSec operates in a peer-to-peer relationship, rather than a client/server relationship. The security association (SA) is a convention (contract) between two parties that facilitates an IPSec-based conversation between two communicating parties. Each party (device, software client) must agree to the policies or rules of their conversation by negotiating these policies with their potential peer. There are two types of SAs: ISAKMP SAs (also known as IKE SAs) and IPSec SAs (see RFC 2408 and 2409 for more details). The IKE SA is bidirectional and provides a secure communication channel between the two parties that can negotiate further communications. The term bidirectional means that once established, either party can start Quick Mode, Informational, and New Group Mode exchanges. IKE SA is identied by the initiators cookie, followed by the responders cookie, and the role of each party in the Phase 1 exchange dictates what cookie is the initiators. The cookie order established by the phase 1 exchange continues to identify the
606
IKE SA, regardless of its direction. The main function of IKE is to establish and maintain the SAs. The following attributes are a minimal set that must be negotiated as part of the ISAKMP SA:
Encryption algorithm Hash algorithm Authentication method Information about the group required to perform the Dife-Hellman (DH) key agreement protocol
IKE provides negotiation, peer authentication, key management, and key exchange. IKE negotiates a contract between the two IPSec endpoints and the SA keeps track of all elements of the negotiation for a single IPSec session. After the successful negotiation, the active (valid) SA parameters are stored in the SA Database (SAD).
NOTE
To enable ISAKMP functionality, UDP port 500 must be open on the corporate rewalls.
The ISAKMP is strongly tied to policy management, which offers a different level of granularity. The ability to push or change policies on the users CPE from the corporate concentrator is a major feature of the enterprise VPN design. The VPN 3000 Series Concentrator provides a conguration mode, which enables sending the remote user centrally controlled policies including Domain Name System (DNS), Windows Internet Naming Service (WINS), IP Address, and default domain name. This mode also provides functionality for save connection password, split tunneling, local LAN access control, remote access load balancing, centralized protection policy (rewall), personal rewall capability (are you there?), and software update notication. The IPSec SA is unidirectional and is used for the actual communication between devices. Therefore, two-way communication between devices requires at least two IPSec SAs, one in each direction, because IPSec SA is a simplex data connection. For example, when a bidirectional TCP session exists between two systems, A and B, there is one SA from A to B and a separate SA from B to A. If both security protocols, Authentication Header (AH) and Encapsulating Security Payload (ESP), are applied to a unidirectional trafc stream, two SAs are created for the trafc stream.
NOTE
A SA is uniquely identied by an IP destination address, a security protocol (AH or ESP) identier, and a unique security parameter index (SPI) value. A SPI is a 32-bit number assigned to the initiator of the SA request by the receiving IPSec endpoint. The SPIs for AH and ESP are not the same for a given trafc ow. The SPI value is a eld in both the AH and ESP headers, and it identies the appropriate SA for all the communications between the two end nodes. The three elements of a SA allow the receiving party to associate the received packet appropriately.
607
Negotiations of ISAKMP and IPSec Phases and Modes

SAs for both IKE and IPSec are negotiated by IKE over various phases and modes. The terms phases and modes denote the steps involved in establishing an IPSec connection. Key exchange and management is an important part of IPSec because of the number of keys that must be exchanged for parties to communicate securely. Two methods of handling key exchange and management that are specied within IPSec include manual keying and IKE, which is based on ISAKMP/Oakley. IKE provides three modes for exchanging key information and setting up SAs: main, aggressive, and quick modes. The rst two modes are phase 1 exchanges (main and aggressive), which set up the initial secure channelIKE SA. The other mode is the phase 2 exchange (quick), which negotiates IPSec SAs. When identity protection is not required, only the aggressive mode can be used to reduce the time required for negotiation. In ISAKMP, phase 1 occurs when the two ISAKMP peers establish a secure, authenticated channel for communication. Main and aggressive modes each accomplish a phase 1 exchange, and are only related to phase 1. Phase 2 occurs when SAs are negotiated on behalf of services such as IPSec or other services that require key material or parameter negotiation. Quick mode accomplishes a phase 2 exchange and is used only in phase 2. In IPSec, phase 1 IKE negotiates IPSec SAs. Two modes can be used for this phase: main mode is used in the vast majority of situations, and aggressive mode is used under some circumstances, given the particular conguration parameters between the two systems. The aggressive mode is typical for situations when authentication is not necessary, or was already performed earlier. (Cisco VPN Client 3.0.4 mainly uses aggressive mode). The user has no control over what mode is chosen; it is automatic and depends on the conguration parameters set up by both peers. In phase 2, IKE negotiates IPSec SAs and the exchange only uses quick mode. The elements and functions of the IKE and IPSec negotiation, and the differences between modes are shown in Figure 19-10. (Some of the terms are discussed later.)
Figure 19-10 Elements and Functions of IKE and IPSec
IKE SA Lifetime Expires
IKE Main Mode IPSec Lifetime Expires Quick Mode
Hash Encryption Authentication Diffie-Hellman Group SA Lifetime Elements Hash Encryption PFS Group SA Lifetime Mode Elements
Establish SAs Key Material Diffie-Hellman Exchange Protection for IPSec Negotiation Functions Protection via ESP Integrity via AH Request Keys from IKE
IPSec
Functions
608
IPSec SAs terminate through deletion or by timing out. When the SAs terminate, the keys are discarded. When subsequent IPSec SAs are needed for ow, IKE performs a new phase 2 and, if necessary, a new phase 1 negotiation. A successful negotiation results in new SAs and new keys. New SAs can be established before the existing SAs expire, so a given ow can continue uninterrupted.
Mutable and Immutable Fields and the ICV

One of the services of IPSec is to provide access control and data integrity, so that no one can change any bits in the packet exchange between the two parties. The service, called connectionless data integrity, ensures that the original IP packet is not modied in transit from the source to the destination. However, any packet to be routed can undergo several transformations (changes to the content) to be delivered to the destination. The ability to read the header of packets for routing purposes, while maintaining security of the data, is a controversy that is addressed by the calculation of the ICV. The ICV is a keyed hash that uses a shared secret value. The computation uses IP header elds that are either immutable in transit or that are predictable in value upon arrival at the endpoint for the SA. The upper-layer protocol data is assumed to be immutable in transit. For the purposes of this computation, the IP datagram elds are divided into three groups: immutable, mutable but predictable, and mutable. Figure 19-11 shows the original IPv4 packet and the breakdown. The IP datagram is a variable-length packet that can be split into two major parts: the header (20-60 bytes), and the total size of 20-65,536 bytes. The header is designed in a way to provide the necessary information for delivery and routing.
Figure 19-11 Mutable and Immutable Fields of IPv4 (The Mutable Fields Are in White, the Destination IP Address Is in Light Gray, and the Immutable Fields Are in Dark Gray)
Size of IP Datagram 20-65,536 Bytes
Header 20-60 Bytes
HLEN Type of Service (ToS) - 8 Bits 4 Bits Identification Flags 16 Bits 3 Bits Protocol Time To Live (TTL) 8 Bits 8 Bits Source IP Address Destination IP Address OPTIONS + Padding Data (Variable)
VER 4 Bits
Total Length 16 Bits Fragmentation Offset 13 Bits Header Checksum 16 Bits
609
Note the following about Figure 19-11:
VersionThe rst 4 bits are the version. The IPv4 uses 0100 in this eld. Header length (HLEN)The value is provided to help calculate the length of the header because IP is a variable length. To determine the length, you must multiply by 4 because with 4 bits, a maximum of four 1s (15) can be coded. Therefore, 15 4 = 60 is the maximum HLEN. Type of service (TOS)Identies how the datagram should be handled (normal delay, throughput, reliability). This eld is mutable because some routers are known to change the value of this eld, even though the IP specication does not consider TOS to be a mutable header eld. Total lengthSpecies the length, in bytes, of the entire IP packet, including the data and header. It is a 2-byte eld, which can code a maximum size of 216 = 65,536 bytes. IdenticationThis eld is used for fragmentation. To pass large packets through networks with different MTUs, the packet must be fragmented. It identies the sequence number. FlagsThis is a 3-bit eld of which the low-order (least signicant) 2 bits control fragmentation. The 3 bits are dened as follows: Low-order bit species whether the packet can be fragmented. Middle bit species whether the packet is the last fragment in a series of fragmented packets. High-order bit is not used. The eld is mutable because an intermediate router might set the Dont Fragment (DF) bit, even if the source did not select it.
Fragmentation offsetProvides the offset of the data in the original packet. The eld is mutable because AH is applied only to non-fragmented IP packets; therefore, the Offset Field must always be 0 and is excluded (even though it is predictable). Time To Live (TTL)If the destination is not reached, it denes the number of hops/ seconds that the packet can travel before being discarded. Every hop decrements the initial value by 1, so when the eld contains 0 and the destination is not yet reached, the packet is discarded. The eld is mutable because it changes due to the normal processing by routers, and therefore its value at the receiver end is not predictable by the sender. ProtocolContains information for the upper-layer protocols that are encapsulated in IP. For example, the protocol ID for UDP is 17, and for TCP, it is 6. Header checksumThis 16-bit eld checks the integrity of the header. It is a mutable eld because it changes if any of the other elds change, and therefore, its value cannot be predicted by the sender. Source IP addressThis is a 32-bit IP address.
610
Destination IP addressThis is a 32-bit IP address for the destination. It is mutable but predictable with loose or strict source routing. OptionsFor IPv4 (unlike IPv6), there is no mechanism for tagging options as mutable in transit. As a result, the IPv4 options are explicitly listed and classied and the entire option is viewed as a unit. So, even though the type and length elds within most options are immutable in transit, if an option is classied as mutable, the entire option is zeroed for ICV computation purposes.
Fragmentation, Path MTU Discovery, and ICMP Processing

The fragmentation in VPN, path MTU discovery, and IPSec-related ICMP messages are discussed in detail in RFC 2401, Security Architecture for the Internet Protocol. Some other studies, such as IETF MTU Discovery Working Group, and in particular RFC 1191, propose a technique for dynamically discovering the MTU of an arbitrary Internet path. The fragmentation of the IP datagrams, if required, occurs after IPSec processing within an IPSec implementation. Thus, transport mode AH or ESP is applied only to entire IP datagrams (not to IP fragments). An IP packet to which AH or ESP has been applied can itself be fragmented by intermediate routers, but such fragments must be reassembled prior to IPSec processing at a receiver. In tunnel mode, AH or ESP is applied to an IP packet, the payload of which can be a fragmented IP packet. Of course, the ofcial minimum MTU (see RFC 791) can process the IP packets, but that would be wasting Internet resources in most cases. In fact, this results in the use of smaller datagrams than necessary because many paths have a Path MTU (PMTU) greater than 576. Furthermore, current practice does not prevent fragmentation in all cases because some paths PMTU is less than 576. These realities essentially emphasize the importance of the fragmentations and related MTU issues. The key suggestion here is that when one IP host has a large amount of data to send to another host, the data is transmitted as a series of IP datagrams. It is usually preferable that these datagrams be of the largest size that does not require fragmentation anywhere along the path from the source to the destination. This datagram size is referred to as the Path MTU (PMTU), and it is equal to the minimum of the MTUs of each hop in the path. A shortcoming of the current Internet protocol suite is the lack of a standard mechanism for a host to discover the PMTU of an arbitrary path. 7 The PMTU depends on the different modes and protocols applied to the remote access VPN solution because different protocols and modes add different overhead to the IP datagrams. See the section, IPSec Protocols for more details about IPSec protocols. For the purposes of this explanation, the general format of the datagrams in the tunnel mode, in terms of the TCP/IP stack, look similar to the following. The AH datagram includes the following:
IP2New (second) IP header AH header
611
IP1Original IP header TCP header TCP data IP2New (second) IP header ESP header IP1Original IP header TCP header TCP data ESP trailer
The ESP datagram includes the following:
Information is provided in Chapter 4, Troubleshooting Approaches, Models, and Tools, about using the ping utility and ICMP protocol to perform the reachibility test between two hops in the network. The same ICMP protocol can perform additional functionality about PMTU discovery. The term PMTU Discovery or ICMP PMTU refers to an ICMP message used for PMTU Discovery. The suggested approach in RFC 1191 is based on the interaction between certain unused elds in the ICMP header and the maximum segment size (MSS) eld of the TCP protocol. After the original IP datagram is encapsulated by any of the IPSec protocols, it changes its format. Also, when used with the ICMP protocol, the format changes in the following fashion:
IP3 header (third header, which includes source and destination information) ICMP header (includes PMTU) IP2 header (second header, which includes source and destination information), where: If the protocol is ESP, the minimum of 64 bits includes the security parameter index (SPI) (32 bits), and sequence number (32 bits). If the protocol is AH, the minimum of 64 bits includes the next header (8 bits), payload len (8 bits), reserved (16 bits), and SPI (32 bits).
To make this possible, the ICMP protocol must include the MTU of that next-hop network in the low-order 16 bits of the ICMP header eld that is labeled unused in the ICMP specication. The high-order 16 bits remain unused, and must be set to 0. The format of the ICMP header is shown in Figure 19-12.
612
Figure 19-12 ICMP Header Format

0 Byte 1 Type 3 Byte 2 Code4 Unused = 0 Byte 3 Checksum Next - Hop MTU Byte 4 31
Internet Header + 64 Bits of Original Datagram Data
Another approach to the MTU discovery process is based on a simple suggestion that, regardless of the content of the IP datagram after the IPSec encapsulation (MD5-ESP3DES), the ICMP overhead is always 28 bytes when it is used with ICMP: Type = 0 (Echo reply) and ICMP: Code = 0. For more explanations about approach and how to use it for troubleshooting, see the section, Determining a Functional MTU Between the VPN Host and Concentrator, in Chapter 21, Remote Access VPN Troubleshooting, and Case 4 of Chapter 22, Remote Access VPN Troubleshooting Scenarios. Both solutions provide successful solutions in most cases. However, they can become complicated if you consider some realities in the existing networks. One reality is the blocking of ICMP messages from most providers, or enterprise rewalls. Another obstacle for implementation can be the existence of black hole routers. A black hole router does not return ICMP destination unreachable messages when it needs to fragment a TCP packet with the DF bit set. TCP depends on receiving these messages to perform PMTU Discovery. One possible approach here is to modify the TCP in a way that TCP tries to send segments without the DF bit set, if several retransmissions of a segment go unacknowledged. If the segment is acknowledged as a result, the MSS is decreased and the DF bit is set in future packets on the connection. Enabling black hole detection increases the maximum number of retransmissions performed for a given segment. It is disabled by default in Windows.
IPSec Modes
IPSec provides secure communication between two hosts, from a host to a security gateway, or between two security gateways. A security gateway is a device, such as a router, rewall, or a dedicated VPN concentrator, which provides IPSec services (that is, terminates the IPSec connection) and passes trafc through the tunnel to the other side. IPSec can operate in one of two modes to accommodate different types of connections: transport mode and tunnel mode. With transport mode, the AH or ESP is placed after the original IP header, so only the IP payload is encrypted and the original IP headers are left intact. Transport mode can be used when both end hosts support IPSec. This mode has the advantage of adding only a few bytes to each packet and it also allows devices on the public network to see the nal source and
613
destination of the packet. This capability enables special processing (for example, quality of service) in the intermediate network, based on the information on the IP header. However, the Layer 4 header is encrypted, which limits the examination of the packet (see Figure 19-14 and Figure 19-17 later in this chapter). With tunnel mode, the entire original IP packet is encapsulated within AH or ESP, and a new IP header is placed around it. So, the original IP datagram is encrypted and becomes the payload in a new IP packet. This mode allows a network device, such as a router, to act as an IPSec proxy that performs encryption on behalf of the host. The sources router encrypts packets and forwards them along the IPSec tunnel. The destinations router decrypts the original IP datagram and forwards it on to the destination system. Therefore, the new IP header has the source address of the gateway itself. With tunnel mode operating between two security gateways, the original source and destination addresses can be hidden through the use of encryption. Tunnel mode is used when one or both sides of the IPSec connection are a security gateway and the actual destination hosts behind it do not support IPSec (see Figure 19-15 and Figure 19-18 later in this chapter).
IPSec Protocols
In a TCP/IP environment, IPSec protocols offer security services at the network layer. These services include the following:
Access control prevents unauthorized use of a resource, such as the network behind a security gateway (router, rewall). Authentication service includes the following: Connectionless integrity, which detects any modication to data within individual IP packets, regardless of their position in a data stream. Data origin authentication, which veries the source of the data.
Anti-replay protection (optional) occurs when the sender must increment the sequence number, and the receiver (if this option is chosen) must detect the arrival of the duplicate IP sequence packet number. Condentiality protects data from unauthorized disclosure by using encryption. Limited trafc-ow condentiality occurs by hiding the original source and destination addresses as part of the data when using ESP in tunnel mode.
Because both AH and ESP provide access control, the main decision to make when choosing security services is whether you need authentication or both authentication and encryption. To give you a better feel for the issues surrounding IPSec protocols, the discussion is divided into the following topics:
IP authentication header IP encapsulating security payload
614
IP Authentication Header and RFC 2402

The AH provides connectionless data integrity and data origin authentication as part of the authentication of IP packets. Connectionless data integrity means that the original IP packet was not modied in transit from the source to the destination. AH provides authentication for as much of the IP header as possible, and for upper-level protocol data. However, some IP header elds can change in transit and the value of these elds might not be predictable by the sender, when the packet arrives at the receiver. The values of such elds cannot be protected by AH; therefore, the protection provided to the IP header by AH is not considered strong enough. AH can be applied alone, in combination with the IP ESP, or in a nested fashion. Security services can be provided between a pair of communicating hosts, security gateways, or between a security gateway and a host. ESP can provide the same security services as AH, but it also provides a condentiality (encryption) service. The AH header is shown in Figure 19-13.
Figure 19-13 Authentication Header (AH) Format
First Byte Next Header
Second Byte Payload Length
Third Byte Reserved
Fourth Byte
Security Parameter Index (SPI) Sequence Number Field Authentication Data (Variable)
NOTE
To ensure AH functionality, protocol 51 must be open in the corporate rewalls.
The AH is inserted into the IP packet between the IP header and the rest of the packets contents. It contains a cryptographic checksum of the packets contents, including the parts of the IP header itself that are immutable in transit. Figure 19-14 shows the IP packet before and after applying the AH in transport mode.
615
Figure 19-14 The IP Packet Before and After Applying the AH in Transport Mode
Original IP Header
TCP
Data
Original IP Header
AH
TCP
Data
Authenticated (Except for Mutable Fields)
Figure 19-15 shows the IP packet before and after applying the AH in tunnel mode.
Figure 19-15 The IP Packet Before and After Applying the AH in Tunnel Mode
Original IP Header
TCP
Data
New IP Header
AH
Original IP Header
TCP
Data
Authenticated (Except for Mutable Fields) in the New IP Header
The default cryptographic algorithms for calculating the checksum are hash-based message authentication code (HMAC) coupled with the Message Digest 5 (MD5) hash function, or HMAC coupled with the Secure Hash Algorithm (SHA-1) function. When taking a received message and calculating the same cryptographic checksum, then comparing it with the value received, the receiver can verify that the message has not been altered in transit.
Calculation of ICV in AH
The ICV calculation includes the following components of AH: next header, payload length, reserved, SPI, sequence number, authentication data (which is set to 0 for this computation), and explicit padding bytes (if any) (see Figure 19-13). AH also provides a limited anti-replay service that counters a denial of service (DoS) attack, based on an attacker intercepting a series of packets and then replaying them. It should be noted that the anti-replay service can affect performance, if the network reorders
616
packets to provide higher QoS for certain types of trafc. If the packets arrive outside the anti-replay window, IPSec rejects them. AH is not widely used for IPSec implementations across the Internet because it does nothing to keep the packet contents condential. For condentiality, ESP must be used.
IP ESP and RFC 2406

The ESP header is designed to provide a mix of security services in IPv4 and IPv6. ESP can be applied alone, in combination with AH, or in a nested fashion. Security services can be provided between a pair of communicating hosts, a pair of communicating security gateways, or a security gateway and a host. The ESP objectives reect the ESP header format that is shown in Figure 19-16.
Figure 19-16 ESP Header Format
First Byte
Second Byte
Third Byte
Fourth Byte
Security Parameter Index (SPI) Sequence Number Field Payload Data (Variable) Payload Data (Cont.) Padding (Cont.) [0-255 Bytes] Padding Bytes Pad Length Next Header
Authentication Data (Variable)
NOTE
To enable ESP functionality, protocol 50 must be open in the corporate rewalls.
ESP provides condentiality, data origin authentication, connectionless integrity, an antireplay service (a form of partial sequence integrity), and limited trafc ow condentiality. The set of services enabled depends on the options selected at the time of SA establishment. The ESP header is inserted after the IP header and before the upper-layer protocol header (in transport mode), or before an encapsulated IP header (in tunnel mode). Figure 19-17 shows how the IPv4 packet is modied in transport mode, and Figure 19-18 shows the IPv4 packet transformation in tunnel mode. Condentiality in ESP is achieved through encryption. Encryption is the process of taking a clear text message, and passing it through a mathematical algorithm to produce what is known as ciphertext. Decryption is the reverse process. Encryption algorithms typically rely on a value, called a key, to encrypt and decrypt the data.
617
Figure 19-17 The IP Packet Before and After Applying the ESP in Transport Mode
Original IP Header
TCP
Data
Original IP Header
ESP Header
TCP
Data
ESP Trailer
ESP Auth.
Encrypted Authenticated
Figure 19-18 The IP Packet Before and After Applying the ESP in Tunnel Mode
Original IP Header
TCP
Data
New IP Header
ESP
Original IP Header
TCP
Data
ESP Trailer
ESP Auth.
Encrypted Authenticated
Two major forms of encryption are used today: symmetric encryption (also known as shared-key encryption) and asymmetric encryption (know as public/private key encryption). Symmetric encryption is approximately 1000 times faster than asymmetric encryption, and is therefore used for the bulk encryption of data. Generally, with welldesigned encryption algorithms, longer keys result in a higher degree of security because more brute force is required to try every possible key (known as the key space) to decrypt a message. ESP supports a variety of symmetric encryption algorithms for data encryption. The Data Encryption Standard (DES) is the default algorithm that uses a 56-bit key and has been in use for about 20 years. However, DES has been susceptible to brute-force attacks, so Triple DES (3DES) is now the standard algorithm recommended for most business use because it encrypts the data three times with up to three different keys. ESP encrypts the higher-level
618
protocol information (such as the TCP header) and the actual data itself. The authentication services of ESP do not protect the new IP header of the packet. On May 26, 2002, the Advanced Encryption Standard (AES) became a nalized Federal Information Processing Standard (FIPS)-approved cryptographic algorithm for purposes of protecting transmissions of electronic data (see FIPS PUB 197). AES is a new, faster, and more secure standard encryption algorithm, and it is being considered by Cisco for future two-phase implementations. The rst phase includes the software (IOS) version and the second phase includes the hardware version. AES is expected to be considered as a baseline functionality in mid 2002 and early 2003, and VPN solutions and devices without highspeed AES support will not be considered for many VPN deployments. The underlying algorithm for AES is called Rijndael. AES species three key sizes: 128, 192, and 256 bits. In decimal terms, this indicates that there are approximately the following:
3.4 1038 possible 128-bit keys 6.2 1057 possible 192-bit keys 1.1 1077 possible 256-bit keys
In comparison, DES keys are 56-bits long, which indicates that there are approximately 7.2 1016 possible DES keys. Hence, there are on the order of 1021 times more AES 128-bit keys than DES 56-bit keys. For more information, see the article, AES an Approved Cryptographic Algorithm (Cisco Packet Magazine, Q3 2002; also available at www.cisco.com/warp/public/784/packet/standards.html).
NOTE
In the late 1990s, specialized DES Cracker machines were built that could recover a DES key after a few hours. Assuming that someone could build a machine that could recover a DES key in a second (that is, try 255 keys per second), it would take that machine approximately 149 trillion years to crack a 128-bit AES key. To put this in perspective, the universe is believed to be less than 20 billion years old.
The anti-replay service can be used only if data origin authentication is selected, and its election is solely at the discretion of the receiver. However the default requires the sender to increment the sequence number used for anti-replay, and the service is effective only if the receiver checks the sequence number. Trafc ow condentiality requires the selection of tunnel mode, and it is most effective if implemented at a security gateway, where trafc aggregation can mask true source-destination patterns. Although both condentiality and authentication are optional, at least one must be selected. Most IPSec VPN implementations today use ESP.
619
Calculation of ICV in ESP

If authentication is selected for the SA, the ICV calculation includes the following components: SPI, sequence number, payload data, padding (if present), pad length, and next header. In general, the sender computes the ICV over the ESP packet, except for the authentication data. The last four elds are in ciphertext form because encryption is performed prior to authentication.
Authentication in VPN
Authentication in VPN has several aspects that include the following:
Client authentication, VPN group name, and group password User/identity authentication Key management, DH algorithm, and methodology Cisco and IPSec message authentication (integrity) and condentiality
The text discusses each in turn.
Client Authentication, VPN Group Name, and Group Password

The group name and group password approach simplies policy enforcement because a user can be a member of a group of users who have common policy requirements. For example, a single change can be made to a group that affects hundreds of users versus making changes for every single user. Groups and users are core components in managing the security of VPNs, and in conguring the Cisco VPN 3000 Concentrator. They have attributes that determine their access to and use of the VPN. Users are members of groups and groups are members of the base group. Users inherit attributes from groups and groups inherit attributes from the base group. The VPN client can be congured with an active group name and group password to provide a user prompt, and be authenticated by a RADIUS server if the Group Lock feature on the concentrator is turned on. Groups simplify system management. By conguring the base group rst, then specic groups, and nally users as members of groups, you can quickly manage access and usage rights for large numbers of users. Associating users with specic groups simplies the conguration of the VPN, while providing granular control over who has access to certain resources. When conguring groups and users, only the attributes that differ from those dened in the base group need to be dened and all other attributes are inherited from the base group. The group name and group password for VPN users are stored locally on the concentrator or server. When the client tries to connect to the concentrator, it has to provide the same group name and password to be recognized as an eligible user. After a successful negotiation, a typical message from the log of both peers is Peer Is a Cisco Unity Compliant Peer, which indicates a successful group name and password authentication.
620
Another important feature allows the VPN administrator to group different user requirements into different client groups. For example, some users have Network Address Translation (NAT) congured within their home LAN, so that when they connect to the concentrator, it must recognize that the user is NATing and adjust. The concentrator can determine if the user is NATing or not based on the group name and password they used to connect.
User/Identity Authentication
One of the basic functions for key exchange is to ensure that the exchange occurs between trusted sources. This requires user identity verication and it is related to the nonrepudiation feature, which prevents a communicating party from later denying having participated. User identity requires proof of identity of the sender and it is based on digital signatures and authentication mechanisms. The Cisco VPN Client (Unity) supports the following digital certicates:
Simple Certicate Enrollment Protocol (SCEP) and certicates enrolled with Microsoft Internet Explorer. Supported certication authorities (CAs) that include Entrust, GTE Cybertrust, Netscape, Baltimore, RSA, Keon, Verisign, and Microsoft. Entrust Intelligence Client support. Smartcards are supported through MS CAPI (CRYPT_NOHASHOID), and include Activcard (Schlumberger cards), eAladdin, and Gemplus. RADIUS with support for the following: State/Reply Message attributes (token cards) Security dynamics (RSA SecurID Ready) Microsoft NT domain authentication MSCHAPv2NT password expiration X.509v3 digital certicates
Supported authentication mechanisms are as follows:
Extended Authentication (XAUTH) within IKE provides user authentication of IPSec tunnels within the IKE protocol. XAUTH prompts the user for authentication material (user name + password), and veries this information through the use of a TACACS+/ RADIUS authentication, authorization, and accounting (AAA) server. User authentication occurs between IKE phase 1 and phase 2. If the user successfully authenticates, establishment of the phase 2 SA (IPSec SA) allows the remote users data to be sent securely to the private network. If the user fails to authenticate, no phase 2 SA is established and the user is not able to send data.
621
External User AuthenticationRADIUS

Individual user authentication information, such as user name and password, can be stored locally, which is more appropriate for small installations. Larger installations must use RADIUS or Terminal Access Controller Access Control System Plus (TACACS+), with an external database capable of supporting a large number of remote users. Larger sites with thousands of users are only limited or restricted by the authentication, authorization, and accounting (AAA) servers capacity.
NOTE
The RADIUS server is based on a protocol for AAA that was developed by Livingston Enterprises, Inc. (see RFC 2866). Cisco has incorporated the RADIUS client into Cisco IOS 11.1. TACACS was introduced with Cisco products and has been in use for many years. The extension of the original TACACS was commonly called Extended TACACS or XTACACS, and was introduced in 1990. Both are documented in RFC 1492. The third is TACACS+, which despite the name, is a completely new protocol and is not compatible with TACACS or XTACACS.
RADIUS is the main choice for external user authentication in existing VPNs. It is composed of a protocol with a frame format that uses UDP/IP, a server, and a client. The RADIUS server runs on a central computer, usually at the customers site, and the clients reside in the access servers that can be distributed throughout the network. The RADIUS client is typically a NAS and the RADIUS server is usually a daemon process, which runs on a UNIX or Windows NT machine. The client passes user information to designated RADIUS servers, and acts on the response that is returned. RADIUS servers receive user connection requests, authenticate the user, and return the conguration information necessary for the client to deliver service to the user. A RADIUS server can act as a proxy client to other RADIUS servers or other kinds of authentication servers.
Packet Encryption
RADIUS only encrypts the password in the access-request packet from the client to the server. The remainder of the packet is in clear text. Information other than the encrypted password, such as username, authorized services, and accounting, can be intercepted by a third party. RADIUS can use encrypted passwords by using UNIX /etc/passwd le; however, this process is slow because of the time consuming linear le searches.
622
Authentication and Authorization

RADIUS combines authentication and authorization. The access-accept packets sent by the RADIUS server to the client contains authorization information, which makes it difcult to separate authentication from authorization.
NOTE
Starting with release 3.0 of the VPN 3000 Concentrator, you can use TACACS+ for administrative authentication. After conguring TACACS+, ensure that you test authentication before logging out. An incorrect conguration of TACACS+ can lock you out, and require a console port login to disable TACACS+ and rectify the problem.
VPN and RADIUS

VPN uses server authentication that is similar to a dialup environment. The client passes user information to designated RADIUS servers, and acts on the response that is returned. The RADIUS server receives user connection requests, authenticates the user, and returns the conguration information necessary for the client to deliver service to the user (see Figure 19-19).
Figure 19-19 The VPN Authentication Process Using RADIUS
VPN 1 2 3
RADIUS Client RADIUS Server 4 5
The following summarizes the process:

1 The user starts an IPSec tunnel to the VPN concentrator by using the VPN client. 2 The VPN concentrator prompts for username and password. 3 The user replies. 4 The RADIUS client sends a username and encrypted password to the RADIUS server.
623
5 The RADIUS server responds with Accept, Reject, or Challenge. 6 The RADIUS client acts upon services and service parameters that are bundled with
Accept or Reject. Every authentication method deserves special attention, which exceeds the objectives of this book. However, the XAUTH within IKE is extensively used by Cisco VPN solutions, and deserves more attention here.
XAUTH
IKE enables a device to set up a secure session by using a bidirectional authentication method, which uses either preshared keys or digital certicates. However, IKE does not provide a method to leverage legacy authentication methods that are widely deployed today. XAUTH is not designed to replace or enhance existing authentication mechanisms, but rather to enable them to be extended by using legacy unidirectional authentication mechanisms such as RADIUS, SecurID, and one-time password (OTP) within IPSecs ISAKMP protocol.8 This XAUTH protocol is designed so that the authentication can be accomplished by using any mode of operation for phase 1 (such as main mode or aggressive mode), and as any authentication method supported by IKE. This protocol can also be easily extended to support new modes of authentication methods, but it does require that the phase 1 authentication method be fully secure. XAUTH adds a vendor ID that must be authenticated whenever possible. The vendor ID for this revision of XAUTH is the following 8 bytes: Vendor ID = 0x09002689DFD6B712 XAUTH provides a mechanism for ve basic types of authentication:
Simple authentication Challenge-response authentication Two-factor authentication OTPs User previously authenticated
An example of an authentication mechanism, where the user password is hidden by an encryption mechanism, follows (see Figure 19-20). Designed for future use, XAUTH supports the following authentication types: 0Generic, 1-RADIUS-CHAP, 2-OTP, and 3-S/Key. Types 4-32767 are reserved for future use, and types 32768-65545 are reserved for private use.
624
Figure 19-20 XAUTH Authentication When the Password Is Encrypted

IPSec User Edge Device
<-- REQUEST (TYPE=RADIUS-CHAP, CHALLENGE="Your_ID_number" NAME="" PASSWORD="")
REPLY (TYPE=RADIUS-CHAP NAME="pnedeltc" PASSWORD="EB45ID09")
SET (STATUS=OK)
ACK (STATUS)
Key Management, DH Algorithm, and Methodology

Condentiality services can be selected independent of other services. However, use of condentiality without integrity/authentication (either in ESP or separately in AH), might subject trafc to certain forms of active attacks that can undermine the condentiality service. Therefore, authentication is offered as an option in conjunction with condentiality. RFC 2401 denes two methods of authentication and key management: manual keying, and automated keying through IKE. Valid authentication methods include the following:
Preshared keys Digital signature standard (DSS) signatures RSA signatures Encryption with RSA Revised encryption with RSA
A DH exponential algorithm generates a strong initial key.
NOTE
The Dife-Hellman key agreement protocol (also called an exponential key agreement) was developed by Whiteld Dife and Martin Hellman in 1976, and was published in New Directions in Cryptography. The protocol enables two users to exchange a secret key over an insecure medium without any prior secrets.
Before IKE proceeds, the parties must agree on how to authenticate themselves to each other. This authentication method is negotiated during the IKE phase main mode exchange. The following mechanisms are in use today:
625
Preshared keys that involve the manual installation of the same key on each peer. Encrypted nonces that generate an asymmetric encryption public/private key pair for each peer, then manually copy the public key of each peer to every other peer. Digital certicates are issued by a trusted third party, called a CA, to validate the authenticity of each peer and to offer the added benet of non-repudiation, so a peer can verify that a communication actually took place.
When remote access clients are involved, a second level of user authentication occurs after device authentication, which occurs through the IKE SA. The headend starts an XAUTH request to the remote user, which prompts for the username-password/passcode pair.9 After authentication is completed in the rst phase, the second phase connects the remote and local networks. The DH algorithm is still considered the strongest by the cryptographic society. In the DH key agreement, the two parties, without any prior arrangements, can agree upon a secret key that is known only to them (often called a shared secret or a key encryption key). This secret key can then encrypt further communications between the parties. The shared secret encrypts the symmetric key (or data encryption keysuch as DES, Triple DES, CAST, International Data Encryption Algorithm [IDEA], or Blowsh) for secure transmission. Asymmetric key systems use two keys: the private key, which the user keeps secret, and the public key, which can be shared with the world. Unfortunately, the asymmetric key calculation is extremely slow. Today, it is a typical practice to use a symmetric system to encrypt the data, and an asymmetric system to encrypt the symmetric keys. This is how you use DH. The basis for the DH algorithm is the difculty of calculating logs in modular arithmetic (see the following Note). The process begins when each side of the communication generates a private key. Each side then generates a public key, which is a derivative of the private key. The two systems then exchange their public keys, so that each side of the communication now has its own private key and the other systems public key. Because of the complexity of the algorithm, its explanation goes beyond the scope of this book. The methodology of the DH algorithm can be found in the article IPSec-Based VPNs and Related Algorithms, by P. Nedeltchev and R. Ratchkov (Cisco Packet Magazine, Q2 2002; and at www.cisco.com/warp/public/784/packet/apr02/pdfs/plamen.pdf).
NOTE
The expression x = y (mod m) reads as x is equivalent to y, modulo m. The statement a + kp = a (mod p) should be fairly obvious. The Chinese Remainder Theorem states that x = y (mod p) and x = y (mod q) is the same as x = y (mod pq), if p and q are coprimes. The Fermat/Euler Theorem rules that if p is prime, xp 1 = 1 (mod p). RSA correctness rules that if d and e are generated in a way that de = k(p 1)(q 1) + 1, and k is an integer, the encryption/decryption process can be written as xed % pq. 10
626
The cost of some methods for computing discrete logarithms depends on the length of the prime, and the cost of others depends on the length of the private value. The intention of selecting a private-value length is to reduce the computation time for key agreement, while maintaining a given level of security. The time to execute the algorithm by software is proportional to D3, where D is the number of bits of p. Therefore, increasing from 200 to 800 bits raises the complexity by a factor of 64. The length of the primes that dened DH-Groups, or Oakley Default Groups, are as follows: Group 1Default 768-bit (300h) Group 2Alternate 1024-bit (400h)recommended Group 3EC2N group on GP[2155] Group 4EC2N group on GP[2185] Group 5Prime length 1536 bits (600h)
NOTE
The Cisco VPN 3000 Concentrator uses DH group 7 as well. The DH group 7 generates IPSec SA keys that are based on an elliptical curve eld (ECC) size of 163 bits. You can use this option with any encryption algorithm and any peer that supports ECC group 7, but it is intended for use with the movianVPN (wireless) client.
The DH key exchange is vulnerable to a man-in-the-middle (MIM) attack because it does not authenticate the participants. The attack consists of someone intercepting both public keys and forwarding bogus public keys of their own. The MIM can potentially intercept encrypted trafc, decrypt it, copy or modify it, re-encrypt it with the bogus key, and forward it on to its destination. If successful, the parties on each end have no idea that there was an unauthorized intermediary. The authenticated DH key agreement protocol, or Station-toStation (STS) protocol, was developed by Dife, van Oorschot, and Wiener in 1992, to defeat the MIM attack on the DH key agreement protocol.11 Immunity is achieved by allowing the two parties to authenticate themselves to each other through the use of digital signatures and public-key certicates.
NOTE
The MIM is addressed in ISAKMP (see RFC 2408), where not only MIM, but two other types of ISAKMP protection, including anti-clogging (DOS) and connection hijacking are addressed.
The longer that a symmetric key is in use, the easier it is to perform a successful cryptoanalytic attack against it. Therefore, changing keys frequently is important. Both sides of the communication still have the shared secret and it can be used to encrypt future keys at any time and for any frequency desired.
627
RFC 2401 denes perfect forward secrecy (PFS), where a shared secret encryption key refresh involves combining the current key with a random number to create a new key. PFS enforces the recalculation of the shared secret key from scratch by using the public and private key generation and DH techniques. It recalculates to avoid the situation where a hacker might have derived a particular secret key. PFS allows a new key to be calculated that has no relationship to the preceding key. The PFS is closely related to SA Lifetime, where an SA Lifetime determines the period of time that a security association is valid. It also determines how often a key is refreshed or recalculated. A lifetime can be measured in seconds or kilobytes and is applied to both the IKE SA and IPSec SAs.
Cisco and IPSec Message Authentication (Integrity) and Condentiality

IPSec provides numerous security features that are based on a family of algorithms, which perform transformations over different elds of packets. The content transformation of the packet is governed by HMAC, as dened by RFC 2104. As previously mentioned, it is based on a secret key that is available to both parties and the key material generation precedes the packet content transformation. Codes based on cryptographic hash functions are called HMAC. RFC 2104 denes HMAC as the following: H (K xor opad, H (K xor ipad, text)) HDenotes a cryptographic hash function KDenotes a secret key textThe input text stream HMAC can use any cryptographic hash function, such as MD5 and SHA-1, and it is at least as strong as the hash function it uses. This also allows for easy cryptographic analysis of the HMAC, where only the underlying hash function is analyzed. Assuming that H is a cryptographic hash function that iterates over a block of data, with byte length B for each block, ipad and opad are xed length strings that are dened as follows: ipad = 0x36 repeated B times opad = 0x5C repeated B times The enterprise can dene the policy and implement a high level of granularity by using different algorithms. The algorithms parameters are congurable and include type of data encryption, device authentication and credentials, data integrity, address hiding, and SA key aging. The IPSec standard requires the use of either data integrity or data encryption, and using both is optional. Cisco highly recommends using both encryption and integrity see the site www.cisco.com/go/safe. Do not use hash functions for encryption. Cisco recommends the use of 3DES for data encryption, and either MD5 or SHA-1 for data integrity (message authentication). Because of the greater bit strength of SHA-1, it is considered more secure. Cisco recommends the use of SHA-1 mainly for S2S VPNs because the increased security
628
outweighs the slight increase in processor overhead (in fact, SHA-1 is sometimes faster than MD5 in certain hardware implementations).12 Both IPSec phases offer the ability to change the lifetime of the SA. You might consider changing the lifetime from the default setting, when the sensitivity of the tunneled data demands replacing the encryption keys and re-authenticating each device on a more aggressive basis. For more information about transformation, hashing, and encryption techniques, see the IPSec family of standards that recommends certain mandatory choices, which are called conformance requirements. The valid choices, supported and recommended by Cisco, are documented in Table 19-2.
Table 19-2 Cisco Recommended Algorithms (At the Time This Book Was Written) Recommended Algorithms ah-md5-hmac ah-rfc1828 ah-sha-hmac esp-40bitdes esp-des esp-md5-hmac esp-rfc1829 esp-sha-hmac esp-3des esp-null Description of the Recommended Algorithms AH-HMAC-MD5 transform AH-MD5 transform (RFC 1828) AH-HMAC-SHA transform ESP transform using DES cipher (40 bits) ESP transform using DES cipher (56 bits) ESP transform using HMAC-MD5 auth ESP-DES-CBC transform (RFC 1829)Cant use with an auth Method ESP transform using HMAC-SHA auth ESP transform using 3DES cipher (168 bits) ESP transform using null cipher
In conclusion, Cisco announced major new capabilities in March 2002, for a Unied VPN (UVPN) suite of protocols that will increase service provider reach, and allow enterprises greater choices and exibility. A rst in the industry, UVPN was introduced with complete support for Layer 2 and Layer 3 VPN technologies. The second phase of Unied VPN Suite will support Multiprotocol Label Switching/Border Gateway Protocol based (MPLS/BGP) VPNs, IPSec, and generic routing encapsulation (GRE). It will integrate Layer 2 access VPNs and simplify deployment. As the latest addition to Cisco IOS Software, L2TP version 3 appears to offer a promising path to efciently deliver Layer 2 services. One of the features in the UVPN is Ciscos EasyVPN, which is discussed in detail in the following chapters.
End Notes
1 Alwayn, Vivek. Advanced 2 Cisco
MPLS Design and Implementation. Cisco Press, 2001.
Packet Magazine. Transport to the Future. R. Brown. Q1, 2002.
Review Questions
629
3 RFC 4 RFC 5 RFC 6 RFC 7 RFC
2637. Point-to-Point Tunneling Protocol. K. Hamzeh, G. Pall, W. Verthein, J. Taarud, W. Little, and G. Zorn. 1999. 3078. Microsoft Point-To-Point Encryption (MPPE) Protocol. G. Pall, G. Zorn. 2001. 2661. Layer Two Tunneling Protocol (L2TP). W. Townsley, A. Valencia, A. Rubens, G. Pall, G. Zorn, B. Palter. 1999. 2401. Security Architecture for the Internet Protocol. 1191. Path MTU Discovery. J.C. Mogul and S.E. Deering. 1990.
8 Cisco
Systems Internet Draft. Extended Authentication Within IKE (XAUTH). S. Beaulieu and R. Pereira. 2002. within IKE (XAUTH). www.ietf.org/internet-drafts/draftbeaulieu-ike-xauth-01.txt.
9 Extended Authentication 10 Jones,
Burton W. Modular Arithmetic. Blaisdell Publishing Company, 1964.
11 www.sans.org/infosecFAQ/encription/dife.htm. 12 Cisco
Packet Magazine. IPSec-Based VPNs and Related Algorithms. P. Nedeltchev and R. Ratchkov. Q2 2002. (Also at www.cisco.com/warp/public/784/packet/apr02/ pdfs/plamen.pdf.)
Summary
In this chapter, you learned about service provider-based VPNs and enterprise VPNs, the functional and technological categories, and the data link layer and network layer VPNs. The PPTP and L2TP second layer VPNs are explained in reasonable detail. The main focus of the chapter is on remote access VPNs, and especially IPSec-based remote access VPN solutions, because they represent the vast majority of the existing VPN solutions in todays industry. The IPSec sections include security associations, security policies, IKE and IPSec modes and protocols, such as the AH and ESP. The authentication includes group name and password, client, user and message authentication methods, and certicates. The DH exponential algorithm, and the complex hashing and encryption complex mathematical algorithms are represented.
Review Questions
1 Name the major VPN types of Cisco Enterprise VPN solutions. 2 What ports need to be open in the corporate rewall to ensure PPTP functionality?
630
3 What is the purpose of control messages in the L2TP protocol? 4 Dene voluntary mode and compulsory mode in PPTP-based VPN. 5 What is the minimum set of negotiable attributes in IKE SA? 6 What does SPI stand for in IPSec? 7 What are the valid authenticating methods in IPSec? 8 What is the main difference between main mode and aggressive mode? 9 What is the main difference between transport mode and tunnel mode in IPSec? 10 Dene the unidirectional and bidirectional security associations (SA). What kind of
SA is an IKE SA? An IPSec SA?

11 What is ICV and how is it calculated? 12 Which ports have to open in the companys rewall to ensure ISAKMP, ESP, and AH
operation?
13 What is the advantage of XAUTH among other authentication methods? What is type
1 authentication in XAUTH?
14 What is the size of the prime in DH Group 5? 15 What does PFS stand for? Explain PFS.
CHAPTER
20
Remote Access VPN Design and Conguration Solutions

The design of a remote access Virtual Private Network (VPN) solution is concerned with determining the optimum balance between functionality, frugality, and manageability for an organization. All Cisco solutions are competitive in pricing, offer overlapping feature sets, and perform remote access with cryptographic features. As a result, an organizations requirements can be met using a single or combination of Cisco alternatives. This chapter focuses on remote access VPN solutions. The initial part provides more detailed information about the main remote access VPN design objectives, remote access VPN management considerations, and security policies when designing remote access VPN access solutions. This chapter is divided into design and conguration sections. The remote access VPN design part focuses on a concise description of the following topics:
Remote access VPN design objectives Remote access VPN management considerations Security policies, authentication options, IP Security (IPSec) modes, Network Address Translation/Port Address Translation (NAT/PAT) challenges, split tunneling, and rewall functionality Remote access VPN core design considerations and architectural guidelines Conguration of the VPN 3000 Concentrator Cisco VPN client congurations, including the VPN Unity Client, the Hardware client, the Easy VPN client, and the PIX-based client
The remote access VPN conguration part includes the following:
Remote Access VPN Design Solutions

To clarify your need for a remote access VPN solution, you must rst differentiate between remote access and site-to-site S2S VPNs, as shown in Table 20-1.
634
Chapter 20: Remote Access VPN Design and Conguration Solutions
Table 20-1 Location Mobile Fixed
Remote Access Versus Site-to-Site VPN Comparison Signicant Number of Endpoints with Lower-Bandwidth Internet Connections Remote access Remote access Limited Number of Endpoints with High-Bandwidth Internet Connections Remote access Site-to-site
A remote access solution is required to meet the demands for mobility from sales or remote staff who are frequently out of the ofce. Individual remote users require access to resources on their organizations network, regardless of the fact that they might be at a xed location or roaming by connecting through high-bandwidth services to the Internet. However, the distinction between remote access and smaller S2S VPN requirements is starting to blur because Ciscos product offerings in this area provide more exibility. Today, remote access solutions provide not only Client mode, but also Network-Extension mode (VPN3002, Easy VPN, PIX 501 and 506), which enables a separate private network to be deployed on the client side with addressing that is routable with the organizations network. This expands the initial understanding of a S2S solution. For large-scale enterprise remote access VPNs, particularly those that must support broadband connections, the key objectives of the design phase of VPNs are as follows:
Resiliency and availability Easy management and exibility Security policies Robust architecture and scalability
The most important decisions in the design phase of remote access VPN solutions include outlining the key objectives of the design, understanding how the VPN management processes are implemented, planning the required security policies, and knowing how to create a robust and scalable environment.
Remote Access VPN Design Objectives

Typically, a remote access VPN solution should meet the resiliency and availability standards of other areas of your network. Assuming that your organization has designed its Internet connectivity to provide local and global redundancy, you must consider product features that allow you to maximize service levels for your user base:
Flexible deploymentYou should be able to deploy your VPN terminating devices anywhere in your network. Currently, three general network congurations exist for VPN devices: bridge, end-node, and routed. A routed device provides the most redundancy because it participates in your networks dynamic routing processes. Endnode devices depend on static routes that have a varying affect on redundancy,
635
depending on how the Internet Protocol (IP) addresses are assigned to VPN clients, and how the pools are routed. If any client can access all network devices without regard to the concentrator or user group, redundancy for end-node devices approaches that for routed devices. Finally, bridged devices have the least exibility because they must be located directly behind your Internet service providers (ISPs) gateways.
Client transparencyUpon failure or the inaccessibility of a VPN terminating device, the connection of a remote access VPN user should be seamlessly transferred to another VPN terminating device. Further, the client should be congurable to connect to multiple devices, with automatic connection attempts to backup devices in the event that the rst choice is not available. Finally, if failover attempts are unsuccessful, the client should be notied in a timely manner that the connection has failed. Service transparencyIdeally, clients should be able to point their client to a single Domain Name System (DNS) to access the VPN service, regardless of the location and the corporate Internet access points. A single host name that covers all VPN terminating devices can provide maximum redundancy and perceived uptime from the client perspective. This design can be facilitated with the use of products such as Cisco Content Engines for Internet Content Delivery, which can be seen at the following site: www.cisco.com/warp/public/cc/so/neso/cxne/cceng_ds.htm or Cisco Distributed Director at www.cisco.com/warp/public/cc/pd/cxsr/dd/index.shtml.
The management of VPN solutions is crucial not only to protect the companys resources from unauthorized access, but also to enable a transparent and manageable solution for all categories of potential users, including full-time telecommuters, day-extenders, roadwarriors, and engineers who are working from home or from a customers site. The solution deployed for each category must be evaluated according to the ability to deploy, change, and enforce policy from the central site.
Remote Access VPN Management

Robust VPN management is a crucial factor for any large remote access VPN deployment. The relevant management features can t into three broad categories: conguration, change, and operations.
Conguration Management
VPN is a sophisticated technology with an extensive number of conguration options. To fully realize the benets, it must be easier to deploy than earlier solutions. Characteristics of strong conguration management include the following:
Core devices demonstrate extremely high availability/low failure rates. Clients are easy to deploy and use, and end users do not require signicant training.
636
Existing infrastructures can be leveraged to minimize new investment in supporting technologies such as authentication, which includes the following: Remote Access Dial-In User Server (RADIUS) Terminal Access Controller Access Control System Plus (TACACS+)
Change Management
Inevitably, you will make changes to your VPN implementation. This might be as simple as changing the Simple Network Management Protocol (SNMP) strings on your central equipment, to a complete upgrade of your central devices and clients. The following are examples of requirements to consider when determining your change management needs:
Changes to core devices do not require stopping/starting the device. New SW is veried by the core device before becoming available for operation, and erasing previous versions. Client SW upgrades require little to no user intervention.
Operations Management
Day-to-day monitoring and management of the VPN solution should be automated to the fullest extent, and require minimal human interaction to maintain service levels at the highest levels of operational availability. Examples of effective operations management include the following:
Monitoring the entire service and individual devices Failure warnings and alerts that support industry standards Self-monitoring, alerts, and failover for proactive management
(See the section, Redundancy later in this chapter, which covers redundancy using Virtual Router Redundancy Protocol (VRRP) and load balancing.)
Remote Access VPN Security Considerations

This section covers some of the decision-making aspects when deciding on a remote access VPN solution. Most of these considerations are valid for any VPN design, but the main focus of this section is on remote access solutions. In particular, the text covers the following:
User authentication infrastructure IPSec transport and tunnel mode IPSec data authentication and encryption
637
Challenges of NAT/PAT Split tunneling Performance criteria for VPN termination equipment Firewall functionality Resiliency and availability VPN core design considerations
Some of the following information was presented in detail in Chapter 19, VPN Technology Background. Its presence here is to show how the different choices and options can or cannot make a difference in the design phase of remote access VPNs.
User Authentication Infrastructure

Ideally, organizations want to use what they already have deployed and are comfortable supporting. This is especially obvious for organizations that have some type of infrastructure to support dialup services. Although relatively few organizations have implemented Public Key Infrastructure (PKI) or digital certicate authentication systems across the entire enterprise, often systems to support RADIUS, TACACS+, NT Domain, and token-based security servers are already in-place. The argument could be made to migrate to VPN and PKI at the same time, but a general recommendation is to migrate to each technology individually to minimize the amount of change for the support organization.
IPSec Transport and Tunnel Mode

If you decide to implement IPSec, theoretically, you must also decide whether to implement Authentication Header (AH), or Encapsulation Security Protocol (ESP), or both. AH provides data integrity and data origin authentication. However, it does not hide the contents of its packets, so it cannot provide data condentiality. ESP does encrypt the data, but it does not protect the new IP header. Ideally, you use both ESP and AH to gain the benets of both. In reality, almost all remote access VPN deployments use only ESP. Whether the IPSec AH or ESP protocol is chosen, the second important decision is whether to use transport or tunnel mode. Transport mode is used when both endpoints support IPSec, as opposed to tunnel mode, where there can be a proxy-like device terminating the tunnel, and then sending trafc on to and from the central network. In transport mode, the AH or ESP header is placed after the original header, and only the payload of the IP packet is encrypted. The original packet headers are left intact, which allows network services, such as quality of service (QoS) to be implemented. Tunnel mode encapsulates the entire IP packet in either AH or ESP, adding a new header, and then the entire datagram is encrypted. Because of its proxy-like capability, tunnel mode is almost exclusively used for all remote access VPN environments.
638
IPSec Data Authentication and Encryption

Security protocols must ensure that data transmissions are secure after the user is authenticated. This requires special tunneling protocols and encryption services because the remote users information might be intercepted in transit, and modied by a third party without the knowledge of the user or the application. Packet contents can be inspected and modied, and source and destination addresses can be changed. TCP/IP originally did not offer any method to secure the data stream. Examples of the security protocols include generic routing encapsulation (GRE), Layer 2 Tunnel Protocol (L2TP), Point-to-Point Tunneling Protocol (PPTP), and IPSec. In some instances, combining security protocols can be a preferable solution, as offered in the Cisco Unied VPN offering that is available in IOS versions 12.0S and 12.2T. For example, second layer tunneling could be more benecial in high-latency networks, which require special measures to enforce your security policies. Based upon the details covered in Chapter 19, it is generally agreed that IPSec offers the strongest combination of features for tunneling, message authentication, and condentiality. A crucial component of authentication and encryption is the generation of keys used for each process. The key exchange between the devices in a remote access VPN session also identies the participants. The Internet Key Exchange (IKE) (formerly [Internet Security Association and Key Management Protocol] ISAKMP/Oakley) is the recommended solution, and congurable options include the Dife-Helman (DH) group to be used with a popular public key crypto algorithm. There are some indications that development of a new key exchange algorithm, Fast Key Exchange, is underway. Data authentication conrms that the data one receives is actually the data that the originator intended to send. As part of IPSec-based VPNs, Cisco recommends data authentication protocols that use keyed hash algorithms. For most remote access environments, the Message Digest 5 (MD5) algorithm is the preferred alternative; however, the Secure Hash Algorithm 1 (SHA-1) is recommended for router-based or S2S solutions. These protocols offer conguration features that simplify their implementation. Encryption converts the data into a coded form with a key that can only be understood if you have the key and understand the encoding algorithm. Otherwise, you cannot read the original data in the encrypted format. The more common encryption algorithms include the Data Encryption Standard (DES) and Triple-DES (3DES). A recently developed algorithm is the Advanced Encryption Standard (AES), which was approved as a Federal Information Processing Standard (FIPS) by the National Institute of Standards and Technology (NIST) at the end of 2001. Similar to the hashes discussed earlier in this section of this chapter, these data encryption algorithms usually offer congurable parameters.
Challenges of NAT/PAT
Environments that use NAT or PAT present challenges for establishing, transmitting, and receiving data across IPSec tunnels. A one-to-one NAT translation occurs when there is an
639
internal address that is mapped to a unique external address. Although not widely used, this form of NAT is used by organizations that want to hide the identity of the end client. A oneto-many NAT, or a PAT environment, consists of one external address that is mapped to many internal addresses. The router or rewall that performs the NAT or PAT maintains a translation table that identies the external destination address with a unique identier, such as the TCP or User Datagram Protocol (UDP) port numbers, and maps these port numbers to trafc transmitted to specic devices on the internal network. PAT is used extensively on residential and corporate networks, and enables the user to conserve address space and hide the identity of their clients. Unfortunately, the ESP protocol does not use the concept of ports. Also, information in the packet is encrypted and unavailable, so the translation device cannot obtain the internal addresses from the IPSec packet. As a result, ESP is typically incompatible with this form of NAT.
IPSec over UDP: A Viable Alternative

As a workaround to the NAT issue described earlier in this chapter, Cisco implemented a technique where the IPSec trafc is encapsulated in UDP trafc, on the VPN 3000 series concentrator. By encapsulating the packet in UDP, the NAT translation device can perform the standard port mapping technique to uniquely identify the source and destination trafc ows. Implementing UDP encapsulation requires additional overhead for each packet, but it is relatively small compared to average packet sizes. At this time, a standards-based approach to resolving IPSec over NAT implementations has not been agreed upon. In the meantime, the Cisco alternative of UDP encapsulation is an effective solution.
IPSec over UDP on the Cisco VPN 3000 Concentrator and Clients
To use IPSec over UDP encapsulation, the VPN 3000 Concentrator administrator must congure either the user or a group. If enabled for a specic user, tunnel negotiation between the client and the concentrator occurs automatically by using IKE. The setup includes the UDP port number and the actual requirement for IPSec over UDP. It is congurable on the Cisco VPN Unity Client, but the Cisco VPN 3002 HW client does not offer any congurable options, so the IPSec over UDP feature for these client types must be congured on the Cisco VPN 3000 Concentrator. As part of enabling the IPSec over UDP option, the core site concentrator must be accessible through the negotiated UDP port; then, data transmissions will be successful from a client behind a device that is performing NAT. If the remote user is behind a rewall, the user must ensure that the rewall rules permit the required trafc, which is necessary for establishing the tunnel over the specied UDP port.
640
IPSec over TCP

The Cisco VPN 3000 Concentrator, VPN Unity Client, and VPN 3002 HW Client provide the option to encapsulate IPSec trafc in TCP datagrams, which was released in v3.5 of these products. To activate this feature, both the core concentrator and the client must be congured to enable IPSec over TCP on the same TCP port. The benet of enabling this feature is primarily for clients who try to access the central concentrator, while behind a rewall that only permits outside exchanges of datagrams that are started by internal hosts on well known or specic ports. By encapsulating the trafc over, for example, port 443 (https), the initiator can be reasonably condent that the rewall will permit responses from the core concentrator. This precludes the need to request security changes to accommodate IPSec, ISAKMP or specic UDP port trafc.
Split Tunneling
The split tunneling feature allows clients to simultaneously send and receive data across a VPN tunnel, while also communicating directly with resources on the Internet. Only trafc that is destined for or originating from hosts on the network that are terminating the VPN connection is encrypted and sent across the tunnel. All other IP trafc is sent outside of the VPN connection to hosts connected on the Internet unencrypted. An organization might nd split tunneling benecial because it reduces the central resources required to support a VPN environment, including ISP bandwidth, and throughput on the local-area network (LAN) and VPN tunnel terminating device. However, many organizations with strict security policies might nd the risk of implementing split tunneling too great, and restrict its use. Concerns might arise as split tunneling could increase the likelihood that an intruder might break into the corporate network by hacking a members host that is concurrently connected to both the Internet and the corporate network through the VPN. The argument is that the organization does not want to extend their rewall capabilities to the customer premises equipment (CPE) at the remote users location, and deal with the administration. To possibly address some of these concerns, an integrated stateful rewall was incorporated into v3.5A of the Cisco VPN Unity Client, which can be activated when a VPN connection is attempted or active. With v3.5 the VPN 3000 Concentrator included a congurable option to require or warn connecting SW VPN clients that they must imple-ment a specic SW rewall. Further, with v3.5.1, the concentrator can point to a central server that administers the rewall policy.
Firewall Functionality
Firewalls are designed to protect a network from outside trafc that is determined to be hostile to the organization. Some products provide an integrated solution for both the rewall and the VPN terminating device; however, before covering this in more detail, the following descriptions of rewall types are provided:
641
Packet lter rewallsPacket lter rewalls are the simplest type of rewall available today. They require the least amount of resources, but can only perform simple logic such as permit/denybased on source/destination IP address, protocol, or port. Intruders can thwart the rewall by spoong the address. Proxy rewallsA proxy is a gateway between the source and destination. All trafc that is intended for external hosts is sourced from the proxy address, instead of the originators address, which provides some anonymity and security to the data transfer. Detailed access controls and trafc reporting are available on proxy rewalls. Stateful inspection rewallsStateful inspection rewalls are the most sophisticated, extending the features of packet-ltering to examine packet ows, and allowing policies to be implemented and checked. An example of this capability is when a TCP acknowledgment (ACK) packet is not preceded by a TCP synchronize (SYN) packet in the correct sequence.
The concentrator rejects any trafc not sourced from one of the allowed protocols or ports. A common deployment for most organizations is to place a stateful inspection rewall in parallel with the VPN concentrator, which offers scaling advantages versus an integrated device. Another advantage of separate devices is the opportunity to implement management interfaces that are optimized independently for each environment. An obvious drawback of this solution is the fact that two different devices with different interfaces require support staff who are trained on both units.
Remote Access VPN Termination Equipment Design Considerations

Cisco recently developed the SAFE Blueprint,1 which provides the latest information for VPN architecture and designs. An entire series of documents are available online from www.cisco.com. This information should be regularly reviewed to ensure that your networks incorporate the latest suggested designs and features. SAFE discusses various alternatives from the organizations perspective, taking into account the scale of the implementation, and the available resources of the organization. It is recommended that you extensively refer to this site when planning your remote access VPN offering.
Termination Equipment Architecture Guidelines

A quick overview of some suggested items that should be considered for your VPN core device architecture are documented in this section. For remote access VPNs, determining the number of devices and where they are deployed is a major concern. To address location decisions, you must analyze your organizations rewall locations and determine where the largest numbers of your user community can access your network. Based on this analysis, enterprises usually provide VPN termination capability at these high-trafc Internet points of presence (POPs).
642
For redundancy, clients can be automatically redirected to VPN core devices at other locations if they cannot access the devices in their chosen location. The number of VPN sites that you implement depends on your remote access strategy, Internet POPs, available bandwidth, and the availability of required support staff and procedures. In most cases, it is usually worthwhile to consolidate into selected sites, where bandwidth is plentiful and cost effective, to reduce the complexity of maintaining a large number of rewalls and demilitarized zone (DMZ) networks. However, this model might not be the best t in areas of the world where there is little difference in the cost of Internet access versus dedicated bandwidth. Generally speaking, Cisco recommends that you install the VPN device in parallel with your corporate rewall in the DMZ, as shown in Figure 20-1.
Figure 20-1 Cisco Recommended Architecture for VPN Core Devices
DMZ
Firewall Corporate
Router Internet or ISP Backbone
Tunnel Traffic Only
AAA/DHCP
CA Extranet
VPN Concentrator
In the dotted-line conguration, only tunneled trafc is routed to the VPN concentrator from the Internet, and the concentrator is protected from denial of service (DOS) attacks. Alternatives are possible, such as placing a rewall behind and parallel to the concentrator to provide additional protection to the internal network from such things as virus-infected VPN clients. Numerous possibilities must be considered. It is recommended that you consult Cisco and network security specialists to determine the architecture that best meets your requirements. A number of questions can be considered in determining which core device to use as the core VPN tunnel terminating device:
What are the desired features (NAT transparency, 3DES encryption, and so on)? How many clients must be supported by the core device? Is an integrated rewall on the concentrator required or desired? Would you plan to run a routing protocol on the VPN tunnel-terminating device (Enhanced Interior Gateway Routing Protocol [EIGRP], Routing Information Protocol [RIP], or Open Shortest Path First [OSPF])? What are the installation and ongoing support costs between alternative VPN solutions, and when compared to the existing remote access solution?
643
Core Device Choice Considerations

Cisco IOS-based routers, PIX rewalls, and 3000 VPN Concentrators can all terminate remote access IPSec VPN tunnels (see Figure 20-2). The device(s) you select to implement depends on the scale of your roll out, the number of sites where remote access VPN tunnel terminating devices are located, and the available development and support resources within your organization.
Figure 20-2 The Possible Combinations of Remote Access VPN Client and Termination Points
Remote Site Broadband Option
Router with Firewall and VPN
Broadband Access Device
Core=Router Based+PIX Failover Unit
Hardware VPN Client Option
Hardware VPN Client
Broadband Access Device
Core=PIX Based
Service Provider
Broadband Home Office Access Firewall with VPN Device Redundant WAN
Private Network
VPN 3000 with VRRP or Cluster of VPN30xx Series
Remote Site Firewall Option
Core=Concentrator+PIX
Software VPN Client
Redundant WAN
Software Access Option
IOS VPN Router Core=IOS Router+PIX
Where scalability is an issue, such as for medium and large-scale deployments with greater than 100 concurrent connections, dedicated devices for terminating the remote access VPN tunnels should be deployed. Generally speaking, for maximum security, the termination device should be in parallel with your corporate rewall. However, this extra security comes with slightly greater support costs because you must manage additional devices, versus a scenario where the terminating device was behind the rewall.
Cisco Remote Access VPN Core Devices

The device that you implement to terminate remote access IPSec VPN tunnels depends on the requirements and resources of the site and your organization. This section provides a brief overview of the Cisco VPN 3000 Series Concentrators. Additional information for the Cisco Easy VPN Server and PIX, as VPN tunnel terminating devices, is also provided. However, you should consult your Cisco resources to determine the latest information available about remote access VPN features in the IOS and PIX devices, and the use of these devices for terminating remote access VPN tunnels.
644
Cisco VPN 3000 Series Concentrator Features

Functions of the VPN 3000 Concentrator include the following:
Establishes tunnels Negotiates tunnel parameters Authenticates users Assigns user addresses Encrypts and decrypts data Manages security keys Manages data transfer across the tunnel Manages data transfer inbound and outbound as a tunnel endpoint or router 2
The Cisco VPN 3000 Concentrators, in various models, address the remote access requirements of all organizations of any type and size. The available models and their specic features are listed in Table 20-2.3 Conguration and selected features of the Cisco VPN 3000 Concentrators are covered in the following discussion.
Table 20-2 Feature Simultaneous users Encryption throughput Encryption method Encryption (Scalable Encryption Processing [SEP]) module Redundant SEP Available expansion slots Upgrade capability System memory T1 wide-area network (WAN) module Hardware Dual power supply Client license Cisco VPN 3000 Series Concentrator Models and Features Cisco 3005 100 4 Mbps Software 0 N/A 0 No 32 MB (xed) Fixed option 1U, Fixed Single Unlimited Cisco 3015 100 4 Mbps Software 0 N/A 4 Yes 64 MB Option 2U, Scalable Option Unlimited Cisco 3030 1500 50 Mbps Hardware 1 Option 3 Yes 128 MB Option 2U, Scalable Option Unlimited Cisco 3060 5000 100 Mbps Hardware 2 Option 2 N/A 256 MB Option 2U, Scalable Option Unlimited Cisco 3080 10000 100 Mbps Hardware 4 Yes N/A N/A 256 MB Option 2U Yes Unlimited
645
Easy VPN Server

The Easy VPN Server feature for Cisco routers was rst offered in IOS Release 12.2(8)T. It allows a router to act as a VPN head-end device for remote access VPNs, where the remote device can be a Cisco Unity VPN Client, a VPN 3002 HW Client, a PIX501 or PIX506 running PIX OS v6.2 congured as a VPN client, or a Cisco 800 or 1700 series router congured with SW that supports the Easy VPN Client. Using the Easy VPN Server feature, security policies dened at the head-end can be pushed to the remote access client. The functions of the Easy VPN Server are similar to those of the Cisco VPN 3000 Series Concentrators. A list of the routers that function as an Easy VPN Server are as follows: Cisco 800, 1400, 1600, 1700, 2600, 3600, 7100, 7200, and 7500 series routers, and the uBR905 and uBR925 cable modems (see www.cisco.com/univercd/ cc/td/doc/product/software/ios122/122newft/122t/122t8/ftunity.htm). A selected list of supported IPSec protocol options and attributes, supported by the Easy VPN Server, is listed in Table 20-3. A list of non-supported IPSec protocols and attributes is provided in Table 20-4. Detailed explanations of the attributes can be found in Chapter 19, or in the Conguration of the VPN 3000 Concentrator section.
Table 20-3 Selected IPSec Options and Attributes Supported by the Easy VPN Server4 Options Authentication algorithms Attributes HMAC-MD5 HMAC-SHA1 Authentication types Preshared keys RSA digital signatures DH groups 2 5 Encryption algorithms (IKE) DES 3DES Encryption algorithms (IPSec) DES 3DES NULL IPSec protocol ESP IPCOMP-LZS IPSec protocol mode Tunnel mode
646
Table 20-4
Selected IPSec Protocol Options and Attributes NOT Supported on the Easy VPN Server5 IPSec Protocol Options Authentication types Attributes Not Supported Authentication with public key encryption Digital signature standard (DSS) DH group IPSec protocol IPSec protocol mode Miscellaneous 1 IPSEC_AH Transport mode Manual keys Perfect forward secrecy (PFS)
PIX 500 Series Firewalls as Remote Access VPN Servers

PIX 500 series rewalls can also be congured as the core device that terminates remote access IPSec VPN tunnels. Concurrent users and throughput for the various PIX rewalls that are congured as core devices are shown in Table 20-5. The PIX rewalls support most of the same attributes as the Cisco Easy VPN Server with a few differences such as support for DH Group 1, but not for Group 5, which Easy VPN supports. Other selected features that PIX supports, but not the Easy VPN Server, are as follows:
Transport mode (for L2P) PFS IPComp-L2Z (Compression)
One useful feature that is not supported on both the PIX and the Easy VPN Server is UDP encapsulation for NAT/PAT operating environments.
Table 20-5 Differences Between the Various PIX Firewalls Congured as Core Devices to Terminate Remote Access IPSec VPN Tunnels 501 IPSec VPN clients SW throughput (3DES-SHA) HW throughput (3DES-SHA) NA NA NA 70 Mbps 95 Mbps 5 3 Mbps 506 25 10 Mbps 515 2000 10 Mbps 525 2000 30 Mbps 535 2000 45 Mbps
Performance Criteria for VPN Termination Equipment

The device that terminates the VPN tunnel on the corporate network should be the solution that best meets the organizations requirements, while maximizing performance. As is often
647
the case, the factors of cost, productivity, and security must be prioritized to assist with the selection of the most appropriate solution. Of course, nancial concerns must be acknowledged, but these should be balanced against improved productivity and security. To evaluate the VPN termination device, compare your requirements against the VPN devices capabilities. The device must authenticate users, based on centralized databases that are located on the concentrator, or through a proxy mechanism to central servers. It usually has two interfacesa public and private. As the names suggest, the public interface is accessible from the Internet or service provider network, and the private is protected by the corporate rewalls or by the concentrator itself. Encrypted trafc is passed through the public interface, and unencrypted trafc ows through the private interface. In most cases, performance is maximized by devices that are dedicated to terminating the VPN tunnel, instead of a shared-purpose device, such as a rewall. Specications of the VPN termination equipment that should be carefully reviewed before making any commitments along with some recommendations include the following:
Encrypted throughputWhen the preferred method of encryption is implemented, throughput measurements should be taken. If 3DES is the choice, using the largest key available, which is 168-bit, is recommended. If AES is the choice, a 256-bit key is recommended. Data authenticationImplementing either the SHA-1 or MD5 hash algorithms for data authentication also requires signicant processing power. Measurements have to be made, based on the chosen hashing algorithm, and 168-bit 3DES encryption (256bit AES). Packet sizeIn general, the packet size of wired networks is proportional to throughput. It is unrealistic to perform measurements based on 1500, or 64 bytes. An effective measurement should be performed with an average packet size that is commonly found on the Internet.6 Data throughputMost VPN termination devices have two interfaces, but to quote throughput as the sum of the data trafc passing through both the public and private interface at a given moment is misleading. True throughput should be measured as the data transported through the device. Simultaneous connections and throughputTheoretically, maximum throughput can be measured with one user connected through a single tunnel to the termination device. However, this is not a realistic representation of a real-world scenario. It is better to increase the number of clients for testing purposes, to better determine the expected throughput after it is deployed. LatencyAs throughput increases, internal packet queues also increase. Unfortunately, this can also impact clients with delay-sensitive applications, such as Voice over IP (VoIP) or terminal emulators. High-performance devices that are specically designed for terminating the VPN tunnel offer better performance versus a general-purpose device.
648
Actual dataWhen comparing throughput of devices, try to use the same data streams. If you measure throughput in terms of user-payload data, this approach avoids any inconsistency that might arise. Packets per secondMeasuring packets per second is an important statistic for comparison purposes. Although it is not as critical as throughput, it does measure the ability to route packets from the private to public interface. Routing capabilityYou can select a device that can run a routing protocol used on your network. However, the use of large contiguous address pools might require you to use static routes, but unfortunately, static routes can result in reduced redundancy.
VPN Conguration Considerations

This section covers selected conguration features of the Cisco VPN 3000 Series Concentrator running v3.5.2, which is used as the core device that terminates remote access VPN tunnels for the following clients: Cisco Unity VPN Client, VPN 3002 HW Client, Easy VPN, and the PIX 501 and 506 Clients.
Conguration of the VPN 3000 Concentrator

As indicated, this section does not attempt to cover all aspects of conguring the Cisco VPN 3000 Series Concentrators. Instead, selected features are explored and actual congurations of these features are discussed by using v3.5.2 as the reference. The concentrator offers a quick conguration menu that allows you to congure it in a matter of minutes, after you determine the values and settings for the unit. The steps required to congure the concentrator are outlined in Table 20-6.7 The minimum required settings offered by the Quick Conguration option are listed in Table 20-7.8
Table 20-6 Step 1 2 Steps Required for Quick Conguration on a VPN 3000 Concentrator
Task Set the system time, date, and time zone, from the console. Congure the VPN Concentrator Ethernet 1 interface to your private network, from the console.
At this point, you can use a browser that is pointing to the private interface to complete Quick Conguration with the VPN Concentrator Manager. 3 4 5 Congure the other Ethernet interfaces that are connected to a public network or an additional external network. Enter system identication information: system name, date, time, DNS, domain name, and default gateway. Specify tunneling protocols and encryption options.
649
Table 20-6 Step 6 7 8 9 10 11
Steps Required for Quick Conguration on a VPN 3000 Concentrator (Continued)
Task Specify methods for assigning IP addresses to clients as a tunnel is established. Choose and identify the user authentication server: the internal server, RADIUS, NT Domain, or Security Dynamics Incorporated (SDI). If using the internal authentication server, populate the internal user database. If using the IPSec tunneling protocol, assign a name and password to the IPSec tunnel group. Change the admin password for security. Save the conguration le. Quick Conguration is now completed. Quick Conguration Settings for a VPN 3000 Concentrator Parameter Description and Use Specify the IP address and subnet mask, speed, and duplex mode for the VPN Concentrator interface to your private network. Specify the IP address and subnet mask, speed, and duplex mode for the VPN Concentrator interface to the public network. (For models 3015-3080 only) If so connected, specify the IP address and subnet mask, speed, and duplex mode for the VPN Concentrator interface to an additional external network. Specify a device or system name for the VPN Concentrator (for example, VPN01). Specify the IP address of your local DNS server. Specify the registered Internet domain name to use with DNS (for example, cisco.com). Specify the IP address or hostname of the default gateway for packets not otherwise routed.
Table 20-7
Quick Conguration Parameters Screen | Parameter Name IP Interfaces | Ethernet 1 (Private) IP Interfaces | Ethernet 2 (Public) IP Interfaces | Ethernet 3 (External)
System Info | System Name System Info | DNS Server System Info | Domain System Info | Default Gateway Address Assignment | DHCP | Server
If you use Dynamic Host Conguration Protocol (DHCP) for remote address assignment, specify the IP address or host name of
the DHCP server.
Address Assignment | Congured Pool | Range Start and Range End Authentication
If you use the VPN Concentrator to assign addresses, specify the starting and ending IP addresses in its initial congured pool.
Choose from the following parameters you see in the following screen. Possible values are as follows: Internal ServerChoosing Internal Server means using the internal VPN Concentrator user authentication server. On the User Database screen, specify the username and password for each user. continues
650
Table 20-7
Quick Conguration Settings for a VPN 3000 Concentrator (Continued) Parameter Description and Use Additionally, if you specify a per-user address assignment, specify the IP address and subnet mask for each user. RADIUSIf you use an external RADIUS user authentication server, specify its IP address or host name, port number, and server secret or password. NT DomainIf you use an external Windows NT Domain user authentication server, specify its IP address, port number, and primary domain controller (PDC) hostname. SDIIf you use an external SDI user authentication server, specify its IP address and port number.
Quick Conguration Parameters Screen | Parameter Name
User Database | Group Name, Password, Verify
If you enable the IPSec tunneling protocol, specify a name and

password for the IPSec tunnel group.
System Conguration Highlights

Details of each facet of the concentrator conguration for v3.5 can be found at www.cisco.com/univercd/cc/td/doc/product/vpn/vpn3000/rel3_5_1/cong/cfg.pdf. The following section highlights some of the parameters that can be congured on the VPN 3000 Series Concentrator, under the Conguration, System menu.
Filters and Rules

Filters are assigned to the private (interface 1), public (interface 2), and external (interface 3) interfaces of the concentrator, and to groups or users. The lters provide a means to control trafc that passes through the concentrator. Three lters can be set (Private, Public and External), besides the option to not set a lter. The lter is congured by assigning rules to it under the Conguration, Policy Management, Trafc Management, Filters menu, as shown in Figure 20-3. This menu also offers the option to modify the existing lter settings, or to create your own lter. Rules consist of either one of two actions, forward or drop, which you assign to the lter for various types of TCP/IP trafc. The concept is similar to that of access-lists on an IOS router, in which you use permit/deny instead of forward/drop.
651
Figure 20-3
Assigning Rules to the Filter Conguration Menu
A substantial number of rules are precongured on the concentrator for various types of TCP/IP trafc that is specic to whether the trafc is incoming or outgoing. Rules are congured under Conguration, System Management, Policy Management, Trafc Management, Rules, as shown in Figure 20-4. The gure comprises two images. To modify existing rules or to congure your own, you must decide on the following parameters:
Protocol or port (source and destination) Direction (inbound or outbound) Action for trafc received over established connections Source and destination address information (network and subnet mask)
652
Figure 20-4
Conguring Rules
653
Redundancy
Using VRRP,9 you can congure redundant concentrators in case the primary concentrator fails. Using this conguration, there are one or more Backup units, and there is one active concentrator, referred to as the Master. The Backup units behave as hot standby concentrators, by not terminating any tunnels unless the primary concentrator fails. The Master constantly communicates its status to the Backup concentrators, and if the Master concentrator fails, VRRP tries the Backup concentrator(s) in order of precedence.10 The Backup concentrators must be congured identically to the Master unit. The IP addresses of the Master concentrators are the virtual IP addresses that must be congured on the Backup units. Further, the Backup and Master concentrators public interfaces should be on the same subnet. Similarly, the private interfaces should be on the same subnet. The Backup units do not respond to pings to the virtual IP address; however, if the Master fails, the highest priority Backup unit assumes the role of Master and terminates the IPSec tunnels. From the client perspective, the transfer from the Master to the Backup unit is transparent, and the client session continues without the need to re-establish the IPSec tunnel. Redundancy is congured under the menu Conguration, System, IP Routing, Redundancy, as shown in Figure 20-5.
Figure 20-5 Redundancy Menu Used to Congure VRRP
654
Load Balancing
Load balancing occurs when multiple concentrators are congured to appear as one virtual cluster instead of multiple concentrators. Client connections are established on a roundrobin basis, based on the session load on each concentrator. This session load per concentrator is the total number of active connections, divided by the maximum number of sessions congured on the concentrator. As a result, when you rst implement load balancing, you might have to reduce the maximum number of sessions per concentrator in the cluster, until the number of active clients approaches a predetermined threshold, when the maximum session count on each concentrator should be re-evaluated. The maximum session count is congured under the Conguration, System, General, Sessions menu. Each concentrator in the cluster is congured with the IP address of the virtual cluster, which clients use to establish their IPSec tunnels. To congure load balancing, go to Conguration, System, Load Balancing, as shown in Figure 20-6. If you use the default public or private lters, you might be required to change the lter rules to permit the protocol used for the Virtual Cluster Agent (VCA). The default for this protocol is UDP, port 9023.
Figure 20-6 Menu Used to Congure Load Balancing
You must set the priority of each concentrator in the virtual cluster, which determines the concentrator that will act as the Master of the cluster. Default priority values are assigned to concentrators that are based on the HW platform, as shown in Table 20-8. Generally, the rst concentrator congured and deployed in a cluster is the Master, and if it fails, or if two concentrators are deployed at the same time, the concentrator with the highest priority takes
655
precedence. If the concentrators boot at the same time and have the same priority, the concentrator with the lowest IP is elected Master. After the Master is determined, a new Master is not elected until the current Master fails.
Table 20-8 Default Priority for VPN 3000 Series Concentrators 11 VPN Concentrator Model 3005 3015 3030 3060 3080 Priority 1 3 5 7 10
Unlike the redundancy conguration, if the concentrators are congured for load balancing, a client connection is terminated if their VPN terminating concentrator fails. Clients must re-establish their IPSec tunnel; however, they can still point to the cluster address instead of a specic concentrator.
Reverse Route Injection

The VPN 3000 Concentrators offer reverse route injection, when the concentrator is congured to announce routes on the private interface using OSPF or RIP. Under reverse route injection, the concentrator announces the route of the client. If the Client Reverse Route Injection feature is activated, and if the connection is from a Unity VPN SW Client or a VPN 3002 HW Client congured for PAT mode, the concentrator announces the host route for that specic client. To activate this feature, go to Conguration, System, IP Routing, Reverse Route Injection, as shown in Figure 20-7. Similarly, if the tunnel between the VPN 3000 Concentrator and the VPN 3002 HW Client is congured for network extension mode, the Network Extension Reverse Route Injection must be congured on the same concentrator menu. The VPN 3000 concentrators can be congured with hold down routes for client addresses. You can use the Generate Hold Down Routes feature to automatically create the routes for all the address pools that are congured on the concentrator.
656
Figure 20-7
Reverse Route Conguration Menu
IKE Proposals and Security Associations for IKE and IPSec

IKE proposals are the settings that negotiate the IKE and IPSec Security Associations (SA). As discussed in Chapter 19, IKE SAs negotiate the parameters to establish a secure tunnel, so that the IPSec SAs can negotiate how trafc is managed in the tunnel. The VPN 3000 Concentrator responds to IPSec requests from remote access clients, and checks all active IKE proposals in priority order, to determine if one matches the parameters in the initiators proposed SA. Some IKE proposals and IKE and IPSec SAs that are compatible with the Cisco VPN Unity Client and VPN 3002 HW Client, are precongured on the concentrator, but you can add your own or modify the existing proposals. After you congure the IKE proposals, congure the IPSec SAs and apply them to the specic user or group.
657
The IKE proposal contains the information required for the Phase 1 IPSec negotiation. IKE proposals are congured under the Conguration, System, Tunneling Protocols, IKE Proposals menu, and the modication menu for a specic IKE proposal is shown in Figure 20-8. Specic attributes for active and inactive precongured IKE proposals are listed in Table 20-9.
Figure 20-8 Modication Menu for a Specic IKE Proposal
Table 20-9 658 Authentication Algorithm DH Group Encryption Algorithm Lifetime Data Measurements Lifetime Time Lifetime
Attributes for Precongured IKE Proposals 12
Proposal Name
Authentication Mode
Proposals Active by Default

MD5/HMAC-128 MD5/HMAC-128 MD5/HMAC-128 MD5/HMAC-128 MD5/HMAC-128 MD5/HMAC-128 3DES-168 Group 2 (1024bits) Time 3DES-168 Group 7 (ECC) (163bits) Time DES-56 Group 1 (768-bits) Time 10,000 KB 10,000 KB 10,000 KB 3DES-168 Group 1 (768bits) Time 10,000 KB 3DES-168 Group 2 (1024bits) Time 10,000 KB 86,400 sec 86,400 sec 86,400 sec 86,400 sec 86,400 sec 3DES-168 Group 2 (1024bits) Time 10,000 KB 86,400 sec
CiscoVPNClient3DES-MD5
Preshared Keys (XAUTH)
IKE-3DES-MD5
Preshared Keys
IKE-3DES-MD5DH1
Preshared Keys
IKE-DES-MD5
Preshared Keys
IKE-3DES-MD5DH7
Preshared Keys
IKE-3DES-MD5RSA
RSA Digital Certicate
Proposals Inactive by Default

MD5/HMAC-128 SHA/HMAC-160 MD5/HMAC-128 MD5/HMAC-128 MD5/HMAC-128 3DES-168 DES-56 3DES-168 Group 1 (768bits) Group 7 (ECC) (163bits) Group 2 (1024-bits) 3DES-168 Group 2 (1024bits) 3DES-168 Group 2 (1024-bits) Time Time Time Time Time 10,000 KB 10,000 KB 10,000 KB 10,000 KB 10,000 KB 86,400 sec 86,400 sec 86,400 sec 86,400 sec 86,400 sec
IKE-3DESMD5-RSA
IKE-3DESSHA-DSA
IKE-3DES-MD5RSA-DH1
IKE-DES-MD5DH7
Preshared Keys
CiscoVPNClient3DES-MD5-RSA SHA/HMAC-160 3DES-168
RSA Digital Certicate (XAUTH)
CiscoVPNClient3DES-SHA-DSA
DSA Digital Certicate (XAUTH)
Group 2 (1024bits)
Time
10,0000 KB 86,400 sec
659
The various alternatives for the IKE proposal parameters are described in detail in Chapter 19. The minimum and maximum lifetimes for the IKE proposals are 60 and 2,147,483,647 seconds (about 68 years). The minimum and maximum lifetimes for the IKE proposals, if measured by data, are 10 and 2,147,483,647 KB. DH Group 2 is the default for the 3DES-168 bit encryption algorithm. The Cisco VPN Unity SW Client v3.x is only compatible with DH Group 2. To use DH Group 1 or Group 7 with the VPN 3002 HW client, digital certicates must be used in the Authentication Mode.
SAs
SAs are congured under the Conguration, Policy Management, Trafc Management, SAs menu. The SA modication menu is shown in Figure 20-9. Similar to the IKE proposals, the concentrators are precongured with default SAs that are listed in Table 20-10. These SAs were discussed in detail in Chapter 19. The IPSec parameters negotiate the Phase 2 SAs, and the IKE parameters apply to the Phase 1 SA negotiations. All parameters must be congured on the remote access client and the core, except where noted. However, clients often do not have the same exibility to support various possibilities for a given parameter. For the remaining parameters, the default settings are usually the best suited for the Cisco VPN Unity SW Client and the VPN 3002 HW Client.
Figure 20-9 Specic SA Conguration Menu
660
Table 20-10 Precongured SAs for the VPN 3000 Concentrators 13 ESP3DESMD5 From Rule ESP/IKE3DESMD5 From Rule ESP3DESNONE From Rule ESP-L2TPTRANSPO RT From Rule ESP3DESMD5-DH7 From Rule
SA Name Parameter Inheritance
ESP-DESMD5 From Rule
IPSec Parameters
Authentication algorithm Encryption algorithm Encapsulation mode PFS Lifetime Measurement Data lifetime Time lifetime ESP/MD5/ HMAC-128 DES-56 Tunnel Disabled Time ESP/MD5/ HMAC-128 3DES-168 Tunnel Disabled Time ESP/MD5/ HMAC-128 3DES-168 Tunnel Disabled Time None 3DES-168 Tunnel Disabled Time ESP/MD5/ HMAC-128 DES-56 Transport Disabled Time ESP/MD5/ HMAC-128 3DES-168 Tunnel Disabled Time
10,000 KB 28,800 sec
10,000 KB 28,800 sec
10,000 KB 28,800 sec
10,000 KB 28,800 sec
10,000 KB 3,600 sec
10,000 KB
28,800 sec
IKE Parameters
IKE peer Negotiation mode Digital certicate IKE proposal
0.0.0.0
Main None (Use preshared keys) IKE-DESMD5
0.0.0.0
Main None (Use preshared keys) IKE-DESMD5
0.0.0.0
Main None (Use preshared keys) IKE-3DESMD5
0.0.0.0
0.0.0.0
0.0.0.0
Aggressive None (Use preshared keys) IKE-3DESMD5-DH7
Inheritance species the number of tunnels that should be built for each connection. It is more applicable for LAN-to-LAN VPN connections than for remote access VPN connections, as the alternatives are From Rule, one tunnel for each rule in the connection, or From Data, one tunnel for every address pair within the address range specied in the rule.
661
IPSec and IKE SA Parameters

Most parameter options are discussed in detail in Chapter 19; however, the following additional information might be required. The IKE peer is applicable only for LAN-toLAN VPNs. Congure the digital certicate option only if you are using PKI certicates, and then you must determine if you will send just the identity certicate, or the entire certicate chain. The IKE proposal parameter is applicable for LAN-to-LAN VPN environments, where the concentrator can be the initiator of the IPSec negotiations. In this scenario, the IKE proposal that is entered is the only proposal negotiated by the concentrator. This is opposite to when the concentrator responds to the IPSec negotiations.
User Conguration Highlights

This section highlights selected parameters that can be congured on the VPN 3000 Concentrator under the Conguration, User Management menus. The following specic menus refer to the Conguration, User Management, Groups menu, but the IPSec SA can also be congured for individual users under the Conguration, User Management, Users menu.
IPSec SA
In the previous section of this chapter, the parameters of the IPSec SA were covered. This section provides information when you select the IPSec SA under the IPSec tab of the specic user or group, as shown in Figure 20-10.
Figure 20-10 IPSec Conguration Menu for User Management
662
IKE Peer Identity Validation

IKE peer identity validation applies only to tunnel negotiations based on certicates. When congured, it provides an extra measure of security because the concentrator veries the identity of the client with information in the digital certicate, such as the hostname or IP address. If you want to implement this additional validation for clients, select this feature, as shown in Figure 20-10.
Group Lock
By setting the Group Lock parameter, you can congure the concentrator to authenticate users only if they are members of the group congured on an external RADIUS server. So the VPN client can be congured with an active group name and group password to provide a user prompt, and then be authenticated by a RADIUS server. However, if the server returns information that the user is a member of another group, the user fails authentication.14 Furthermore, by using this feature, VPN clients who authenticate as members of one group are restricted to use the features of the group that are authenticated, even if the client is a member of another group with different feature sets.
Conguration Mode
Conguration mode refers to the process and communications when the concentrator exchanges certain conguration parameters with the client, such as the DNS and Windows Internet Naming Service (WINS) server addresses, during the SA negotiation. Conguration mode must be congured if you want to implement split tunneling, local LAN access, or UDP encapsulation of IPSec trafc. Third-party VPN clients might not support Conguration mode and its parameters.
Client Firewall
The VPN 3000 Series Concentrators now support interaction with PC-based rewalls. Depending on your preference, you can require clients to use a rewall to allow them to establish a VPN tunnel, to push the rewall policy from the concentrator upon tunnel establishment, or to push the policy from a Zone Labs Integrity Server. Supported personal rewalls include these or later versions: Cisco Integrated Firewall (CIC), ZoneAlarm Pro 2.6, ZoneAlarm 2.6, BlackICE 2.5, and BlackICE Agent 2.5.
Cisco Remote Access VPN Clients

Client features and availability are constantly being updated. As a result, the focus in this section is limited to conguration information for only the following Cisco VPN clients:
Cisco VPN Unity SW Client (v3.5.1b) Cisco VPN 3002 HW Client (v3.5)
663

NOTE
Cisco Easy VPN Client (v12.2(4)YA+) Cisco PIX501 and PIX506 congured as a VPN client (v6.2)
Information on Cisco VPN products is constantly evolving. It is recommended to track Cisco.com for the most recent announcements.
Cisco VPN Unity Client

The Cisco VPN Unity Client is available for Windows, Linux, Solaris, and Macintosh OS platforms. Table 20-11 indicates the specic requirements for each platform.
Table 20-11 Cisco VPN Unity Client Compatibility Matrix 15, 16 Operating System Windows Requirement Windows 2000, NT 98 (V3.x or later) Windows XP V3.1 or later Linux Solaris Macintosh Red Hat v6.2 Linux (Intel) or compatible libraries w/glibc v2.1.1-6 or later, using kernel versions 2.2.12 or later Any ultraSPARC running 32-bit Solaris kernel OS version 2.6 or later Any Mac running OS X version 10.1.0 or later
The focus of this section is on the Windows compatible client. Clients for other operating systems have similar parameters that you must congure to negotiate, establish, and send data over an IPSec VPN tunnel. Items you must congure on the VPN Client include the following:
Connection name Host name or IP address of remote server Authentication parameters of Group Access Information (group name and group password) or Certicate Enabling transparent tunneling of IPSec over the following: UDPTo allow IPSec data transmission in NAT/PAT environments TCPIncluding the specic port enabled on the VPN concentrator (besides UDP encapsulation advantages, it also allows data transmission when you do not have access to the local rewall to permit the UDP encapsulation port, ISAKMP port, and protocol 50 ESP)
Options include the following:
664
Allow local LAN accessIf enabled in the VPN concentrators Peer response timeout30-480 seconds, and the default is 90 seconds Conguration of backup servers (concentrators)
Before conguring your clients, you must decide on all these parameters. The conguration information is stored in a prole, which is represented by a ConnectionName.pcf le, with the ConnectionName representing the connection name that you enter in the client. The ConnectionName.pcf le is stored in the Proles folder, under the Cisco VPN Unity Client program folder. The actual number of proles that you need to congure depends on how you identify the concentrators or clusters to your clients. You can use a product, such as Ciscos DistributedDirector, to enable one DNS entry to represent all of your concentrators or cluster environments. You also might elect to use a different prole for each cluster or concentrator. The conguration of the backup clusters or concentrators depends on how you congure clients to connect to the primary cluster or concentrator. For example, if you cannot use one entry that relies upon DistributedDirector to redirect clients to the closest cluster, you might want to list each of your specic clusters. However, if you point clients to a specic cluster, you might want to add clusters in order of anticipated latency from the primary cluster. When users launch the VPN Unity Client (ipsecdialer.exe), they can scroll to their preferred prole. The proles are listed in alphabetical order and the last prole that is selected by a client is normally the prole that the ipsecdialer.exe uses by default the next time that the client is started. Upon installation, the Windows VPN Unity Client automatically installs the following utilities to be used with the client:

NOTE
Set MTUChanges the maximum transmission unit (MTU) of a network interface Certicate ManagerAllows clients to install certicates Log ViewerHelpful for troubleshooting connectivity issues (refer to Chapter 21, Remote Access VPN Troubleshooting, and Chapter 22, Remote Access VPN Troubleshooting Scenarios.) HelpBrowser-based utility that points to a local le on a PC
One caveat worth mentioning is that after you have established an IPSec tunnel, the user cannot see the intermediate hops when running the traceroute (TRACERT.exe) command. However, if you have enabled and congured split tunneling, traceroutes function correctly over the unencrypted data path.
665
Cisco VPN 3002 HW Client

The VPN 3002 HW client provides the same functionality as the VPN Unity SW Client; however, it is platform independent because it provides an Ethernet interface for hosts. Actually, two versions of the 3002 existone with one port for the private interface and the other with an 8-port switch. Both models have one public interface. The IPSec VPN tunnel is established between the core concentrator and the 3002, so that any device connected to the private interface of the 3002 can access the central network. The VPN 3002 HW Client does offer two modes of client congurationNetwork Extension and PAT. As the name suggests, Network Extension mode is when the private interface is congured with an IP address that is routable in the network and connected to the concentrator that is terminating the VPN tunnel. In PAT mode, the 3002 performs address translation of addresses that are assigned to clients on the private interface. Currently, the advantage of Network Extension mode is that it provides support for a Cisco IP HW Telephone, and hosts on the public interface side can access resources that are connected to the private interface. The browser and CLI interfaces of the VPN 3002 HW Client are similar to the interface on the VPN 3000 Series Concentrators. The 3002 HW Client has a Quick Conguration feature that allows users to congure the client right out of the box, without requiring a console connection. However, congurable options are different between the HW client and the concentrators. The Quick Conguration menu has the following options:
TimeSets date and time on the client. Upload CongAllows you to upload the conguration le to the client. Private InterfaceSets the IP address and subnet mask on the interface, with the option to set the 3002 as a DHCP server with an address pool. Public InterfaceAllows you to congure the 3002 HW client as a DHCP client (default), Point-to-Point Protocol over Ethernet (PPPoE) client, or with a static IP address. IPSecSimilar to the Unity SW Client; congures preshared secret information or certicates besides tunneling in TCP. PATCongures a client to perform PAT or Network Extension (see next section). DNSThe IP address of the service providers DNS server, which can be learned through DHCP or PPPoE. Static RoutesNormally learned through DHCP or PPPoE; only required if the IP address is statically congured on the 3002. AdminChanges password facility.
666
Additional settings for these parameters can be congured under the Conguration, System menu with the exception of the PAT/Network Extension, which is enabled under the Conguration, Policy Management, Trafc Management menu. You cannot congure the following DHCP options on the 3002 HW client when its congured as a DHCP client:
Subnet mask Router DNS Domain name NetBios Name Server(s)/WINS
These DHCP options are congured on the central-site concentrator for the group that is specied for the VPN 3002 Hardware Client. As is the case for all group conguration parameters, the central-site concentrator pushes these values to the VPN 3002 over the tunnel.17 Similar to a VPN 3000 Concentrator, the 3002 HW Client offers features to limit access, and to collect operational data under the Conguration, System, Management Protocols and Conguration, System, Events menus.
Cisco Easy VPN IOS Client

The Cisco Easy VPN Client offers most of the functionality of the Cisco VPN 3002 HW client in specic IOS platforms. The Cisco Easy VPN Client feature was rst released in Cisco IOS 12.2(4)YA for the following Cisco routers:
The Cisco 806, 826, 827, and 828 from the 800 series routers The Cisco 1700 series routers The Cisco uBR905 and uBR925 cable access routers18
Similar to the 3002, the Easy VPN Client supports two modes of operationClient mode and Network Extension mode. In Client mode, the Easy VPN Client uses NAT/PAT to provide network connectivity to devices that are connected to the Ethernet interface(s). The NAT/PAT feature is automatically created by the router when the VPN tunnel is established. A conguration for a Cisco 806 router, congured as an Easy VPN Client in Client mode, is shown in Example 20-1.
Example 20-1
Conguration of a Cisco 806 Router That Is Congured as an Easy VPN Client in Client Mode
version 12.2 no service pad service timestamps debug uptime
667
Example 20-1
Conguration of a Cisco 806 Router That Is Congured as an Easy VPN Client in Client Mode (Continued)
service timestamps log uptime no service password-encryption ! hostname Router ! ip subnet-zero ip name-server 192.168.168.183 ip name-server 192.168.226.120 ip dhcp excluded-address 10.10.10.1 ! ip dhcp pool CLIENT import all network 10.10.10.0 255.255.255.0 default-router 10.10.10.1 dns-server 192.168.226.120 192.168.168.183 lease infinite ! ip ssh time-out 120 ip ssh authentication-retries 3 ! crypto ipsec client ezvpn test ! The command is crypto ipsec client <name> groupname testgroup key grouppw ! The command is group <groupname> key <group-password> mode client ! Set for Client mode (change to mode network-extension for ! Network Extension mode) peer 192.168.192.81 ! Address on the tunnel terminating device (DNS name can also be entered) ! interface Ethernet0 ip address 10.10.10.1 255.255.255.0 hold-queue 100 out ! interface Ethernet1 ip address 192.168.87.252 255.255.255.254 crypto ipsec client ezvpn test Assigns the Easy VPN configuration to the interface. ! ip classless ip route 0.0.0.0 0.0.0.0 Ethernet1 ip http server ip pim bidir-enable ! line con 0 stopbits 1 line vty 0 4 login ! scheduler max-task-time 5000 end
668
NOTE
If NAT/PAT is already congured on the CPE and you start to congure it as an Easy VPN Client, the original NAT/PAT conguration information is automatically overwritten upon establishing the VPN tunnel by using the Easy VPN Client. The ip nat inside or the ip nat outside commands, under the private and public interfaces for the IOS device, are eliminated from the conguration.
You cannot view the NAT/PAT congurations as you normally do with the show run command. Instead, after the connection is established, you can view this information by using the show access-list and show ip nat statistics commands. In Network Extension mode, after the tunnel is established, devices behind the Easy VPN Client appear as entities on your organizations network. The Easy VPN Client also supports split tunneling in either Client or Network Extension mode, if the tunnel terminating device is congured to permit this feature. After conguration of the router as an Easy VPN Client is complete, you can start the Extended Authentication (XAUTH) login sequence by using the crypto ipsec client ezvpn xauth command. This command prompts the user to enter their username and password. The user can use the show crypto ipsec client ezvpn command to determine if the tunnel has been successfully established. If the VPN tunnel is successfully established, the results of this command are shown in Example 20-2. If the tunnel is not established, the user is prompted with the following response on the Easy VPN router:
EZVPN: Pending XAuth Request, Please enter the following command: EZVPN: crypto ipsec client ezvpn xauth
Example 20-2
Results of Running the show crypto ipsec client ezvpn Command on an Easy VPN Client Congured for Client Mode, After Establishing a Successful VPN Tunnel
Router#show crypto ipsec client ezvpn Current State: IPSEC_ACTIVE Last Event: SOCKET_UP Address: 10.25.254.1 ! Note this address and the following mask are assigned by the VPN ! tunnel terminating device upon authentication for Client Mode only; ! it is not assigned in Network Extension mode. Mask: 255.255.255.255 DNS Primary: 192.168.226.120 DNS Secondary: 192.168.168.183 NBMS/WINS Primary: 192.168.2.87 NBMS/WINS Secondary: 192.168.235.228 Default Domain: abc.com
669
NOTE
At the time of writing, the Easy VPN Client does not support digital certicates and the PFS feature on the VPN 3000 Concentrators. Similar to the Cisco VPN Unity SW Client, the Easy VPN Client only supports ISAKMP Group 2 policies (DH 1024-bit key). For the latest product information, see Cisco.com.
Cisco PIX 501 and 506 VPN Client

With the release of v6.2 for the PIX operating system (OS), the PIX 501 and PIX 506 provide the functional equivalent to the Cisco VPN 3002 HW Client. Similar to the VPN 3002 HW Client and the Easy VPN IOS Client, the PIX 501 and PIX 506 support both Client and Network Extension modes. Digital certicate support in Client mode is not available at this time. The commands to congure the PIX as a remote access VPN HW client starts with the keyword vpnclient. This feature makes it easier for you to differentiate between commands that are required to congure the PIX as a HW client, as opposed to conguring the PIX as a core device that terminates the remote access VPN tunnels. The commands required to congure the VPN client features on the PIX v6.2OS are shown in Table 20-12.
Table 20-12 Commands and Their Format for Setting the VPN Client Features on the PIX 501 with v6.2OS VPN Client Commands on PIX 501 with v6.2OS vpnclient vpngroup group_name password preshared_key Explanation Sets preshared key
vpnclient username xauth_username password xauth_password Sets username vpnclient peer ip_primary [ip_secondary_1...ip_secondary_n] vpnclient mode {client-mode | network-extension-mode} vpnclient enable no vpnclient {vpngroup | username | peer | mode | enable} show vpnclient clear vpnclient Sets IP address of core tunnel terminating device Sets VPN client mode Activates VPN client feature Removes or disables the specied feature Displays VPN client congured features Removes all VPN client features
On the PIX 501 console, after establishment of the VPN tunnel, you should see results for Client and Network Extension mode as shown in Example 20-3 and Example 20-4. The PIX client that is congured for Client mode operation includes many parameters that are
670
not pushed down to the client that is congured for Network Extension mode upon establishment of the VPN tunnel.
Example 20-3
Results of show vpnclient Command After Establishing a VPN Tunnel in Client Mode
pixfirewall# show vpnclient Local Configuration vpnclient vpngroup pix password ******** vpnclient username test password ******** vpnclient peer 192.168.192.81 vpnclient mode client-mode vpnclient enable Downloaded Dynamic Policy ! IP address assigned by the VPN tunnel terminating device: NAT addr : 10.25.254.1 ! Pushed down from tunnel terminating device: Primary DNS : 192.168.226.120 ! Pushed down from tunnel terminating device: Secondary DNS : 192.168.168.183 ! Pushed down from tunnel terminating device: Primary WINS : 192.168.2.87 ! Pushed down from tunnel terminating device: Secondary WINS : 192.168.235.228 ! Pushed down from tunnel terminating device: Default Domain : abc.com ! Note that terminating device did not require PFS: PFS Enabled : Current Peer : 192.168.192.81 ! DNS configured on the PIX, and active if split-tunneling is ! enabled on the VPN tunnel terminating device Split DNS : def.com_
Example 20-4
Results of show vpnclient Command After Establishing a VPN Tunnel in Network Extension Mode
pixfirewall# show vpnclient Local Configuration vpnclient vpngroup pix password ******** vpnclient username test password ******** vpnclient peer 192.168.192.81 vpnclient mode network-extension-mode vpnclient enable Downloaded Dynamic Policy PFS Enabled : No Current Peer : 192.168.192.81 Split DNS : def.com_
By default, the PIX 501 with v6.2 is congured as a DHCP server with PAT to enable hosts that are connected to the inside interface to access external hosts. You can congure the VPN client parameters when you attempt to enable the VPN client by using the command
End Notes
671
vpnclient enable. You must remove any access-lists and PAT address pools that support PAT/NAT. If you attempt to enable the VPN client feature while PAT/NAT rules or global pools are in effect, you receive a notice indicating that you must attempt to enable the VPN client only after removing those items. Similar to the VPN 3002 and most of the routers that support the Easy VPN IOS Clients, the PIX 501 can be congured as either a DHCP client on the public interface (default), a PPPoE client, or with a static IP address.
End Notes
1 2
SAFE Blueprint. http://wwwin.cisco.com/ent/vsec/safe/. www.cisco.com/univercd/cc/td/doc/product/vpn/vpn3000/3_5/getting/ gs1und.htm#xtocid3. www.cisco.com/univercd/cc/td/doc/pcat/3000.htm#xtocid2. www.cisco.com/univercd/cc/td/doc/product/software/ios122/122newft/122t/122t8/ ftunity.htm. www.cisco.com/univercd/cc/td/doc/product/software/ios122/122newft/122t/122t8/ ftunity.htm. Others suggest that 402.7 bytes is the average size (see http://advanced.comms.agilent. com/routertester/member/journal/1MxdPktSzThroughput.html). However, a packet size of 576 is approximately 50 percent of the packet size distribution.
3 4
6 Most sources identify 576 as an average size of packets over the Internet (see RFC 1191).
www.cisco.com/univercd/cc/td/doc/product/vpn/vpn3000/3_5/getting/ gs2inst.htm#xtocid19. www.cisco.com/univercd/cc/td/doc/product/vpn/vpn3000/3_5/getting/ gs2inst.htm#xtocid20. RFC 2338. www.cisco.com/warp/public/471/vrrp.html. www.cisco.com/warp/public/471/ld_bl_vpn3000_7602.html. Cisco VPN 3000 Concentrator IKE Proposals Help. VPN Concentrator 3.5 Help menu, Conguration, Policy Management, Trafc Management, SA. www.cisco.com/warp/public/471/vpn_3000_auth.html. Release Notes for Cisco VPN Client for Windows, Release 3.5.1; www.cisco.com/ univercd/cc/td/doc/product/vpn/client/rel3_5_1/351_3kcl.htm.
10 11 12 13
14 15
672
16
Installing the VPN Client User Guide for Linux, Solaris, and Mac OS X. www.cisco.com/univercd/cc/td/doc/product/vpn/client/nonwin35/user_gd/index.htm. Cisco VPN 3002 Help menu, v3.5.2. www.cisco.com/univercd/cc/td/doc/product/software/ios122/122newft/122limit/122y/ 122ya/122ya4/ftezvpcm.htm.
17 18
Summary
This chapter covered remote access VPN design and conguration solutions. The design part denes the remote access VPN design objectives, considerations, and architectural guidelines. The conguration part is focused primarily on using the Cisco VPN 3000 Concentrator as a core termination device and VPN clients based upon the Cisco Unity VPN client, the Hardware Client, the Easy VPN Client, and PIX-based clients.
Review Questions
1 Why is the AH protocol considered less secure than ESP? 2 Which part of the ESP packet is not protected? 3 What is a one-to-many NAT or PAT? 4 What is split tunneling? 5 Name the three main types of rewalls. 6 Describe how to calculate the session load on the VPN concentrator. 7 What does VRRP stand for? 8 What is Reverse Route Injection? 9 What is the Group Lock conguration in a VPN concentrator? 10 Name the two mandatory settings on your VPN client. 11 Dene the network extension mode for the VPN 3002 Client. 12 For the Router-EzVPN, type the IOS command to start the XAUTH login sentence. 13 When typing IOS command show crypto ipsec client ezvpn, how do you nd out if
IPSec is up and running?

14 In PIX 501, how do you check if you are running Client mode, or Network Extension
mode?
CHAPTER
21
Remote Access VPN Troubleshooting

Virtual Private Network (VPN) is private networking over public networks. In the troubleshooting context, this implies different narrowband and broadband technologies as Internet access alternatives. The technologies discussed in Part II, Dial, Part III, ISDN, and Part IV, Frame Relay, are not known to pose any restrictions over VPN. If they do, it is not technology-related, but a VPN-related issue, and all the principles of VPN troubleshooting apply. For this reason, more detailed information is provided in this chapter for technologies that require specic knowledge and adjustments when used with VPN. The emphasis is on the client side because the client issues and problems supercede all others combined. To facilitate troubleshooting, the entire VPN implementation chain is divided into three areas:
Troubleshooting of Cisco remote access VPN clients, which includes the following: Cisco VPN Unity software client troubleshooting Cisco 3002 HW client troubleshooting Cisco Easy VPN client troubleshooting Cisco PIX hardware client troubleshooting
Internet technologies and remote access VPNs sections include VPN-related troubleshooting information for the following technologies: VPN and asymmetric DSL (ADSL) VPN over cable VPN over wireless and satellite
Local-area networks (LANs) and remote access VPNs sections are focused on common networking issues that affect VPN connections.
The information in this chapter allows you to show and debug some VPN events. Additionally, the VPN clients and the VPN concentrator allow you to review post-factum large log les for troubleshooting purposes. Some of the outputs are provided in this chapter because of their importance, despite their large size. It is important to review your performance criteria before approaching VPN troubleshooting.
676
Chapter 21: Remote Access VPN Troubleshooting
Troubleshooting Cisco Remote Access VPN Clients

Ciscos remote access IPSec-based VPN solution includes the Unity software (SW) client, the 3002 VPN Hardware (HW) client, the 806/17xx IOS-based easy VPN and PIX-based VPN clients. See Chapter 19, VPN Technology Background, and Chapter 20, Remote Access VPN Design and Conguration Solutions for details. In this chapter, common VPN troubleshooting techniques and recommended approaches (methodologies) are provided. The examples are demonstrated using the Cisco 3000 family of concentrators as termination devices for the following remote access solutions:
Cisco VPN Unity SW client Cisco 3002 HW client Cisco Easy VPN client Cisco PIX VPN client
First, general restrictions and limitations exist for each solution. After these are understood, actual operational issues can be resolved by isolating the components that might affect the establishment of an IPSec VPN tunnel, and the ow of data through the tunnel. By using the initial troubleshooting tools, you isolate the source of the issue to one or more areas, then further investigate until the actual cause is identied and corrective actions are implemented.
Cisco VPN Unity SW Client

In this section, you focus on the Cisco VPN Unity SW client. The following sections address the client in the following order:
Restrictions and limitations Initial problem identication and troubleshooting Cisco VPN Unity client event log Cisco 3000 concentrator event log
Restrictions and Limitations of the Cisco VPN Unity Software Client

The Cisco VPN Unity client on the Windows 2000 (W2K) host has several restrictions and limitations, which serve as a foundation for the other remote access solutions that are covered in this chapter; specically, the text includes the 3002 VPN HW client, and the Easy VPN client that operates on a Cisco 806 router. In sections dedicated to these alternative solutions, differences between them and the Cisco VPN Unity client, and any unique circumstances that might be applicable, are highlighted.
677
The following briey summarizes the major restrictions and limitations of the Unity client. They are listed in Table 21-1:
The Cisco VPN Unity client cannot function correctly if installed on a host on which another VPN client has been installed. You can install other VPN clients on the same host and use them, but then you cannot use your Cisco VPN Unity client. The native VPN client included in Microsoft W2K and other Windows platforms is not compatible with the IPSec implementation on Cisco 3000 concentrators, which forces you to ensure that on a W2K platform, the MS IPSec Policy Agent is completely disabled. If a software rewall, such as Zone Alarm Pro from Zone Labs, is installed on the host, the maximum security setting must not be congured, to allow the VPN client to function. This setting and the terminology varies for each rewall that is compatible with the Unity client. You cannot view multicast streams through the VPN client at this time. VPN clients can participate as a client when using Microsoft NetMeeting for data sharing and collaboration applications, but cannot host the meeting. This varies among data collaboration solutions.
NOTE
Although you can congure the Unity client to enable viewing of multicast sessions through applications such as Cisco IP/TV, the conguration requires access to a multicastenabled UNIX host that is beyond what can be implemented for most clients.
NOTE
Remote users must be made aware of security policies and restrictions such as split tunneling, especially if it is not permitted because the user cannot reach LAN devices when the tunnel is established. Some of these restrictions might no longer be applicable, and readers are encouraged to review the latest status at www.cisco.com.
Finally, the security administrator of the network must open the required IP protocol, User Datagram Protocol (UDP) ports, and Transmission Control Protocol (TCP) ports necessary to establish and transmit data across the IPSec tunnel and permit it through the corporate rewalls.
678
Table 21-1
Cisco VPN Unity Client Restrictions and Limitations When Choosing MD5-ESP-3DES Tunnel Mode Requirement Corrective Action
Restriction/Limitations Host Only the Cisco VPN client can be installed on the PC.
Verify that no other VPN client is installed on the PC.
Check the Start, Settings, Control Panel, Add/Remove Programs to determine that no other VPN clients have been installed. If they have, you must uninstall that client. To ensure smooth operation, you might want to also uninstall the Cisco VPN Unity client, shut down the PC, and then reinstall it. To disable and stop the service: Start, Settings, Network and Dial-Up Connections, your active network connection, Properties, Internet Protocol (TCP/IP), Advanced, Options, IP Security, Properties, Do not use IPSECthen restart PC, as shown in Figure 21-1. Verify the State and Start Mode of the IPSEC Policy: Start, Programs, Accessories, System Tools, System Information, Software Environment, Services, as shown in Figure 21-2.
MS IPSEC Policy Agent should not be active.
IPSec Policy Service Agent State mode should be stopped and the Start mode should be disabled.
TCP/IP ltering does not permit trafc on the required ports to establish a VPN tunnel.
Disable TCP/IP ltering, or if required, permit necessary TCP or UDP Network Address Translation (NAT) encapsulation ports (default is 10,000).
To verify and permit required trafc: Start, Settings, Network and Dial-Up Connections, your active network connection, Properties, Internet Protocol (TCP/IP), Advanced, Options, TCP/IP ltering, Enable TCP/IP Filtering (all adapters) should not be checked. An alternative is to permit IP protocol 50 (Encapsulating Security Payload [ESP]) and UDP Port 500 (Internet Security Association and Key Management Protocol [ISAKMP]), and if necessary, permit the TCP or UDP port for encapsulation in the respective protocol (default on the concentrator is 10,000 but is congurable on the concentrator) (see Figure 21-3). As an example, on Zone Alarm Pro from Zone Labs, the Security Settings must be set at medium or low for LAN and Internet access, as shown in Figure 21-4. The multicast trafc ows must be converted to a unicast session. A workaround can be implemented if you have access to a multicast enabled UNIX host.
Personal rewall blocks access for the client.
Adjust settings on the rewall to maximum security that permits Cisco VPN Unity client to establish tunnel and send/receive data. The Cisco 3000 concentrators and the Cisco VPN Unity client do not support multicast at the time this book was written.
Cannot view multicast streams.
679
Table 21-1
Cisco VPN Unity Client Restrictions and Limitations When Choosing MD5-ESP-3DES Tunnel Mode (Continued) Requirement Corrective Action
Restriction/Limitations Host Cannot host real-time collaboration sessions.
The Cisco VPN Unity client does not permit hosting of real-time collaboration sessions for some applications. Clients must be informed that policy is pushed from core.
The workaround is to host the session from a user on the corporate intranet and require VPN clients to connect to it, or use a collaboration solution that works with the Unity client, such as Lotus Sametime. On the core concentrator split tunneling is controlled through Conguration, User Management, Base Group or Groups, Mode Cong menu.
Split-tunneling policy is controlled from the central concentrator. LAN Local and remote rewalls permit VPN connectivity.
To establish an IPSec VPN tunnel and send trafc over it, local and remote rewalls must permit IP protocol 50 ESP, UDP port 500 ISAKMP, and the TCP or UDP port encapsulation (if applicable).
Verify that the local and remote rewalls allow the required protocols through the rewall. Conrm that the tunnel can be successfully established from behind the rewall. If the core concentrator is congured for UDP or TCP encapsulation, conrm the port set on the client, as shown in Figure 21-5. TCP encapsulation is available in VPN 3.5x and higher.
Figure 21-1 IPSec Policy Setting
680
Figure 21-2 IPSec Policy Agent Setting
NOTE
To prevent a conict with other VPN clients and the Cisco VPN Unity client, the VPN 3.5x installer (and later versions) automatically issues a warning and permits the user to disable the IPSec Policy Agent Service. If this service is not disabled, the error message, The necessary sub-system is not available, is displayed when the user starts the VPN client. See Table 21-2 for more information.
681
Figure 21-3 TCP/IP Filter Set Menu
Figure 21-4 Security Settings on Zone Alarm Client
682
Figure 21-5 Setting the Tunnel Port on Cisco VPN Unity Client
Initial Problem Identication and Troubleshooting with the Cisco VPN Unity SW Client
Assume that you successfully set up the core concentrator and security environment, and conrmed that remote users can successfully establish an IPSec tunnel to send and receive data across the tunnel using the Cisco VPN Unity client. Based on the problem reported by a user experiencing issues, potential sources and suggested corrective action are listed in Table 21-2.
683
Table 21-2 Issue Host
Initial Troubleshooting Checklist for Cisco VPN Unity Client Possible Source Corrective Action
1. User never receives the Authenticating user . . . prompt during the initial dialer connection attempt (see Figure 21-6).
a. Internet Connectivity and Domain Name System (DNS) services. Conrm that the user can access public Internet sites such as www.cisco.com from the host by using ping or a browser.
If the client cannot access public Internet sites, run Start, Run, CMD, IPCONFIG and verify IP address information. If the user cannot ping the local gateway from the host, you must work with a LAN administrator to resolve basic network connectivity, or conrm Point-to-Point Protocol over Ethernet (PPPoE) username and password if using a PPPoE SW client, such as RASPPPoE. Verify the host name and IP address entered in the host name or IP address of the remote server block of the Cisco VPN Unity client dialer. Request user run NSLOOKUP, Go to Start, Run, CMD, NSLOOKUP <Hostname> to verify host lookup function. If the user cannot resolve the hostname of the concentrator from the host, recongure the Cisco VPN Unity Client prole with the specic IP address of the core concentrator, and contact LAN support to resolve. Verify the groupname and groupname password in the Cisco VPN Unity client prole Options, Properties, Authentication. Verify that the installed Cisco VPN Unity client is version 3.5 or later, and the prole is congured with one of the TCP encapsulation ports congured on the core concentrator. Options, Properties, General. Verify if the remote LAN permits one of the required combinations of trafc: ESP and ISAKMP ISAKMP and UDP (default 10,000) encapsulation port congured on the concentrator continues
b. IP address or host name of concentrator might be incorrect.
c. DNS services are not working correctly. User cannot resolve host name of core concentrator from the Cisco VPN Unity client host.
d. Group name and group password might not match the concentrator.
e. Cisco VPN Unity client is not congured with the correct TCP encapsulation port.
f. Required protocols and ports are not permitted through the local rewall to the Internet. To establish an IPSec VPN tunnel and send trafc over it, local and remote rewalls must permit IP protocol 50 (ESP) and UDP port 500 (ISAKMP), or UDP port 500 and the UDP port used for encapsulation of the
684
Table 21-2 Issue
Initial Troubleshooting Checklist for Cisco VPN Unity Client (Continued) Possible Source ESP trafc, or the TCP port used for encapsulation of both ESP and ISAKMP trafc. The core concentrator must be congured for encapsulation of UDP or TCP for clients to establish a tunnel through encapsulation. g. Gateway router on users LAN might not correctly handle redirects if trying to connect to a cluster instead of a specic concentrator. h. Maximum transmission unit (MTU) must be reduced to =< MTU of the segment with the lowest MTU between the client and the concentrator. Corrective Action TCP encapsulation port congured on the concentrator (usually but not limited to a port already opened for other trafc, such as port 80, 443 or 22)
Recongure Cisco VPN Unity client prole to connect to a specic concentrator. Verify if IPSec tunnel can be established. Run SetMTU utility to reduce MTU on network interface card (NIC), or if applicable, change MTU in PPPoE SW client to a size that permits a connection (See the sections, MTUA Critical Factor for Troubleshooting Internet IPSec Connectivity, and VPN and Asymmetric DSL). If host is behind a NAT device, conrm that UDP encapsulation is congured on the concentrator. Also verify that the Cisco VPN Unity client prole on the host supports UDP encapsulation, and is congured with the UDP encapsulation port supported by the concentrator. Run SetMTU utility to reduce MTU of the NIC, or if applicable change the MTU in the PPPoE SW client (such as RASPPPoE) to a size that permits a connection (see the sections, MTUA Critical Factor for Troubleshooting Internet IPSec Connectivity and VPN and Asymmetric DSL). Verify with your system administrator if split tunneling is enabled.
2. User is connected and authenticated but cannot pass any trafc.
a. Determine if the host is connected to a device that performs NAT. If yes, verify that the user has a selected prole that supports UDP encapsulation of IPSec trafc on the Cisco VPN 3000.
b. MTU must be reduced to =< MTU of the segment with the lowest MTU between the host and the concentrator.
3. User cannot access devices on the local network behind the NAT device. 4. User receives the message VPN Client Subsystem cannot be started.
Split tunneling might not be enabled by the administrator.
a. The Cisco VPN Daemon (CVPND) service cannot be started.
Verify that the MS IPSEC Policy Agent is stopped and is disabled (see Figure 21-2).
685
Table 21-2 Issue
Initial Troubleshooting Checklist for Cisco VPN Unity Client (Continued) Possible Source b. Corrupt installation of Cisco VPN Unity client. Corrective Action Uninstall the Cisco VPN client. Shut down the host, then reinstall the Cisco VPN Unity client from a different source le. See the section, Incompatible GINAs and Workarounds. For the NAT device, switch to a device or SW version that does not require the UDP source port of an ISAKMP exchange to be 500. See the section, Multiple VPN Clients Behind a NAT Device in the LAN section of this chapter.
5. User cannot log in to Windows after installation of the VPN client. 6. User cannot establish two concurrent IPSec VPN tunnels from two hosts connected behind the same router to the same concentrator. When the second Cisco VPN Unity client authenticates, the rst client is disconnected.
Incompatible Graphical Identication and Authentication (GINA) program. If the router performs NAT/Port Address Translation (PAT), it might be designed to force the ISAKMP UDP source port to 500, for all IPSec tunnels from devices behind the router, regardless if a VPN tunnel is already established.
Figure 21-6 Cisco VPN Unity Client Dialog Box Indicating Authentication Process Has Been Initiated Between the Client and the Concentrator with an IP Address of 192.68.1.2
Cisco VPN Unity Client Event Log

The VPN Client Event Log Viewer provides a real-time event log of the VPN client from starting the connection, negotiating authentication, maintaining the connection, and terminating the VPN tunnel. The Log Viewer collects event messages from all processes that contribute to the client-peer connection, and it can be especially helpful if you cannot
686
identify the source of a problem for a client in an environment that you do not have access to or cannot replicate. Also, if you believe you have identied a bug with the client or have other reasons to open a Technical Assistance Center (TAC) case, you will most likely be required to provide a copy of the Log Viewer event log. Sometimes, you might nd it helpful to collect and examine the log information on the core concentrator that terminates the remote access VPN session. For your reference, this section of the text is divided into the following sections:
Starting the Client Log Viewer ISAKMP and Its Phases Reviewing a VPN Client Log
Starting the Client Log Viewer

To start the Log Viewer on a W2K host, select Start, Programs, Cisco Systems VPN Client, Log Viewer. The Log Viewer displays its main window upon startup. The VPN client version is indicated under the Help option. To collect the log information, the client must turn on the capture feature, under Options, Capture. By default, the lter is set to low for the ten log classes identied in the Log Viewer, as shown in Table 21-3. As a result, you might not see the required events displayed in the Log Viewer. To change the lter for a specic event class, select Options, Filter, or click the Filter icon. You should see the screen shown in Figure 21-7. Next, select the event class lters you want to change, right-click your selection and change the lter verbose level to the desired setting. For the purposes of working with remote clients, it is easier to instruct the client to change all lters to high. When using the Log Viewer with the high lter setting, it might impact performance of all applications on the clients PC, but there is no impact to performance when it is not in use.
Table 21-3 Event Generating Classes in the VPN Client 1 Class Name CERT Denition Certicate management process, which handles getting, validating, and renewing certicates from certicate authorities. CERT also displays errors that occur as you use the application. Command line interface, which is used instead of Windows ipsecdialer application. Connection manager, which drives VPN connections. It dials a PPP device, congures IKE for establishing secure connections, and manages connection states. Cisco VPN Daemon (main daemon), which starts client services and controls messaging process and ow.
CLI CM
CVPND
687
Table 21-3
Event Generating Classes in the VPN Client 1 (Continued) Class Name DIALER FIREWALL IKE IPSEC PPP XAUTH Denition Windows-only component, which handles conguring a prole, initiating a connection, and monitoring. Available in versions that support rewall SW client integrated operations with the VPN client. Internet Key Exchange module, which manages secure associations. IPSec module, which obtains network trafc and applies IPSec rules to it. Point-to-Point Protocol. Extended authorization application, which validates a remote users credentials.
Figure 21-7 Software VPN Log Filter
ISAKMP and Its Phases

Before you review the log, a brief review is required of the ISAKMP and IPSec negotiation phases and modes (see Chapter 19 for more information). Recall that ISAKMP has two phases: Phase 1 establishes a secure channel between ISAKMP peers that negotiate the parameters of the Phase 2 services.
688
Phase 1 has two modes: Main mode and Aggressive mode. After Phase 1 negotiation is successfully completed, Phase 2 negotiation occurs. Phase 2 ISAKMP also negotiates security parameters for the actual data transfer over the secure channel. Phase 2 only has one modeQuick mode. After Phase 2 negotiation is complete, the VPN peers exchange data over their secure IPSec tunnel.
Reviewing a VPN Client Log

The log of a successful VPN client connection is reviewed in Example 21-1. Example 21-1 is the captured Log Viewer results of a version 3.0 Unity client. Each entry is numbered, has a time and date stamp, is marked with a severity level (1-6) with 1 being the most severe, and is noted with a specic event class and message ID. Example 21-1 provides detailed output from two separate processes: establishing the VPN connection and termination of the VPN connection. It is relatively large, which is why inline comments help you to comprehend the content. This type of connect-disconnect scenario is rare in the real world. However, when a troubleshooting problem arises and is beyond the scope of well-known issues, this is a possibility with which you need to be familiar.
Example 21-1
Log Viewer Results for Establishing and Terminating a VPN v3.5.2 Unity Client
***** 1 05:52:44.564 07/15/02 DIALER/0x63300002 Initiating connection. 2 05:52:44.564 07/15/02 CM/0x63100002 Begin connection process Sev=Info/6
Sev=Info/4
3 05:52:44.584 07/15/02 Sev=Info/4 CM/0x63100004 Establish secure connection using Ethernet 4 05:52:44.584 07/15/02 Sev=Info/4 CM/0x63100026 Attempt connection with server vpn-concentrator.xyz.com ! Core VPN concentrator is vpn-concentrator.xyz.com. 5 05:52:44.604 07/15/02 Sev=Info/6 IKE/0x6300003B Attempting to establish a connection with 192.68.192.81. ! Core VPN concentrator IP address is 192.168.192.81. 6 05:52:44.644 07/15/02 Sev=Info/4 IKE/0x63000013 SENDING >>> ISAKMP OAK AG (SA, KE, NON, ID, VID, VID, VID) to 192.68.192.81 ! OAK=Oakley
689
Example 21-1
Log Viewer Results for Establishing and Terminating a VPN v3.5.2 Unity Client (Continued)
! ! ! ! ! ! ! AG=Aggressive Mode SA=Security Association KE=Key Exchange NON=Nonce ID=Identifier HASH VID=Vendor Identifier
7 05:52:44.804 07/15/02 Sev=Info/5 IKE/0x6300002F Received ISAKMP packet: peer = 192.68.192.81 8 05:52:44.804 07/15/02 Sev=Info/4 IKE/0x63000014 RECEIVING <<< ISAKMP OAK AG (SA, KE, NON, ID, HASH, VID, VID, VID, VID) from 192.68.192.81 9 05:52:44.804 07/15/02 Sev=Info/5 IKE/0x63000059 Vendor ID payload = 12F5F28C457168A9702D9FE274CC0100 10 05:52:44.804 07/15/02 Sev=Info/5 IKE/0x63000001 Peer is a Cisco-Unity compliant peer ! Client authentication. Successful verification for trusted source. ! Group name and password is verified. 11 05:52:44.804 07/15/02 Sev=Info/5 IKE/0x63000059 Vendor ID payload = 09002689DFD6B712 12 05:52:44.804 07/15/02 Sev=Info/5 IKE/0x63000059 Vendor ID payload = AFCAD71368A1F1C96B8696FC77570100 13 05:52:44.804 07/15/02 Sev=Info/5 IKE/0x63000001 Peer supports DPD ! DPD: Dead Peer Detection. The client will send a series of query ! packets to the core concentrator if it does not receive a ! response to data it has sent. ! If there is no response after a predefined time period, ! (90 seconds is the default) then the client will assume ! the IPSec connection is inactive and tear it down. 14 05:52:44.804 07/15/02 Sev=Info/5 IKE/0x63000059 Vendor ID payload = 1F07F70EAA6514D3B0FA96542A500305 15 05:52:44.834 07/15/02 Sev=Info/4 IKE/0x63000013 SENDING >>> ISAKMP OAK AG *(HASH, NOTIFY:STATUS_INITIAL_CONTACT) to 192.68.192.81
continues
690
Example 21-1
16 05:52:44.854 07/15/02 Sev=Info/5 IKE/0x6300002F Received ISAKMP packet: peer = 192.68.192.81 17 05:52:44.854 07/15/02 Sev=Info/4 IKE/0x63000014 RECEIVING <<< ISAKMP OAK TRANS *(HASH, ATTR) from 192.68.192.81 18 05:52:44.854 07/15/02 Sev=Info/4 CM/0x63100015 Launch xAuth application ! User authentication launched. 19 05:52:45.585 IPSEC/0x63700014 Deleted all keys 07/15/02 Sev=Info/4
20 05:52:51.024 07/15/02 CM/0x63100017 xAuth application returned
Sev=Info/4
21 05:52:51.024 07/15/02 Sev=Info/4 IKE/0x63000013 SENDING >>> ISAKMP OAK TRANS *(HASH, ATTR) to 192.68.192.81 22 05:52:51.334 07/15/02 Sev=Info/5 IKE/0x6300002F Received ISAKMP packet: peer = 192.68.192.81 23 05:52:51.334 07/15/02 Sev=Info/4 IKE/0x63000014 RECEIVING <<< ISAKMP OAK TRANS *(HASH, ATTR) from 192.68.192.81 24 05:52:51.334 07/15/02 Sev=Info/4 CM/0x6310000E Established Phase 1 SA. 1 Phase 1 SA in the system ! Phase 1 Security Association has been successfully established. 25 05:52:51.354 07/15/02 Sev=Info/4 IKE/0x63000013 SENDING >>> ISAKMP OAK TRANS *(HASH, ATTR) to 192.68.192.81 26 05:52:51.535 07/15/02 Sev=Info/5 IKE/0x6300005D Client sending a firewall request to concentrator 27 05:52:51.535 07/15/02 Sev=Info/5 IKE/0x6300005C Firewall Policy: Product=Cisco Integrated Client, Capability= (Centralized Policy Push). ! Cisco VPN Unity Client has integrated firewall
691
Example 21-1
28 05:52:51.535 07/15/02 Sev=Info/4 IKE/0x63000013 SENDING >>> ISAKMP OAK TRANS *(HASH, ATTR) to 192.68.192.81 29 05:52:51.575 07/15/02 Sev=Info/5 IKE/0x6300002F Received ISAKMP packet: peer = 192.68.192.81 30 05:52:51.575 07/15/02 Sev=Info/4 IKE/0x63000014 RECEIVING <<< ISAKMP OAK TRANS *(HASH, ATTR) from 192.68.192.81 31 05:52:51.575 07/15/02 Sev=Info/5 IKE/0x63000010 MODE_CFG_REPLY: Attribute = INTERNAL_IPV4_ADDRESS: , value = 10.25.250.2 ! IP address assigned to the client by the VPN ! concentrator for the IPSec tunnel. 32 05:52:51.575 07/15/02 Sev=Info/5 IKE/0x63000010 MODE_CFG_REPLY: Attribute = INTERNAL_IPV4_DNS(1): , value = 192.168.226.120 ! IP address of the primary DNS server assigned to the ! client by the concentrator. 33 05:52:51.575 07/15/02 Sev=Info/5 IKE/0x63000010 MODE_CFG_REPLY: Attribute = INTERNAL_IPV4_DNS(2): , value = 192.168.168.183 ! IP address of the secondary DNS server assigned to the ! client by the concentrator. 34 05:52:51.575 07/15/02 Sev=Info/5 IKE/0x63000010 MODE_CFG_REPLY: Attribute = INTERNAL_IPV4_NBNS(1) (a.k.a. WINS) : , value = 192.168.2.87 ! IP address of the primary WINS server assigned to ! the client by the concentrator. 35 05:52:51.575 07/15/02 Sev=Info/5 IKE/0x63000010 MODE_CFG_REPLY: Attribute = INTERNAL_IPV4_NBNS(2) (a.k.a. WINS): , value = 192.168.235.228 ! IP address of the secondary WINS server assigned to ! the client by the concentrator.
36 05:52:51.575 07/15/02 Sev=Info/5 IKE/0x6300000E MODE_CFG_REPLY: Attribute = MODECFG_UNITY_BANNER, value = Unauthorized access is prohibited. Connected to vpn-concentrator. ! Banner that Cisco VPN Unity client receives from the concentrator. ! The banner indicated the Configuration mode was done successfully.
continues
692
Example 21-1
37 05:52:51.575 07/15/02 Sev=Info/5 IKE/0x6300000D MODE_CFG_REPLY: Attribute = MODECFG_UNITY_SAVEPWD: , value = 0x00000000 38 05:52:51.575 07/15/02 Sev=Info/5 IKE/0x6300000E MODE_CFG_REPLY: Attribute = MODECFG_UNITY_DEFDOMAIN: , value = xyz.com ! Domain assigned to the concentrator by the VPN concentrator, xyz.com. 39 05:52:51.575 07/15/02 Sev=Info/5 IKE/0x6300000D MODE_CFG_REPLY: Attribute = MODECFG_UNITY_PFS: , value = 0x00000000 ! PFS=Perfect Forward Secrecy; not being used ! This parameter specifies whether to use Perfect Forward Secrecy ! and the size of the numbers to use in generating Phase 2 IPSec keys. ! Perfect Forward Secrecy is a cryptographic concept; ! each new key is unrelated to any previous key. ! In IPSec negotiations, Phase 2 keys are based on Phase 1 keys unless ! Perfect Forward Secrecy is specified. ! Perfect Forward Secrecy uses Diffie-Hellman techniques to generate the keys.2 40 05:52:51.575 07/15/02 Sev=Info/5 IKE/0x6300000E MODE_CFG_REPLY: Attribute = APPLICATION_VERSION, value = Cisco Systems, Inc./VPN 3000 Concentrator Version 3.5.2.Rel built by vmurphy on Feb 14 2002 12:10:21 41 05:52:51.575 07/15/02 CM/0x63100019 Mode Config data received Sev=Info/4
42 05:52:51.595 07/15/02 Sev=Info/5 IKE/0x63000055 Received a key request from Driver for IP address 192.68.192.81, GW IP = 192.68.192.81 43 05:52:51.595 07/15/02 Sev=Info/4 IKE/0x63000013 SENDING >>> ISAKMP OAK QM *(HASH, SA, NON, ID, ID) to 192.68.192.81 ! QM=Quick Mode 44 05:52:51.595 07/15/02 Sev=Info/5 IKE/0x63000055 Received a key request from Driver for IP address 10.10.10.255, GW IP = 192.68.192.81 45 05:52:51.595 07/15/02 Sev=Info/4 IKE/0x63000013 SENDING >>> ISAKMP OAK QM *(HASH, SA, NON, ID, ID) to 192.68.192.81 46 05:52:51.595 IPSEC/0x63700014 Deleted all keys 07/15/02 Sev=Info/4
693
Example 21-1
47 05:52:51.645 07/15/02 Sev=Info/5 IKE/0x6300002F Received ISAKMP packet: peer = 192.68.192.81 48 05:52:51.645 07/15/02 Sev=Info/4 IKE/0x63000014 RECEIVING <<< ISAKMP OAK INFO *(HASH, NOTIFY:STATUS_RESP_LIFETIME) from 192.68.192.81 49 05:52:51.645 07/15/02 Sev=Info/5 IKE/0x63000044 RESPONDER-LIFETIME notify has value of 86400 seconds ! Lifetime of IPSec SA keys. Set by core concentrator 50 05:52:51.645 07/15/02 Sev=Info/5 IKE/0x63000046 This SA has already been alive for 7 seconds, setting expiry to 86393 seconds from now 51 05:52:51.645 07/15/02 Sev=Info/5 IKE/0x6300002F Received ISAKMP packet: peer = 192.68.192.81 52 05:52:51.645 07/15/02 Sev=Info/4 IKE/0x63000014RECEIVING <<< ISAKMP OAK QM *(HASH, SA, NON, ID, ID, NOTIFY:STATUS_RESP_LIFETIME) from 192.68.192.81 53 05:52:51.645 07/15/02 Sev=Info/5 IKE/0x63000044 RESPONDER-LIFETIME notify has value of 28800 seconds 54 05:52:51.645 07/15/02 Sev=Info/4 IKE/0x63000013 SENDING >>> ISAKMP OAK QM *(HASH) to 192.68.192.81 55 05:52:51.645 07/15/02 Sev=Info/5 IKE/0x63000058 Loading IPsec SA (Message ID = 0xD6D39C1E OUTBOUND SPI = 0x2FC49467 INBOUND SPI = 0x50A8DB73) 56 05:52:51.645 07/15/02 Sev=Info/5 IKE/0x63000025 Loaded OUTBOUND ESP SPI: 0x2FC49467 57 05:52:51.645 07/15/02 Sev=Info/5 IKE/0x63000026 Loaded INBOUND ESP SPI: 0x50A8DB73
continues
694
Example 21-1
58 05:52:51.645 07/15/02 Sev=Info/4 CM/0x6310001A One secure connection established 59 05:52:51.695 07/15/02 DIALER/0x63300003 Connection established. Sev=Info/6
60 05:52:51.755 07/15/02 Sev=Info/5 IKE/0x6300002F Received ISAKMP packet: peer = 192.68.192.81 61 05:52:51.755 07/15/02 Sev=Info/4 IKE/0x63000014 RECEIVING <<< ISAKMP OAK QM *(HASH, SA, NON, ID, ID, NOTIFY:STATUS_RESP_LIFETIME) from 192.68.192.81 62 05:52:51.765 07/15/02 Sev=Info/5 IKE/0x63000044 RESPONDER-LIFETIME notify has value of 28800 seconds 63 05:52:51.765 07/15/02 Sev=Info/4 IKE/0x63000013 SENDING >>> ISAKMP OAK QM *(HASH) to 192.68.192.81 64 05:52:51.765 07/15/02 Sev=Info/5 IKE/0x63000058 Loading IPsec SA (Message ID = 0xD765C6C4 OUTBOUND SPI = 0x07742CDC INBOUND SPI = 0xCB7C70B2) ! Concentrator connecting to this client will have the same SPI numbers but ! its inbound and outbound SPIs will be reversed as seen in Table 21-3. 65 05:52:51.765 07/15/02 Sev=Info/5 IKE/0x63000025 Loaded OUTBOUND ESP SPI: 0x07742CDC 66 05:52:51.765 07/15/02 Sev=Info/5 IKE/0x63000026 Loaded INBOUND ESP SPI: 0xCB7C70B2 67 05:52:51.765 07/15/02 Sev=Info/4 CM/0x63100022 Additional Phase 2 SA established. ! The Phase 2 SA (IPSec SA) was successfully established. 68 05:52:51.765 07/15/02 Sev=Info/5 IKE/0x63000055 Received a key request from Driver for IP address 192.168.2.87, GW IP = 192.68.192.81 69 05:52:51.765 07/15/02 Sev=Info/4 IKE/0x63000013 SENDING >>> ISAKMP OAK QM *(HASH, SA, NON, ID, ID) to 192.68.192.81
695
Example 21-1
70 05:52:51.805 07/15/02 Sev=Info/5 IKE/0x6300002F Received ISAKMP packet: peer = 192.68.192.81 71 05:52:51.805 07/15/02 Sev=Info/4 IKE/0x63000014 RECEIVING <<< ISAKMP OAK QM *(HASH, SA, NON, ID, ID, NOTIFY:STATUS_RESP_LIFETIME) from 192.68.192.81 72 05:52:51.805 07/15/02 Sev=Info/5 IKE/0x63000044 RESPONDER-LIFETIME notify has value of 28800 seconds 73 05:52:51.805 07/15/02 Sev=Info/4 IKE/0x63000013 SENDING >>> ISAKMP OAK QM *(HASH) to 192.68.192.81 74 05:52:51.805 07/15/02 Sev=Info/5 IKE/0x63000058 Loading IPsec SA (Message ID = 0x8367341C OUTBOUND SPI = 0x044318D0 INBOUND SPI = 0x682F214E) 75 05:52:51.805 07/15/02 Sev=Info/5 IKE/0x63000025 Loaded OUTBOUND ESP SPI: 0x044318D0 76 05:52:51.805 07/15/02 Sev=Info/5 IKE/0x63000026 Loaded INBOUND ESP SPI: 0x682F214E 77 05:52:51.805 07/15/02 Sev=Info/4 CM/0x63100022 Additional Phase 2 SA established. 78 05:52:52.807 07/15/02 Sev=Info/4 IPSEC/0x63700010 Created a new key structure ! A new key structure was created. 79 05:52:52.807 07/15/02 Sev=Info/4 IPSEC/0x6370000F Added key with SPI=0x6794c42f into key list <Output Omitted> 90 05:52:53.187 07/15/02 Sev=Info/6 DIALER/0x63300008 MAPI32 Information - Outlook not default mail client ! This message does not affect operation of the VPN Client. ! The issue occurs when Microsoft Outlook is installed but not ! configured for email, although it is the default mail client.
continues
696
Example 21-1
! ! ! ! ! ! It is caused by a Registry Key that is set when the user installs Outlook. To eliminate this message, do one of the following: -Right-click the Outlook icon, go to Properties, and configure it to use Microsoft Exchange or Internet Mail as the default mail client -Use Internet Explorer to configure the system to have no default mail client -Configure Outlook as the default mail client (CSCdv67594)3
91 05:52:54.189 07/15/02 Sev=Info/4 IPSEC/0x63700019 Activate outbound key with SPI=0xdc2c7407 for inbound key with SPI=0xb2707ccb 92 05:53:21.803 07/15/02 Sev=Info/5 IKE/0x6300002F Received ISAKMP packet: peer = 192.68.192.81 93 05:53:21.803 07/15/02 Sev=Info/4 IKE/0x63000014 RECEIVING <<< ISAKMP OAK INFO *(HASH, DEL) from 192.68.192.81 94 05:53:21.803 07/15/02 Sev=Info/5 IKE/0x63000018 Deleting IPsec SA: (OUTBOUND SPI = 7742CDC INBOUND SPI = CB7C70B2) 95 05:53:22.734 07/15/02 Sev=Info/4 IPSEC/0x63700013 Delete internal key with SPI=0xb2707ccb 96 05:53:22.734 07/15/02 IPSEC/0x6370000C Key deleted by SPI 0xb2707ccb Sev=Info/4
97 05:53:22.734 07/15/02 Sev=Info/4 IPSEC/0x63700013 Delete internal key with SPI=0xdc2c7407 98 05:53:22.734 07/15/02 IPSEC/0x6370000C Key deleted by SPI 0xdc2c7407 Sev=Info/4
99 05:53:26.741 07/15/02 Sev=Info/4 IPSEC/0x63700019 Activate outbound key with SPI=0xd0184304 for inbound key with SPI=0x4e212f68 100 05:54:49.903 07/15/02 Sev=Info/6 DIALER/0x63300006 Disconnecting connection. ! Termination process has been initiated. 101 05:54:49.913 07/15/02 CM/0x6310000A Secure connections terminated Sev=Info/4
697
Example 21-1
102 05:54:49.913 07/15/02 Sev=Info/5 IKE/0x63000018 Deleting IPsec SA: (OUTBOUND SPI = 44318D0 INBOUND SPI = 682F214E) ! Deleting SA Recall the SA is IP address + IPSec protocol +S PI 103 05:54:49.913 07/15/02 Sev=Info/4 IKE/0x63000013 SENDING >>> ISAKMP OAK INFO *(HASH, DEL) to 192.68.192.81 104 05:54:49.913 07/15/02 Sev=Info/5 IKE/0x63000018 Deleting IPsec SA: (OUTBOUND SPI = 2FC49467 INBOUND SPI = 50A8DB73) 105 05:54:49.913 07/15/02 Sev=Info/4 IKE/0x63000013 SENDING >>> ISAKMP OAK INFO *(HASH, DEL) to 192.68.192.81 106 05:54:49.913 07/15/02 Sev=Info/5 IKE/0x63000017 Marking IKE SA for deletion (COOKIES = FA981A927C24915F AED77DA44D19D140) reason = DEL_REASON_RESET_SADB ! Reason for disconnect was a reset of the security association data base SADB. 107 05:54:49.913 07/15/02 Sev=Info/4 IKE/0x63000013 SENDING >>> ISAKMP OAK INFO *(HASH, DEL) to 192.68.192.81 108 05:54:49.913 07/15/02 Sev=Info/4 CM/0x63100013 Phase 1 SA deleted cause by DEL_REASON_RESET_SADB. Phase 1 SA currently in the system 109 05:54:49.973 07/15/02 CM/0x63100029 Initializing CVPNDrv Sev=Info/5
110 05:54:49.973 07/15/02 Sev=Info/6 CM/0x63100035 Tunnel to headend device vpn-concentrator.xyz.com disconnected: duration: 0 days 0:1:58 111 05:54:49.973 07/15/02 CM/0x63100029 Initializing CVPNDrv Sev=Info/5
112 05:54:49.983 07/15/02 Sev=Info/4 IPSEC/0x63700013 Delete internal key with SPI=0x4e212f68
continues
698
Example 21-1
113 05:54:49.983 07/15/02 Sev=Info/4 IPSEC/0x63700013 Delete internal key with SPI=0xd0184304 114 05:54:49.983 07/15/02 Sev=Info/4 IPSEC/0x63700013 Delete internal key with SPI=0x73dba850 115 05:54:49.983 07/15/02 Sev=Info/4 IPSEC/0x63700013 Delete internal key with SPI=0x6794c42f 116 05:54:49.983 IPSEC/0x63700014 Deleted all keys 07/15/02 Sev=Info/4
117 05:54:49.983 07/15/02 IPSEC/0x63700010 Created a new key structure
Sev=Info/4
118 05:54:49.983 07/15/02 Sev=Info/4 IPSEC/0x63700013 Delete internal key with SPI=0x00000000 119 05:54:49.983 IPSEC/0x63700014 Deleted all keys 120 05:54:49.983 IPSEC/0x63700014 Deleted all keys 121 05:54:49.983 IPSEC/0x63700014 Deleted all keys 07/15/02 Sev=Info/4
07/15/02
Sev=Info/4
07/15/02
Sev=Info/4
122 05:54:49.983 07/15/02 Sev=Info/5 IKE/0x6300002F Received ISAKMP packet: peer = 192.68.192.81 123 05:54:49.983 07/15/02 Sev=Warning/2 IKE/0xA3000062 Attempted incoming connection from 192.68.192.81. Inbound connections are not allowed. 124 05:54:49.983 07/15/02 Sev=Info/5 IKE/0x63000055 Received a key request from Driver for IP address 192.168.2.87, GW IP = 192.68.192.81 125 05:54:49.983 IKE/0xE3000065 07/15/02 Sev=Warning/3
699
Example 21-1
Could not find an IKE SA for 192.68.192.81. KEY_REQ aborted. ! In addition to the termination, this message may appear when the WAN ! IP address has changed due to problems such as flapping WAN connections or ! ISP issues (see Chapter 22 for more information). 126 05:54:50.413 DIALER/0x63300007 Disconnected. 07/15/02 Sev=Info/6
Log les showing that a Phase 1 SA cannot be established is an indication that the client cannot successfully communicate with the core concentrator. Clients that cannot establish the Phase 2 SA might be encountering an issue related to MTU size, and the clients need to consider reducing the size. Clients with connections that randomly fail after successfully passing data, and receive an error message similar to the one in Example 21-2, is an indication that connectivity between the client and the VPN concentrator is suspect.
Example 21-2
Log Entry for Terminating VPN Session

IKE lost contact with remote peer, deleting connection (keepalive type: DPD) ! Cause of termination was loss of Network Connectivity to ! VPN terminating device
Cisco 3000 Concentrator Event Log

The concentrator also has a log feature that is helpful in troubleshooting remote access VPN connections. Example 21-3 shows the concentrator log entries for the same client shown in Example 21-1. Example 21-3 shows the benet of being a troubleshooting engineer in the enterprise environment, where usually you have access to the concentrator and can check the log, which shows the same connection that is shown in Example 21-1 from the other end. For the purposes of the example, the beginning of the negotiation process is skipped and line 29299 starts from the user authentication phase, which allows you to identify the user by login name (smith) in the log. As mentioned in Example 21-1, the log shows the output from the connect-disconnect scenario, and it is provided here solely for the purposes of explanation.
Example 21-3
Concentrator Log for Unity

VPN SW Client Connection (client v3.5.2, concentrator v3.5) 29299 07/15/2002 05:52:11.970 SEV=4 IKE/52 RPT=4502 12.235.95.31 Group [vpn] User [smith] User (smith) authenticated. ! 12.235.95.31 is the actual IP address of the client. 29301 07/15/2002 05:52:12.500 SEV=4 AUTH/22 RPT=4691 User smith connected
continues
700
Example 21-3
Concentrator Log for Unity (Continued)

29302 07/15/2002 05:52:12.500 SEV=4 IKE/119 RPT=15983 12.235.95.31 Group [vpn] User [smith] PHASE 1 COMPLETED 29304 07/15/2002 05:52:12.500 SEV=5 IKE/25 RPT=39263 12.235.95.31 Group [vpn] User [smith] Received remote Proxy Host data in ID Payload: Address 10.25.250.2, Protocol 0, Port 0 ! 10.25.250.2 is the IP address assigned to the client by ! the concentrator for the VPN tunnel. 29307 07/15/2002 05:52:12.500 SEV=5 IKE/24 RPT=38566 12.235.95.31 Group [vpn] User [smith] Received local Proxy Host data in ID Payload: Address 192.168.192.81, Protocol 0, Port 0 29310 07/15/2002 05:52:12.500 SEV=5 IKE/66 RPT=20250 12.235.95.31 Group [vpn] User [smith] IKE Remote Peer configured for SA: ESP/IKE-3DES-MD5 29311 07/15/2002 05:52:12.510 SEV=5 IKE/75 RPT=19355 12.235.95.31 Group [vpn] User [smith] Overriding Initiators IPSec rekeying duration from 2147483 to 28800 seconds ! The lower value offered for re-keying between both concentrator and ! client is the agreed upon value for key lifetime. 29313 07/15/2002 05:52:12.530 SEV=5 IKE/25 RPT=39264 12.235.95.31 Group [vpn] User [smith] Received remote Proxy Host data in ID Payload: Address 10.25.250.2, Protocol 0, Port 0 29316 07/15/2002 05:52:12.530 SEV=5 IKE/34 RPT=47224 12.235.95.31 Group [vpn] User [smith] Received local IP Proxy Subnet data in ID Payload: Address 0.0.0.0, Mask 0.0.0.0, Protocol 0, Port 0 29319 07/15/2002 05:52:12.530 SEV=5 IKE/66 RPT=20251 12.235.95.31 Group [vpn] User [smith] IKE Remote Peer configured for SA: ESP/IKE-3DES-MD5 ! SA protocol ESP, encryption algorithm 3DES, and hash MD5. 29320 07/15/2002 05:52:12.530 SEV=5 IKE/75 RPT=19356 12.235.95.31 Group [vpn] User [smith] Overriding Initiators IPSec rekeying duration from 2147483 to 28800 seconds ! The group on the VPN concentrator is set to rekey the keys for ! the IPSec negotiations. 29322 07/15/2002 05:52:12.540 SEV=4 IKE/49 RPT=20311 12.235.95.31 Group [vpn] User [smith] Security negotiation complete for User (smith) Responder, Inbound SPI = 0x0db4b5a1, Outbound SPI = 0x7e6fc994 ! You can see the SPIs reversed from the client as shown in Example 21-1.
701
Example 21-3

29325 07/15/2002 05:52:12.540 SEV=4 IKE/120 RPT=20311 12.235.95.31 Group [vpn] User [smith] PHASE 2 COMPLETED (msgid=32e87ed3) 29326 07/15/2002 05:52:12.790 SEV=4 IKE/49 RPT=20312 12.235.95.31 Group [vpn] User [smith] Security negotiation complete for User (smith) Responder, Inbound SPI = 0x73558664, Outbound SPI = 0xa9a80dcf 29329 07/15/2002 05:52:12.790 SEV=4 IKE/120 RPT=20312 12.235.95.31 Group [vpn] User [smith] PHASE 2 COMPLETED (msgid=6fdb7e4d) 29330 07/15/2002 05:52:12.810 SEV=5 IKE/25 RPT=39265 12.235.95.31 Group [vpn] User [smith] Received remote Proxy Host data in ID Payload: Address 10.25.250.2, Protocol 0, Port 0 29333 07/15/2002 05:52:12.810 SEV=5 IKE/34 RPT=47225 12.235.95.31 Group [vpn] User [smith] Received local IP Proxy Subnet data in ID Payload: Address 0.0.0.0, Mask 0.0.0.0, Protocol 0, Port 0 29336 07/15/2002 05:52:12.810 SEV=5 IKE/66 RPT=20252 12.235.95.31 Group [vpn] User [smith] IKE Remote Peer configured for SA: ESP/IKE-3DES-MD5 29337 07/15/2002 05:52:12.810 SEV=5 IKE/75 RPT=19357 12.235.95.31 Group [vpn] User [smith] Overriding Initiators IPSec rekeying duration from 2147483 to 28800 seconds 29339 07/15/2002 05:52:12.830 SEV=4 IKE/49 RPT=20313 12.235.95.31 Group [vpn] User [smith] Security negotiation complete for User (smith) Responder, Inbound SPI = 0x398539b4, Outbound SPI = 0x7cc8d0c0 29342 07/15/2002 05:52:12.840 SEV=4 IKE/120 RPT=20313 12.235.95.31 Group [vpn] User [smith] PHASE 2 COMPLETED (msgid=ba313b15) ! Disconnect process follows. 29349 07/15/2002 05:52:22.280 SEV=5 IKE/50 RPT=3452 12.235.95.31 Group [vpn] User [smith] Connection terminated for peer smith (Peer Terminate) Remote Proxy 10.25.250.2, Local Proxy 0.0.0.0 29352 07/15/2002 05:52:22.280 SEV=5 IKE/170 RPT=34237 12.235.95.31 Group [vpn] User [smith] IKE Received delete for rekeyed centry IKE peer: 10.25.250.2, centry addr: 0727a5f0, msgid: 0x6fdb7e4d
continues
702
Example 21-3

29355 07/15/2002 05:52:22.280 SEV=5 IKE/50 RPT=3453 12.235.95.31 Group [vpn] User [smith] Connection terminated for peer smith (Peer Terminate) Remote Proxy 10.25.250.2, Local Proxy 192.168.192.81 29358 07/15/2002 05:52:22.290 SEV=4 AUTH/28 RPT=4322 12.235.95.31 User [smith] disconnected: Duration: 0:00:09 Bytes xmt: 456 Bytes rcv: 680 Reason: User Requested
The concentrator event classes and corresponding descriptions are found in Table 21-4.
Table 21-4 VPN Concentrator Event Classes 2 Class Name AUTH AUTHDBG AUTHDECODE AUTOUPDATE CAPI CERT CONFIG DHCP DHCPDBG DHCPDECODE DM DNS DNSDBG DNSDECODE EVENT EVENTDBG EVENTMIB EXPANSIONCARD FILTER FILTERDBG FSM Class Description (Event Source) Authentication Authentication debugging Authentication protocol decoding Autoupdate subsystem Cryptography subsystem Digital certicates subsystem Conguration subsystem Dynamic Host Conguration Protocol (DHCP) subsystem DHCP debugging DHCP decoding Data movement subsystem DNS subsystem DNS debugging DNS decoding Event subsystem Event subsystem debugging Event Management Information Base (MIB) changes Expansion card (module) subsystem Filter subsystem Filter debugging Finite state machine subsystem (for debugging)
703
Table 21-4
VPN Concentrator Event Classes 2 (Continued) Class Name FTPD GENERAL GRE GREDBG GREDECODE HARDWAREMON HTTP IKE IKEDBG IKEDECODE IP IPDBG IPDECODE IPSEC IPSECDBG IPSECDECODE L2TP L2TPDBG L2TPDECODE LBSSF MIB2TRAP OSPF PPP PPPDBG PPPDECODE PPTP PPTPDBG PPTPDECODE PSH PSOS Class Description (Event Source) FTP daemon subsystem Network Time Protocol (NTP) subsystem and other general events Generic routing encapsulation (GRE) subsystem GRE debugging GRE decoding Hardware monitoring (fans, temperature, voltages, and so on) HTTP subsystem ISAKMP/Oakley (IKE) subsystem ISAKMP/Oakley (IKE) debugging ISAKMP/Oakley (IKE) decoding IP router subsystem IP router debugging IP packet decoding IPSec subsystem IPSec debugging IPSec decoding Layer 2 Tunnel Protocol (L2TP) subsystem L2TP debugging L2TP decoding Load balancing subsystem MIB-II trap subsystem: Simple Network Management Protocol (SNMP) MIB-II traps Open Shortest Path First (OSPF) subsystem PPP subsystem PPP debugging PPP decoding PPTP subsystem PPTP debugging PPTP decoding Operating system command shell Embedded real-time operating system continues
704
Table 21-4
VPN Concentrator Event Classes 2 (Continued) Class Name QUEUE REBOOT RM SMTP SNMP SSH SSL SYSTEM TCP TELNET TELNETDBG TELNETDECODE TIME VRRP XML Class Description (Event Source) System queue System rebooting Resource manager subsystem Simple Mail Transfer Protocol (SMTP) event handling SNMP trap subsystem Secure Shell (SSH) subsystem Secure Socket Layer (SSL) subsystem Buffer, heap, and other system utilities TCP subsystem Telnet subsystem Telnet debugging Telnet decoding System time (clock) Virtual Router Redundancy Protocol (VRRP) subsystem XML
The impact of these events, or their severity levels, is measured and shown in the event logs per Table 21-5.
Table 21-5 VPN Concentrator Event Severity Levels 2 Level 1 2 3 4 5 6 7 8 9 10 11 Category Fault Warning Warning Information Information Information Debug Debug Debug Packet Decode Packet Decode Description A crash or non-recoverable error A pending crash or severe problem that requires user intervention A potentially serious problem that might require user action An information-only event with few details An information-only event with moderate detail An information-only event with greatest detail Least amount of debugging detail Moderate amount of debugging detail Greatest amount of debugging detail High-level packet header decoding Low-level packet header decoding
705
Table 21-5
VPN Concentrator Event Severity Levels 2 (Continued) Level 12 13 Category Packet Decode Packet Decode Description Hex dump of header Hex dump of packet
Cisco indicates that within a severity level category, higher-numbered events provide more details than lower-numbered events. You can change the severity level of the events displayed in the concentrator event log and console, as well as those displayed in the syslog, e-mail and traps, with the concentrator menu Conguration, System, Events, General. An example of a specic event and severity level is shown in Example 21-4, in which the concentrator deletes its connection with User smith because of no response using the Dead Peer Detection (DPD) feature. Actually, the concentrator reports two separate events, rst no response, then disconnection. For the no response event, the severity level is 4 the event class is IKE, and the event number is 123. The disconnection is also classied as severity level 4, and the event class is authentication. RPT stands for repeat and indicates the number of times that the event has occurred since the concentrator was reloaded.2
Example 21-4
Event Log for Deleted Connection Because of No Response from the Client
8157 07/11/2002 12:54:19.140 SEV=4 IKE/123 RPT=6792 128.216.126.77 Group [xyz-vpn] User [smith] IKE lost contact with remote peer, deleting connection (keepalive type: DPD) 8162 07/11/2002 12:54:19.150 SEV=4 AUTH/28 RPT=16579 128.216.126.77 User [smith] disconnected: Duration: 0:51:22 Bytes xmt: 276824 Bytes rcv: 311120 Reason: User Requested
Incompatible GINAs and Workarounds

GINA is the system that Microsoft devised to control access to the W2K and NT host environments. GINAs are the modules that force clients to log in to their host. Two types of GINAs are in use: authenticator and lter.4 There can be multiple lters, but only one authenticator. In this case, the lters chain to each other but the last GINA called in this chain must be the authenticator. The authenticator manages the user login process, and the lters offer additional benets. The default GINA for W2K is MSGINA.DLL. Unfortunately, some GINAs cannot coexist and participate in a chain of GINAs. If you install the Cisco VPN Unity client v3.5 or earlier on a host that already has a third party GINA, which is incompatible with the GINA for the Cisco VPN Unity client (CSGINA.DLL), the W2K host might experience a startup failure.5
706
A typical failure message that is as a result of installing incompatible GINAs during the boot process is as follows:
SAS window: winlogon.exe Application Error The instruction at 0x00000000 referenced memory at 0x00000000. The memory could not be read.
You might need to restart your host in Safe mode, and implement the following sequence to restore your host to the state it was in before the Cisco VPN Unity client installed its GINA:
1 Copy CSGINA.DLL in the SYSTEM32 directory to TEMPORARY_CSGINA.DLL. 2 In the same SYSTEM32 directory, copy MSGINA.DLL to CSGINA.DLL. 3 Reboot the host and log into the host as Administrator. 4 Type run32dll temporary_csgina.dll,GinaUnregister, omitting the quotes at the
command line, or use Start, Run.

5 Reboot the host.
This procedure can also result in extended delays for clients who log into Windows NT networks after authenticating their Cisco VPN Unity client. This delay, of up to 30 seconds or more, can occur because the client is preempted by other tasks running on the host. If you want to force the host to disregard any third-party GINAs and to restore the backup method for logging into Windows NT networks, after authenticating the Cisco VPN Unity client, Cisco suggests the following:
1 Copy MSGINA.DLL to CSGINA.DLL in the SYSTEM32 directory. 2 Reboot the host and log in as Administrator. 3 Delete the HKEY_LOCAL_MACHINE\Software\Microsoft\Windows
NT\CurrentVersion\WinLogon subkey in the Registry editor.

4 Set the HKEY_LOCAL_MACHINE\Software\Cisco Systems\VPN Client subkey
to 0.
5 Reboot the host.
Cisco 3002 HW Client Troubleshooting

The Cisco VPN 3002 HW client can be congured in either Client mode or Network Extension mode. In Client mode, the 3002 performs as the Cisco VPN Unity SW client, obtaining an IP address from the device terminating the VPN tunnel. PAT/NAT is implemented on the VPN 3002 to direct network trafc to/from hosts connected to its private interface. In Network Extension mode, the VPN 3002 HW client is congured with an IP address subnet that is routable throughout the organization, which provides the capability to remotely access hosts connected to the private interface from the enterprise network.
707
In this section, you review methods and tools for troubleshooting the VPN 3002 HW client, including the following:
Initial troubleshooting checklist Using the VPN 3002 HW client event log
Initial Troubleshooting Checklist

As with the Cisco VPN Unity client, this section is written under the assumption that the conguration of the 3002 HW client is correct; however, the rst steps are to verify the conguration, as suggested in Table 21-6. Issues that clients might encounter are related to end-to-end connectivity, MTU, and address assignment. The end-to-end connectivity and MTU issues are similar to those encountered with the SW client. The address assignment issue is unique to the 3002. At the time of writing this book, Cisco was working to address the MTU and subnet mask assignment issues for the 3002. Other features that most probably will be available in the near future are support for viewing multicast streams and two-way IP telephony when the 3002 HW client is in Client mode.
Table 21-6 Issue 1. User does not receive login prompt if using XAUTH for unit authentication. Initial Troubleshooting Checklist for the VPN 3002 HW Client Possible Source a. VPN 3002 HW client might need to be reset. Corrective Action Administration, Ping, and attempt to ping an Internet site, such as www.cisco.com. If successful, save the VPN 3002 concentrator conguration and reload the VPN 3002. b. VPN 3002 HW client does not have Internet connectivity because it is incorrectly congured. If VPN 3002 HW client cannot resolve host name, verify DNS server addresses. Next, verify the public interface connectivity. If using PPPoE, verify PPPoE username and password. Check log to verify PPPoE authentication, Monitoring, Filterable Event Log, Get Log. Verify that the VPN 3002 HW client is properly congured or learning correct route(s). If not using PPPoE, verify that the public interface is either learning IP address information through DHCP, or is congured with the correct static IP address information. If applicable, verify Internet connectivity from a router in front of the VPN 3002 HW client. Conguration, Interfaces, Verify the private interface is congured with the correct IP address and subnet mask. continues
2. User is authenticated but cannot pass any data.
a. The correct client mode was not selectedeither Network Extension or Client mode.
708
Table 21-6 Issue
Initial Troubleshooting Checklist for the VPN 3002 HW Client (Continued) Possible Source b. If Network Extension mode is used, another client might have an overlapping subnet. Corrective Action On the core VPN3000 concentrator, the administrator needs to verify the subnet mask for each client with subnets adjacent to the client experiencing the problem: Administration, Administer Sessions. Next, check masks for subnets that might have been mistakenly set. After the device causing the problem is identied, correct the setting and conrm that the 3002 HW client with the original issue can now send/receive data. Reduce the MTU on the network interface for each host exhibiting the issue (see the section, MTUA Critical Factor for Troubleshooting Internet IPSec Connectivity).
3. User is authenticated but cannot send/ receive data for applications with large packet sizes such as HTTP, email or Network File System (NFS).
a. MTU of host is too large (at the time of writing, the VPN 3002 HW client does not have a mechanism to set/ change the MTU on its interfaces).
Using the VPN 30002 HW Client Event Log

Similar to the Cisco VPN Unity client, the Event Console Messages and Event Log for the VPN 3002 HW client can prove useful when troubleshooting remote access connectivity issues. The settings that control the events reported in the VPN 3002 HW Client Event Log are found under Conguration, System, Events. The VPN 3002 HW Client Help menu provides an excellent overview and detailed information of the features of the Event Logging system. A signicant number of event classes exist for the VPN 3002 HW client (see Table 21-7), some of which are designed exclusively for Cisco to provide support. However, some can provide useful information when troubleshooting a VPN 3002 HW client.
Table 21-7 VPN 3002 HW Client Event Classes for General Users 6 Class Name CERT DHCP DNS FTPD Class Description (Event Source) Digital certicates subsystem DHCP subsystem DNS subsystem FTP daemon subsystem
709
Table 21-7
VPN 3002 HW Client Event Classes for General Users 6 (Continued) Class Name GENERAL HARDWAREMON HTTP IKE IP IPSEC PPP PPPoE REBOOT SNMP SSH SSL TCP TELNET TIME Class Description (Event Source) NTP subsystem and other general events Hardware monitoring (fans, temperature, voltages, and so on) HTTP subsystem ISAKMP/Oakley (IKE) subsystem IP router subsystem IPSec subsystem PPP subsystem PPPoE subsystem System rebooting SNMP trap subsystem SSH subsystem SSL subsystem TCP subsystem Telnet subsystem System time (clock)
By default, the VPN 3002 displays all events of severity level 1 through 3 on the console. It writes all events of severity level 1 through 5 to the event log. Severity 1 is the most severe and indicates a system crash. Levels 1 to 13 are available, although setting logging for some event classes up to level 13 can cause the concentrator to become inaccessible as a result of processor overuse. Example 21-5 shows the entries for the Event Log from a 3060 concentrator that successfully authenticates a 3002 VPN HW client and negotiates and establishes a VPN tunnel.
Example 21-5
Event Log from the VPN 3000 Core Concentrator Authenticating a VPN 3002 HW Client v3.5 in Network Extension Mode (Using Default Event Reporting Settings)
52714 03/04/2002 02:38:10.010 SEV=4 IKE/52 RPT=113 12.234.185.130 Group [TEST] User [smith] User (smithsmith) authenticated. !Client IP address= 12.234.185.130 Group name= TEST Username = smith 52715 03/04/2002 02:38:10.070 SEV=4 AUTH/22 RPT=116 User smith connected
continues
710
Example 21-5
Event Log from the VPN 3000 Core Concentrator Authenticating a VPN 3002 HW Client v3.5 in Network Extension Mode (Using Default Event Reporting Settings) (Continued)
52716 03/04/2002 02:38:10.070 SEV=4 IKE/119 RPT=185 12.234.185.130 Group [TEST] User [smith] PHASE 1 COMPLETED 52718 03/04/2002 02:38:10.070 SEV=5 IKE/25 RPT=390 12.234.185.130 Group [TEST] User [smith] Received remote Proxy Host data in ID Payload: Address 12.234.185.130, Protocol 0, Port 0 52721 03/04/2002 02:38:10.070 SEV=5 IKE/24 RPT=386 12.234.185.130 Group [TEST] User [smith] Received local Proxy Host data in ID Payload: Address 1928.168.192.81, Protocol 0, Port 0 ! 192.168.192.81 is IP address of the concentrator 52724 03/04/2002 02:38:10.070 SEV=5 IKE/66 RPT=835 12.234.185.130 Group [TEST] User [smith] IKE Remote Peer configured for SA: ESP-3DES-MD5 ! SA protocol ESP, encryption algorithm 3DES, and hash MD5. 52726 03/04/2002 02:38:10.070 SEV=5 IKE/75 RPT=835 12.234.185.130 Group [TEST] User [smith] Overriding Initiators IPSec rekeying duration from 2147483647 to 28800 seconds ! Lifetime of IPSec SA keys. Set by this concentrator. 52728 03/04/2002 02:38:10.100 SEV=4 IKE/49 RPT=835 12.234.185.130 Group [TEST] User [smith] Security negotiation complete for User (smith) Responder, Inbound SPI = 0x72b26536, Outbound SPI = 0x76018499 52731 03/04/2002 02:38:10.100 SEV=4 IKE/120 RPT=835 12.234.185.130 Group [TEST] User [smith] PHASE 2 COMPLETED (msgid=6573ee0a) 52732 03/04/2002 02:38:10.100 SEV=4 AUTOUPDATE/19 RPT=114 Sending IKE Notify: AutoUpdating clients in group [TEST] Client delay: 0, instID: 0000046F 52734 03/04/2002 02:38:14.110 SEV=5 IKE/35 RPT=446 12.234.185.130 Group [TEST] User [smith] Received remote IP Proxy Subnet data in ID Payload: Address 10.25.0.128, Mask 255.255.255.240, Protocol 0, Port 0 ! IP address subnet configured on the client is 10.25.0.128/28. ! The subnet could also be assigned via a Radius authentication server. 52737 03/04/2002 02:38:14.110 SEV=5 IKE/34 RPT=450 12.234.185.130 Group [TEST] User [smith] Received local IP Proxy Subnet data in ID Payload: Address 0.0.0.0, Mask 0.0.0.0, Protocol 0, Port 0 52740 03/04/2002 02:38:14.110 SEV=5 IKE/66 RPT=836 12.234.185.130 Group [TEST] User [smith] IKE Remote Peer configured for SA: ESP-3DES-MD5
711
Example 21-5
Event Log from the VPN 3000 Core Concentrator Authenticating a VPN 3002 HW Client v3.5 in Network Extension Mode (Using Default Event Reporting Settings) (Continued)
52742 03/04/2002 02:38:14.110 SEV=5 IKE/75 RPT=836 12.234.185.130 Group [TEST] User [smith] Overriding Initiators IPSec rekeying duration from 2147483647 to 28800 seconds 52744 03/04/2002 02:38:14.150 SEV=4 IKE/49 RPT=836 12.234.185.130 Group [TEST] User [smith] Security negotiation complete for User (smith) Responder, Inbound SPI = 0x6f1c24f7, Outbound SPI = 0x25f707f3 52747 03/04/2002 02:38:14.150 SEV=4 IKE/120 RPT=836 12.234.185.130 Group [TEST] User [smith] PHASE 2 COMPLETED (msgid=6b8ddbe7) ! At this point the IPSec SA was successfully negotiated and ! data can be sent to/from hosts connected behind the VPN 3002 HW Client. ! The disconnect process begins. 54625 03/04/2002 04:10:59.250 SEV=4 IKE/123 RPT=28 12.234.185.130 Group [TEST] User [smith] IKE lost contact with remote peer, deleting connection (keepalive type: DPD) 54629 03/04/2002 04:10:59.250 SEV=4 AUTH/28 RPT=47 12.234.185.130 User [smith] disconnected: Duration: 1:32:49 Bytes xmt: 156848 Bytes rcv: 242112 Reason: User Requested
Example 21-6 shows the event log from a 3002 client during its authentication, negotiation, and establishment of a VPN tunnel.
Example 21-6
Event Log from a VPN 3002 HW Client for Establishing a VPN Tunnel (Using Default Event Reporting Settings)
1235 03/04/2002 02:35:52.520 SEV=4 IKE/41 RPT=156 192.168.192.81 IKE Initiator: New Phase 1, Intf 2, IKE Peer 192.168.192.81 local Proxy Address 12.234.185.130, remote Proxy Address 192.168.192.81, SA (ESP-3DES-MD5) 1238 03/04/2002 02:36:00.640 SEV=5 DHCP/66 RPT=32 DHCPREQUEST received by server. MAC Addr: 00.00.86.46.2E.8E. Requested IP: 10. 25.0.130. ! 3002 VPN HW Client configured as DHCP server. Receives DHCP request. 1240 03/04/2002 02:36:00.640 SEV=5 DHCP/72 RPT=31 DHCPACK sent by server. MAC Addr: 00.00.86.46.2E.8E ! 3002 VPN HW Client Responds to DHCP request. 1241 03/04/2002 02:36:23.590 SEV=3 AUTH/24 RPT=3 Tunnel to headend device 192.168.192.81 connected
continues
712
Example 21-6
Event Log from a VPN 3002 HW Client for Establishing a VPN Tunnel (Using Default Event Reporting Settings) (Continued)
1242 03/04/2002 02:36:23.590 SEV=4 IKE/119 RPT=4 192.168.192.81 Group [192.168.192.81192.168.192.81] PHASE 1 COMPLETED 1243 03/04/2002 02:36:23.620 SEV=5 IKE/73 RPT=14 192.168.192.81 Group [192.168.192.81] Responder forcing change of IKE rekeying duration from 2147483647 to 86400 seconds ! Core terminating concentrator forces IKE rekey duration change. 1246 03/04/2002 02:36:23.620 SEV=5 IKE/73 RPT=15 192.168.192.81 Group [192.168.192.81] Responder forcing change of IPSec rekeying duration from 2147483647 to 28800 seconds 1249 03/04/2002 02:36:23.630 SEV=4 IKE/49 RPT=11 192.168.192.81 Group [192.168.192.81] Security negotiation complete for peer (192.168.192.81) Initiator, Inbound SPI = 0x76018499, Outbound SPI = 0x72b26536 1252 03/04/2002 02:36:23.640 SEV=4 IKE/120 RPT=11 192.168.192.81 Group [192.168.192.81] PHASE 2 COMPLETED (msgid=6573ee0a) 1253 03/04/2002 02:36:23.660 SEV=4 AUTOUPDATE/5 RPT=3 Current version 3.5.Rel is up to date. ! Core terminating concentrator checked SW version running on this ! 3002 HW client and verified it matches its requirement. ! Otherwise it could have been configured to push new SW image to the client. 1254 03/04/2002 02:36:27.640 SEV=4 IKE/41 RPT=157 IKE Initiator: New Phase 2, Intf 2, IKE Peer 1-192.168.192.81 local Proxy Address 10.25.0.128, remote Proxy Address 0.0.0.0, SA (ESP-3DES-MD5) 1256 03/04/2002 02:36:27.660 SEV=5 IKE/73 RPT=16 192.168.192.81 Group [192.168.192.81] Responder forcing change of IPSec rekeying duration from 2147483647 to 28800 seconds 1259 03/04/2002 02:36:27.670 SEV=4 IKE/49 RPT=12 192.168.192.81 Group [192.168.192.81] Security negotiation complete for peer (192.168.192.81) Initiator, Inbound SPI = 0x25f707f3, Outbound SPI = 0x6f1c24f7 1262 03/04/2002 02:36:27.680 SEV=4 IKE/120 RPT=12 192.168.192.81 Group [192.168.192.81] PHASE 2 COMPLETED (msgid=6b8ddbe7) ! At this point the IPSec SA was successfully negotiated, and data !can be sent to/from hosts connected behind the VPN 3002 HW Client. ! The disconnect process begins. 1282 03/04/2002 04:03:55.070 SEV=3 IP/31 RPT=1 Deleting Default Gateway 12.234.184.1 learned via DHCP on interface 2. 1283 03/04/2002 04:03:55.090 SEV=3 AUTH/25 RPT=3 192.168.192.81 Tunnel to headend device 192.168.192.81 disconnected: duration: 1:27:31
713
Cisco Easy VPN Client

In this section, you review information specic to the Cisco Easy VPN client. Similar to the VPN 3002 HW client, an Easy VPN client can be congured to operate in Client or Network Extension mode. However, conguring and troubleshooting an Easy VPN client presents its own unique challenges that you review in this section. In particular, you learn about the following:
Restrictions and limitations Troubleshooting the Cisco Easy VPN client
Restrictions and Limitations of the Cisco Easy VPN Client

Features are constantly being implemented in the Cisco Easy VPN client. At the time this book was written, the Easy VPN client did not yet support NAT transparency (UDP/TCP encapsulation). Additional restrictions and limitations are outlined in Table 21-8. Some are similar to the Cisco VPN Unity client and some are specic to the Cisco Easy VPN client. For the most recent list of restrictions and limitations, consult www.cisco.com.
Table 21-8 Restriction Host Cisco Easy VPN Client does not support perfect forward secrecy (PFS). Cisco Easy VPN client uses SA that does not exist in the default conguration of the VPN 3000 concentrator series running v3.5. Disable PFS option. On core concentrator, disable PFS option through Conguration, Policy Management, Trafc Management, Security Associations. Copy the ESP/IKE-3DES-MD5 SA and change the IKE proposal to CiscoVPNClient-3DESMD5 in the Conguration, Policy Management, Trafc Management, Security Associations menu. Cisco Easy VPN Client Selected Restrictions and Limitations for an 806 Router Running IOS v12.2(4)YA Requirement Corrective Action
Cisco Easy VPN uses a modied form of ESP/IKE3DES-MD5 on the VPN 3000 concentrator that is modied to use the IKE proposal CiscoVPNClient3DES-MD5. Do not congure NAT / PAT on any interface when using the Cisco Easy VPN client. Cannot use digital certicates.
Manual NAT/PAT conguration is not permitted.
Remove any manual NAT/PAT conguration on the router.
Digital Certicates are not supported in the release 12.2(4)YA.
Do not use digital certicates for authentication.
continues
714
Table 21-8 Restriction Host
Cisco Easy VPN Client Selected Restrictions and Limitations for an 806 Router Running IOS v12.2(4)YA (Continued) Requirement Corrective Action
Supports only Group 2 ISAKMP policy (1024 bit Dife-Hellman (DH) IKE negotiation). Cisco Easy VPN client does not support the transform sets that provide encryption without authentication.
Is not compatible with ISAKMP Group 1 or Group 1 policies.
Congure the core concentrator IKE proposal to use only Group 2 policies (the default for most precongured IKE proposals). Select Conguration, System, Tunneling Protocols, IPSEC, IKE Proposals. Conrm that selected transform set supports both encryption and authentication. Do not use precongured transform sets that do not provide authentication (ESP-DES and ESP3DES), or transform sets that do not provide encryption (ESP-NULL, ESP-SHA-HMAC, ESP-NULL, and ESP-MD5-HMAC). The workaround is to host the session from a user on the corporate intranet and require VPN clients to connect to it, or select a data collaboration application that supports the Easy VPN client.
Intended transform set for Cisco Easy VPN clients must include both encryption and authentication.
Cannot host real-time collaboration application sessions.
The Cisco Easy VPN client does not permit hosting of real-time collaboration sessions for some applications such as MS NetMeeting.
Troubleshooting the Cisco Easy VPN Client

Because Easy VPN is a Cisco IOS feature, one of the most effective methods to troubleshoot the Cisco Easy VPN client is through the use of the show and debug commands. The commands in the following list are specic to the Cisco Easy VPN client to troubleshoot the establishment of the VPN IPSec tunnels, and as data transmission and reception. You can perform the following commands from the console if using a telnet (SSH, if it is congured) session into the router:
The show crypto ipsec client ezvpn command displays the status of the Easy VPN client, as shown in Example 21-8 and Example 21-9. The debug crypto ezvpn command enables debugging of the Cisco Easy VPN client. The clear crypto ipsec client ezvpn command resets the VPN connection, as shown in Example 21-10. However, if you have enabled debugging, you might prefer to use the clear crypto sa and clear crypto isakmp commands. The debug crypto ipsec and debug crypto isakmp commands enable debugging of the IPSec and IKE key events. The results of the debug crypto isakmp are shown in Example 21-11. The show crypto engine connections active command displays the active IPSec VPN connections.
715
A suggested troubleshooting checklist for the Easy VPN client is presented in Table 21-9.
Table 21-9 Initial Troubleshooting Checklist for the Cisco Easy VPN Client Issue 1. Cannot establish a VPN IPSec tunnel between the Cisco Easy VPN client and the core VPN 3000 concentrator. Possible Source a. Cisco Easy VPN client router does not have Internet connectivity. Corrective Action Run show ip interface brief to verify that the router has IP addresses on both the inside and outside (public) interfaces, as shown in Example 21-7. If applicable, verify the PPPoE conguration (see the section, ADSL). Check the DHCP client conguration for outside interface (if appropriate). Conrm that you can ping Internet hosts such as www.cisco.com. Run show crypto ipsec client ezvpn to verify if the Cisco Easy VPN client is active, as in Example 21-8. If inactive, run crypto ipsec client ezvpn <name> to verify output, as shown in Example 21-9. Run debug crypto ipsec client ezvpn and then clear the active IPSec tunnel using the command clear crypto ipsec client ezvpn, as shown in Example 21-10. Run a second debug, debug crypto isakmp, and then start a tunnel, as shown in Example 21-11. Identify the source of the error from the output and correct accordingly. c. Core VPN 3000 concentrator authentication parameter is not set to NONE. Verify that authentication is set to none under the Conguration, User Management, Base Group, IPSec menu, and in Conguration, User Management, Groups, specic group, IPSec. Verify that VPN IPSec tunnel is established using show crypto ipsec client ezvpn.
b. Cisco Easy VPN client is not active.
2. Data is not transmitted/ received by the hosts connected to the inside (private) interface of the router running the Cisco Easy VPN client.
a. IPSec VPN tunnel has been terminated.
continues
716
Table 21-9
Initial Troubleshooting Checklist for the Cisco Easy VPN Client (Continued) Issue Possible Source b. NAT and the access-list conguration on the Cisco Easy VPN client router are invalid. NAT might have been manually congured on the router prior to establishment of the VPN IPSec tunnel. c. The DHCP pool is not congured correctly. Corrective Action Verify that NAT is not congured under the interfaces by using show running-cong, and by identifying if ip nat inside or ip nat outside is congured.
Verify the DHCP pool conguration on the router or server for hosts on the inside interface.
Example 21-7
Output of show ip interface brief Command

Router-EzVPN#show ip interface brief Interface IP-Address OK? Ethernet0 10.1.1.1 YES Ethernet1 66.127.241.85 YES ! Ethernet1 is the Public interface. ! The address 66.127.241.85 has been Method NVRAM NVRAM Status up up Protocol up up
assigned by the ISP.
Example 21-8
Output of show crypto ipsec client ezvpn Command for an Inactive Client
Inactive EzVPN client Router-EzVPN #show crypto ipsec client ezvpn Current State: XAUTH_REQ ! Client requests XAUTH response in current state Last Event: XAUTH_REQUEST Router-EzVPN#
Example 21-9
Output of show crypto ipsec client ezvpn Command for an Active Easy VPN Client Congured for Client Mode
Router-EzVPN#show crypto ipsec client ezvpn Current State: IPSEC_ACTIVE Last Event: SOCKET_UP Address: 10.25.250.1 ! The IP address obtained from the address pool on the terminating concentrator Mask: 255.255.255.255 ! The subnet mask obtained from the pool, defined in the server configuration. DNS Primary: 192.168.226.120 DNS Secondary: 192.168.168.183 ! The primary and secondary DNS servers defined for the group on the ! concentrator terminating the VPN tunnel NBMS/WINS Primary: 192.168.2.87 NBMS/WINS Secondary: 192.168.235.228 ! The primary and secondary WINS servers defined for the group on the ! concentrator terminating the VPN tunnel Default Domain: cisco.com
717
Example 21-10 Output of clear crypto ipsec client ezvpn Command

Router-EzVPN#clear crypto ipsec client ezvpn Router-EzVPN# 00:09:25: EZVPN: Current State: IPSEC_ACTIVE 00:09:25: EZVPN: Event: RESET 00:09:25: ezvpn_reconnect_request 00:09:25: ezvpn_close 00:09:25: ezvpn_connect_request 00:09:25: EZVPN: New State: READY 00:09:26: EZVPN: Current State: READY 00:09:26: EZVPN: Event: XAUTH_REQUEST 00:09:26: ezvpn_xauth_request 00:09:26: ezvpn_parse_xauth_msg 00:09:26: EZVPN: Attributes sent in xauth request message: 00:09:26: XAUTH_TYPE_V2: 0 00:09:26: XAUTH_USER_NAME_V2: 00:09:26: XAUTH_USER_PASSWORD_V2: 00:09:26: XAUTH_MESSAGE_V2 <Enter Username and Password.> 00:09:26: EZVPN: New State: XAUTH_REQ 00:09:27: EZVPN: Pending XAuth Request, Please enter the following command: 00:09:27: EZVPN: crypto ipsec client ezvpn xauth
Example 21-11 Output from a 8xx Router Running 12.2(4)YA, Congured as an Easy VPN Client with debug
crypto isakmp When Attempting to Establish an IPSec VPN Tunnel

Router-EzVPN #debug crypto isakmp Router-EzVPN#crypto ipsec client ezvpn xauth Enter Username and Password.: login_name Password: password. ! The user provides the login name and password Router-EzVPN# 00:12:48: xauth-type: 0 00:12:48: username: login_name 00:12:48: password: <omitted> 00:12:48: message <Enter Username and Password.> 00:12:48: ISAKMP (0:7): responding to peer config from 192.168.192.81. ID = -252864948 00:12:48: ISAKMP (0:7): sending packet to 192.168.192.81 (I) CONF_XAUTH 00:12:48: ISAKMP (0:7): deleting node -252864948 error FALSE reason done with xauth request/reply exchange 00:12:48: ISAKMP (0:7): Input = IKE_MESG_INTERNAL, IKE_XAUTH_REPLY_ATTR Old State = IKE_XAUTH_REPLY_AWAIT New State = IKE_XAUTH_REPLY_SENT 00:12:48: ISAKMP (0:7): received packet from 192.168.192.81 (I) CONF_XAUTH 00:12:48: ISAKMP: set new node 1465183127 to CONF_XAUTH ! The server confirms the login name and password ! Authentication is successful 00:12:48: ISAKMP (0:7): processing transaction payload from 192.168.192.81. message ID = 1465183127 00:12:48: ISAKMP: Config payload SET 00:12:48: ISAKMP (0:7): Xauth process set, status = 1 00:12:48: ISAKMP (0:7): checking SET:
continues
718
crypto isakmp When Attempting to Establish an IPSec VPN Tunnel (Continued)

00:12:48: ISAKMP: XAUTH_STATUS_V2 XAUTH-OK 00:12:48: ISAKMP (0:7): attributes sent in message: 00:12:48: Status: 1 00:12:48: ISAKMP (0:7): sending packet to 192.168.192.81 (I) CONF_XAUTH 00:12:48: ISAKMP (0:7): deleting node 1465183127 error FALSE reason 00:12:48: ISAKMP (0:7): Input = IKE_MESG_FROM_PEER, IKE_CFG_SET Old State = IKE_XAUTH_REPLY_SENT New State = IKE_P1_COMPLETE ! IKE phase one completed successfully. 00:12:48: ISAKMP (0:7): Need config/address 00:12:48: ISAKMP (0:7): Need config/address 00:12:48: ISAKMP: set new node 1868961837 to CONF_ADDR 00:12:48: ISAKMP (0:7): initiating peer config to 192.168.192.81. ID = 1868961837 00:12:48: ISAKMP (0:7): sending packet to 192.168.192.81 (I) CONF_ADDR 00:12:48: ISAKMP (0:7): Input = IKE_MESG_INTERNAL, IKE_PHASE1_COMPLETE Old State = IKE_P1_COMPLETE New State = IKE_CONFIG_MODE_REQ_SENT ! The end user receives a configuration from the server. 00:12:48: ISAKMP (0:7): received packet from 192.168.192.81 (I) CONF_ADDR 00:12:48: ISAKMP (0:7): processing transaction payload from 192.168.192.81. message ID = 1868961837 00:12:48: ISAKMP: Config payload REPLY 00:12:48: ISAKMP(0:7) process config reply 00:12:48: ISAKMP (0:7): deleting node 1868961837 error FALSE reason done with transaction 00:12:48: ISAKMP (0:7): Input = IKE_MESG_FROM_PEER, IKE_CFG_REPLY Old State = IKE_CONFIG_MODE_REQ_SENT New State = IKE_P1_COMPLETE ! Request for configuration mode sent. 00:12:48: ISAKMP (0:7): Input = IKE_MESG_INTERNAL, IKE_PHASE1_COMPLETE Old State = IKE_P1_COMPLETE New State = IKE_P1_COMPLETE 00:12:48: ISAKMP: received ke message (1/4) 00:12:48: ISAKMP: set new node 0 to QM_IDLE 00:12:48: ISAKMP (0:7): sitting IDLE. Starting QM immediately (QM_IDLE 00:12:48: ISAKMP (0:7): beginning Quick Mode exchange, M-ID of 85557524 ! Quick mode begins.
00:12:48: ISAKMP (0:7): sending packet to 192.168.192.81 (I) QM_IDLE 00:12:48: ISAKMP (0:7): Node 85557524, Input = IKE_MESG_INTERNAL, IKE_INIT_QM Old State = IKE_QM_READY New State = IKE_QM_I_QM1 00:12:48: ISAKMP (0:7): received packet from 192.168.192.81 (I) QM_IDLE ! Quick mode exchange 00:12:48: ISAKMP (0:7): processing HASH payload. message ID = 85557524 00:12:48: ISAKMP (0:7): processing SA payload. message ID = 85557524 00:12:48: ISAKMP (0:7): Checking IPSec proposal 1 ! IPSec proposal 1 sent. 00:12:48: ISAKMP: transform 1, ESP_3DES 00:12:48: ISAKMP: attributes in transform: 00:12:48: ISAKMP: SA life type in seconds 00:12:48: ISAKMP: SA life duration (basic) of 3600 00:12:48: ISAKMP: SA life type in kilobytes 00:12:48: ISAKMP: SA life duration (VPI) of 0x0 0x46 0x50 0x0 00:12:48: ISAKMP: encaps is 1
719
crypto isakmp When Attempting to Establish an IPSec VPN Tunnel (Continued)

00:12:48: ISAKMP: authenticator is HMAC-MD5 00:12:48: ISAKMP (0:7): atts are acceptable. 00:12:48: ISAKMP (0:7): processing NONCE payload. message ID = 85557524 00:12:48: ISAKMP (0:7): processing ID payload. message ID = 85557524 00:12:48: ISAKMP (0:7): processing ID payload. message ID = 85557524 00:12:48: ISAKMP (0:7): Creating IPSec Sas ! Creating the security association, which includes the IP addresses, ! the protocol (ESP or AH), and SPI. 00:12:48: inbound SA from 192.168.192.81 to 66.127.241.85 ! The public IP address (proxy 0.0.0.0 to 10.31.17.129) 00:12:48: has spi 0x9608BACF and conn_id 2000 and flags 4 00:12:48: lifetime of 3600 seconds 00:12:48: lifetime of 4608000 kilobytes 00:12:48: outbound SA from 66.127.241.85 to 192.168.192.81 (proxy 10.31.17.129 to 0.0.0.0 ) 00:12:48: has spi 703036318 and conn_id 2001 and flags C 00:12:48: lifetime of 3600 seconds 00:12:48: lifetime of 4608000 kilobytes 00:12:48: ISAKMP (0:7): sending packet to 192.168.192.81 (I) QM_IDLE 00:12:48: ISAKMP (0:7): deleting node 85557524 error FALSE reason 00:12:48: ISAKMP (0:7): Node 85557524, Input = IKE_MESG_FROM_PEER, IKE_QM_EXCH Old State = IKE_QM_I_QM1 New State = IKE_QM_PHASE2_COMPLETE ! ISAKMP phase 2 complete and the parameters are negotiated. 00:12:48: ISAKMP: received ke message (4/1) 00:12:48: ISAKMP: Locking CONFIG struct 0x80F93638 for crypto_ikmp_config_handle_kei_mess, count 3 00:12:48: ISAKMP (0:7): received packet from 192.168.192.81 (I) QM_IDLE 00:12:48: ISAKMP: set new node 1502656406 to QM_IDLE 00:12:48: ISAKMP (0:7): processing HASH payload. message ID = 1502656406 00:12:48: ISAKMP (0:7): processing NOTIFY unknown protocol 1 spi 0, message ID = 1502656406, sa = 80EB31E8 00:12:48: ISAKMP (0:7): deleting node 1502656406 error FALSE reason informational (in) state 1 00:12:48: ISAKMP (0:7): Input = IKE_MESG_FROM_PEER, IKE_INFO_NOTIFY Old State = IKE_P1_COMPLETE New State = IKE_P1_COMPLETE
In addition to the steps outlined in Table 21-9 for troubleshooting connectivity issues, you might nd the following commands useful for monitoring the Cisco Easy VPN environment:
To verify the applied policy, use show crypto isakmp policy (see Example 21-12). To check the ISAKMP security association, use show crypto isakmp sa (see Example 21-13). To check the status of the Cisco Easy VPN client prole, use show crypto ipsec prole (see Example 21-14). To check the status of the IPSec SA, use show crypto ipsec sa (see Example 21-15). To check the status of the crypto engine connections, use show crypto engine connections active (see Example 21-16).
720
Example 21-12 Output of show crypto isakmp policy Command

Router-EzVPN#show crypto isakmp policy Protection suite of priority 65527 encryption algorithm: DES - Data Encryption Standard (56 bit keys). hash algorithm: Secure Hash Standard authentication method: Diffie-Hellman group: #2 (1024 bit) lifetime: 65535 seconds, no volume limit <output omitted> Default protection suite encryption algorithm: hash algorithm: authentication method: Diffie-Hellman group: lifetime:
DES - Data Encryption Standard (56 bit keys). Secure Hash Standard Rivest-Shamir-Adleman Signature #1 (768 bit) 86400 seconds, no volume limit
Example 21-13 Output of show crypto isakmp sa Command

Router-EzVPN#show crypto isakmp sa dst src state 192.168.192.81 66.127.241.85 QM_IDLE conn-id 7 slot 0
Example 21-14 Output of show crypto ipsec prole Command

Router-EzVPN#show crypto ipsec profile IPSEC profile ezvpn-profile Security association lifetime: 4608000 kilobytes/3600 seconds PFS (Y/N): N Transform sets={ ezvpn-profile-autoconfig-transform-0, ezvpn-profile-autoconfig-transform-1, ezvpn-profile-autoconfig-transform-2, ezvpn-profile-autoconfig-transform-3, }
Example 21-15 Output of show crypto ipsec sa Command

Route-EzVPN#show crypto ipsec sa interface: Ethernet1 Crypto map tag: Ethernet1-head-0, local addr. 66.127.241.85 local ident (addr/mask/prot/port): (192.168.192.81/255.255.255.255/0/0) remote ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0) current_peer: 192.168.192.81 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 0, #recv errors 0
721
Example 21-15 Output of show crypto ipsec sa Command (Continued)

local crypto endpt.: 66.127.241.85, remote crypto endpt.: 192.168.192.81 path mtu 1500, media mtu 1500 current outbound spi: 36B6AD4B inbound esp sas: ! Inbound direction of ESP Security Association spi: 0x74FBAEB0(1962651312) transform: esp-3des esp-md5-hmac , in use settings ={Tunnel, } slot: 0, conn id: 2000, flow_id: 1, crypto map: Ethernet1-head-0 sa timing: remaining key lifetime (k/sec): (4608000/3374) IV size: 8 bytes replay detection support: Y inbound ah sas: ! The client is not running the AH protocol, so it is empty inbound pcp sas: ! The client is not running PCP, so it is empty outbound esp sas: ! Outbound direction of ESP SA spi: 0x36B6AD4B(917941579) transform: esp-3des esp-md5-hmac , in use settings ={Tunnel, } slot: 0, conn id: 2001, flow_id: 2, crypto map: Ethernet1-head-0 sa timing: remaining key lifetime (k/sec): (4608000/3374) IV size: 8 bytes replay detection support: Y outbound ah sas: outbound pcp sas:
Example 21-16 Output of show crypto engine connections active Command

Router-EzVPN #show ID Interface 22 Ethernet1 2000 Ethernet1 2001 Ethernet1 crypto engine connections active IP-Address State Algorithm Encrypt Decrypt 66.127.241.85 set HMAC_MD5+3DES_56_C 0 0 66.127.241.85 set HMAC_MD5+3DES_56_C 0 0 66.127.241.85 set HMAC_MD5+3DES_56_C 0 0
Cisco PIX VPN Client

Starting with v6.2, the Pix 501 and 506 can be congured as VPN clients. These platforms can be congured in Client or Network Extension mode, and perform similarly to the Cisco VPN 3002 HW client.
722
Restrictions and Limitations

The PIX 501 and 506, when congured as VPN clients, share the same restrictions as the VPN 3002 HW client, such as a lack of support for multicast trafc and IP telephony when congured in Client mode. At the time this was written, a notable limitation was the lack of support for NAT transparency. However, most of these features might be addressed by the time this book is available. For the latest feature status, consult www.cisco.com.
Verifying and Troubleshooting the VPN Connection

Assuming that you have correctly congured your PIX 501 or 506 to provide Internet connectivity, you can verify the VPN Client conguration with the command, show vpnclient. Results are shown in Example 21-17. All examples in this section were created on a PIX 501 running v6.2 of the PIX operating system.
Example 21-17 Output of show vpnclient Command on PIX
pix#show vpnclient Local Configuration vpnclient vpngroup pix password ******** vpnclient username smith password ******** vpnclient server 192.168.192.81 ! Core device terminating the VPN tunnel. vpnclient mode client-mode ! PIX can be configured in Client or Network Extension mode. vpnclient enable
At this point, the VPN tunnel is not established. You should be able to establish the VPN tunnel by trying to ping a device on the internal network on the other end of the tunnel. The rst few pings might fail but a tunnel should be established. The tunnel information can be viewed with the output from the following commands:
show vpnclient (see Example 21-18) show crypto ipsec sa (see Example 21-19) show crypto isakmp sa (see Example 21-20)
If the tunnel is not established, you cannot see any Downloaded Dynamic Policy parameters, and the ESP SA or (SPI) security parameter index is not established. At that point, if you have conrmed the PIX conguration and Internet connectivity, you might want to clear the VPN client information by using the command clear vpnclient in the global conguration mode. Then, re-enter the VPN client conguration information.
723
Example 21-18 Output from show vpnclient Command on PIX Congured as a VPN Client after Establishing a
VPN Tunnel
pix#show vpnclient Local Configuration vpnclient vpngroup pix password ******** ! pix was the entered groupname vpnclient username smith password ******** ! smith was the entered username vpnclient server 192.168.192.81 vpnclient mode network-extension-mode vpnclient enable Downloaded Dynamic Policy Current Server : 192.168.192.81 Primary DNS : 192.168.226.120 Secondary DNS : 192.168.168.183 Primary WINS : 192.168.2.87 Secondary WINS : 192.168.235.228 Default Domain : cisco.com PFS Enabled : No Split DNS : cisco.com_
Example 21-19 Output from show crypto ipsec sa Command After Establishment of VPN Tunnel
pix#show crypto ipsec sa interface: outside Crypto map tag: _vpnc_cm, local addr. 12.235.95.31 ! 12.235.95.31 is the IP address of outside interface of the PIX local ident (addr/mask/prot/port): (10.25.250.1/255.255.255.255/0/0) remote ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0) current_peer: 192.168.192.81 ! 192.168.192.81 is IP address of the core VPN terminating device PERMIT, flags={origin_is_acl,} #pkts encaps: 101, #pkts encrypt: 101, #pkts digest 101 ! Number of packets encrypted #pkts decaps: 140, #pkts decrypt: 140, #pkts verify 140 #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.: 12.235.95.31, remote crypto endpt.: 192.168.192.81 path mtu 1500, ipsec overhead 56, media mtu 1500 current outbound spi: 321e317b ! SPI has been created inbound esp sas: spi: 0xb84c8c89(3092024457) transform: esp-3des esp-md5-hmac ,
continues
724
Example 21-19 Output from show crypto ipsec sa Command After Establishment of VPN Tunnel (Continued)
in use settings ={Tunnel, } slot: 0, conn id: 1, crypto map: _vpnc_cm sa timing: remaining key lifetime (k/sec): (4607889/28424) IV size: 8 bytes replay detection support: Y ! Inbound SA has been created with the esp protocol using ! 3DES encryption, md5 hash inbound ah sas: ! Authentication Header (AH) was not an option on the core device ! terminating the VPN connection
inbound pcp sas: ! Payload Compression Protocol (pcp) was not an option on the core device ! terminating the VPN tunnel7 outbound esp sas: spi: 0x321e317b(840839547) transform: esp-3des esp-md5-hmac , in use settings ={Tunnel, } slot: 0, conn id: 2, crypto map: _vpnc_cm sa timing: remaining key lifetime (k/sec): (4607995/28419) IV size: 8 bytes replay detection support: Y ! Outbound esp SAS outbound ah sas:
outbound pcp sas:
outbound ah sas:
outbound pcp sas: local ident (addr/mask/prot/port): (12.235.95.31/255.255.255.255/0/0) remote ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0) current_peer: 192.168.192.81 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 1, #recv errors 0
725
Example 21-19 Output from show crypto ipsec sa Command After Establishment of VPN Tunnel (Continued)
local crypto endpt.: 12.235.95.31, remote crypto endpt.: 192.168.192.81 path mtu 1500, ipsec overhead 56, media mtu 1500 current outbound spi: 76accd0d inbound esp sas: spi: 0x948b4d0c(2492157196) transform: esp-3des esp-md5-hmac , in use settings ={Tunnel, } slot: 0, conn id: 3, crypto map: _vpnc_cm sa timing: remaining key lifetime (k/sec): (4608000/28706) IV size: 8 bytes replay detection support: Y
inbound ah sas:
inbound pcp sas:
outbound esp sas: spi: 0x76accd0d(1991036173) transform: esp-3des esp-md5-hmac , in use settings ={Tunnel, } slot: 0, conn id: 4, crypto map: _vpnc_cm sa timing: remaining key lifetime (k/sec): (4608000/28706) IV size: 8 bytes replay detection support: Y
outbound ah sas:
outbound pcp sas:
Example 21-20 Output from show crypto isakmp sa Command After Establishing VPN Tunnel
pix#show crypto isakmp sa Total : 1 Embryonic : 0 dst src state pending created 192.168.192.81 12.235.95.31 QM_IDLE 0 2 ! If the VPN tunnel had not been established then the created ! entry would have been zero.
The log from a VPN 3000 series concentrator that shows the establishment of the VPN tunnel illustrated in the previous two examples is shown in Example 21-21. This again shows how the troubleshooting engineer can analyze the process from the other end, and what the process looks like.
726
Example 21-21 Log from a VPN 3000 Series Concentrator for a PIX Client
13160 07/17/2002 08:13:50.200 SEV=4 IKE/52 RPT=4625 12.235.95.31 Group [pix] User [smith] User (smith) authenticated. 13161 07/17/2002 08:13:51.690 SEV=4 AUTH/22 RPT=4826 User smith connected 13162 07/17/2002 08:13:51.690 SEV=4 IKE/119 RPT=16260 12.235.95.31 Group [pix] User [smith] PHASE 1 COMPLETED 13164 07/17/2002 08:13:51.690 SEV=5 IKE/25 RPT=39847 12.235.95.31 Group [pix] User [smith] Received remote Proxy Host data in ID Payload: Address 10.25.250.1, Protocol 0, Port 0 13167 07/17/2002 08:13:51.690 SEV=5 IKE/34 RPT=47957 12.235.95.31 Group [pix] User [smith] Received local IP Proxy Subnet data in ID Payload: Address 0.0.0.0, Mask 0.0.0.0, Protocol 0, Port 0 13170 07/17/2002 08:13:51.690 SEV=5 IKE/66 RPT=21557 12.235.95.31 Group [pix] User [smith] IKE Remote Peer configured for SA: ESP/IKE-3DES-MD5 13171 07/17/2002 08:13:51.710 SEV=4 IKE/49 RPT=21627 12.235.95.31 Group [pix] User [smith] Security negotiation complete for User (smith) Responder, Inbound SPI = 0x321e317b, Outbound SPI = 0xb84c8c89 ! The Inbound and Outbound SPI are reversed compared ! to the log from PIX client. 13174 07/17/2002 08:13:51.710 SEV=4 IKE/120 RPT=21627 12.235.95.31 Group [pix] User [smith] PHASE 2 COMPLETED (msgid=e367589c) 13181 07/17/2002 08:13:55.270 SEV=5 IKE/25 RPT=39848 12.235.95.31 Group [pix] User [smith] Received remote Proxy Host data in ID Payload: Address 12.235.95.31, Protocol 0, Port 0 13184 07/17/2002 08:13:55.270 SEV=5 IKE/34 RPT=47958 12.235.95.31 Group [pix] User [smith] Received local IP Proxy Subnet data in ID Payload: Address 0.0.0.0, Mask 0.0.0.0, Protocol 0, Port 0 13187 07/17/2002 08:13:55.270 SEV=5 IKE/66 RPT=21558 12.235.95.31 Group [pix] User [smith] IKE Remote Peer configured for SA: ESP/IKE-3DES-MD5 13188 07/17/2002 08:13:55.290 SEV=4 IKE/49 RPT=21628 12.235.95.31 Group [pix] User [smith]
727
Example 21-21 Log from a VPN 3000 Series Concentrator for a PIX Client (Continued)
Security negotiation complete for User (smith) Responder, Inbound SPI = 0x76accd0d, Outbound SPI = 0x948b4d0c ! Again, the SPI identifying the IPSec SAs reversed on the PIX client. 13191 07/17/2002 08:13:55.290 SEV=4 IKE/120 RPT=21628 12.235.95.31 Group [pix] User [smith] PHASE 2 COMPLETED (msgid=3be10994)
Two debug commands that can provide detailed information during the negotiation of the VPN tunnels are the following:
debug crypto ipsec sa debug crypto isakmp sa
Output on the PIX 501 after enabling these debugs before the VPN tunnel negotiation is shown in Example 21-22. By checking this output, you can observe if something is failing during the tunnel negotiation process.
Example 21-22 Output on PIX After Implementing debug crypto ipsec sa and debug crypto isakmp sa and
Enabling a VPN Client

pix# debug crypto ipsec pix# debug crypto isakmp pix# show debug debug crypto ipsec 1 debug crypto isakmp 1 pix#config terminal pix(config)# vpnclient vpngroup pix password abcd pix(config)# vpnclient server 192.168.192.81 pix(config)# vpnclient mode network pix(config)# vpnclient username smith password efghij pix(config)# vpnclient enable ! After this group of configuration commands, you can see the following events: pViPx(coNnCfig )#C FG: transform set unconfig attempt done VPNC CLI: no isakmp keepalive 10 VPNC CFG: IKE unconfig successful VPNC CLI: no crypto map _vpnc_cm VPNC CFG: crypto map deletion attempt done VPNC CFG: crypto unconfig successful VPNC CLI: no global 65001 VPNC CLI: no nat (inside) 0 access-list _vpnc_acl VPNC CFG: nat unconfig attempt failed VPNC CLI: no access-list _vpnc_acl VPNC CFG: ACL deletion attempt failed VPNC CLI: no crypto ALT_DEF_DOMAIN INTERNAL_IPV_NBNS INTERNAL_IPV_DNS ALT_SPLIT_INCLUDE ALT_SPLITDNS_NAME
continues
728
Enabling a VPN Client (Continued)

ALT_PFS map _vpnc_cm interface outside VPNC CFG: crypto map de/attach failed VPNC CLI: no sysopt connection permit-ipsec VPNC CLI: sysopt connection permit-ipsec VPNC CFG: transform sets configured VPNC CFG: crypto config successful VPNC CLI: isakmp keepalive 10 VPNC CFG: IKE config successful VPNC CLI: no access-list _vpnc_acl VPNC CFG: ACL deletion attempt failed VPNC CLI: access-list _vpnc_acl permit ip host 12.235.95.31 host 192.168.192.81 VPNC CLI: crypto map _vpnc_cm 10 match address _vpnc_acl VPNC CFG: crypto map acl update successful VPNC CLI: no crypto map _vpnc_cm interface outside VPNC CLI: crypto map _vpnc_cm interface outside VPN Peer: ISAKMP: Added new peer: ip:192.168.192.81 Total VPN Peers:1 VPN Peer: ISAKMP: Peer ip:192.168.192.81 Ref cnt incremented to:1 Total VPN Peers:1 ISAKMP (0): ID payload next-payload : 13 type : 11 protocol : 17 port : 500 length : 7 ISAKMP (0): Total payload length: 11 ISAKMP (0): beginning Aggressive Mode exchangeVPNC INF: Request for IKE trigger done crypto_isakmp_process_block: src 192.168.192.81, dest 12.235.95.31 OAK_AG exchange ISAKMP (0): processing SA payload. message ID = 0 ISAKMP (0): Checking ISAKMP transform 2 against priority 65010 policy ISAKMP: encryption 3DES-CBC ISAKMP: hash MD5 ISAKMP: default group 2 ISAKMP: extended auth pre-share ISAKMP: life type in seconds ! Lifetime duration of the ISAKMP SA in seconds ISAKMP: life duration (VPI) of 0x0 0x1 0x51 0x80 ISAKMP (0): atts are not acceptable. Next payload is 0 ISAKMP (0): Checking ISAKMP transform 2 against priority 65020 policy ISAKMP: encryption 3DES-CBC ISAKMP: hash MD5 ISAKMP: default group 2 ISAKMP: extended auth pre-share ISAKMP: life type in seconds ISAKMP: life duration (VPI) of 0x0 0x1 0x51 crypto_isakmp_process_block: src 192.168.192.81, dest 12.235.95.31
729

ISAKMP_TRANSACTION exchange ISAKMP (0:0): processing transaction payload from 192.168.192.81. message ID = 2158353436 crypto_isakmp_process_block: src 192.168.192.81, dest 12.235.95.31 ISAKMP_TRANSACTION exchange ISAKMP (0:0): processing transaction payload from 192.168.192.81. message ID = 2158353436 ISAKMP: Config payload CFG_SET ISAKMP (0:0): checking SET: ISAKMP: XAUTH_STATUS ISAKMP (0:0): attributes sent in message: Status: 1 return status is IKMP_NO_ERROR VPNC INF: Constructing policy download req VPNC INF: Packing attributes for policy request VPNC INF: Attributes being requested ISAKMP : attributes being requested ISAKMP (0:0): initiating peer config to 192.168.192.81. ID = 3931692763 (0xea58dedb) crypto_isakmp_process_block: src 192.168.192.81, dest 12.235.95.31 ISAKMP_TRANSACTION exchange ISAKMP (0:0): processing transaction payload from 192.168.192.81. message ID = 2158353436 ISAKMP: Config payload CFG_REPLYVPNC ATTR: INTERNAL_IP4_DNS: 192.168.226.120 VPNC ATTR: INTERNAL_IP4_DNS: 192.168.168.183 VPNC ATTR: INTERNAL_IP4_NBNS: 192.168.2.87 VPNC ATTR: INTERNAL_IP4_NBNS: 192.168.235.228 VPNC ATTR: ALT_DEF_DOMAIN: cisco.com VPNC ATTR: ALT_SPLITDNS_NAME cisco.com_ VPNC ATTR: ALT_PFS: 0 VPNC INF: Received application version Cisco Systems, Inc./VPN 3000 Concentrator Version 3.5.2.Rel built by vmurphy on Feb 14 2002 12:10:21 ! Version information of VPN 3000 Concentrator terminating the IPSec tunnel VPNC CLI: no VPNC INF: IPSec rmt mgmt trigger done ISAKMP (0): beginning Quick Mode exchange, M-ID of 1015758940:3c8b405cIPSEC (key_engine): got a queue event... IPSEC(spi_response): getting spi 0x689d0b46(1755122502) for SA from 192.168.192.81 to 12.235.95.31 for prot 3 crypto_isakmp_process_block: src 192.168.192.81, dest 12.235.95.31 OAK_QM exchange oakley_process_quick_mode:
continues
730

OAK_QM_IDLE ISAKMP (0): processing SA payload. message ID = 1015758940 ISAKMP : Checking IPSec proposal 1 ISAKMP: transform 1, ESP_3DES ISAKMP: attributes in transform: ISAKMP: SA life type in seconds ISAKMP: SA life duration (basic) of 28800 ISAKMP: SA life type in kilobytes ISAKMP: SA life duration (VPI) of 0x0 0x46 0x50 0x0 ISAKMP: encaps is 1 ISAKMP: authenticator is HMAC-MD5 ISAKMP (0): atts are acceptable.IPSEC(validate_proposal_request): proposal part #1, (key eng. msg.) dest= 192.168.192.81, src= 12.235.95.31, dest_proxy= 0.0.0.0/0.0.0.0/0/0 (type=4), src_proxy= 12.235.95.31/255.255.255.255/0/0 (type=1), protocol= ESP, transform= esp-3des esp-md5-hmac , lifedur= 0s and 0kb, spi= 0x0(0), conn_id= 0, keysize= 0, flags= 0x4 ISAKMP (0): processing NONCE payload. message ID = 1015758940 ISAKMP (0): processing ID payload. message ID = 1015758940 ISAKMP (0): processing ID payload. message ID = 1015758940 ISAKMP (0): Creating IPSec SAs inbound SA from 192.168.192.81 to 12.235.95.31 (proxy 0.0.0.0 to 12.235.95.31) has spi 1755122502 and conn_id 4 and flags 4 lifetime of 28800 seconds lifetime of 4608000 kilobytes outbound SA from 12.235.95.31 to 192.168.192.81 (proxy 12.235.95.31 to 0.0.0.0) has spi 865892405 and conn_id 3 and flags 4 lifetime of 28800 seconds lifetime of 4608000 kilobytesIPSEC(key_engine): got a queue event... IPSEC(initialize_sas): , (key eng. msg.) dest= 12.235.95.31, src= 192.168.192.81, dest_proxy= 12.235.95.31/255.255.255.255/0/0 (type=1), src_proxy= 0.0.0.0/0.0.0.0/0/0 (type=4), protocol= ESP, transform= esp-3des esp-md5-hmac , lifedur= 28800s and 4608000kb, spi= 0x689d0b46(1755122502), conn_id= 4, keysize= 0, flags= 0x4 IPSEC(initialize_sas): , (key eng. msg.) src= 12.235.95.31, dest= 192.168.192.81, src_proxy= 12.235.95.31/255.255.255.255/0/0 (type=1), dest_proxy= 0.0.0.0/0.0.0.0/0/0 (type=4), protocol= ESP, transform= esp-3des esp-md5-hmac , lifedur= 28800s and 4608000kb, spi= 0x339c7835(865892405), conn_id= 3, keysize= 0, flags= 0x4
731

VPN Peer: IPSEC: Peer ip:192.168.192.81 Ref cnt incremented to:2 Total VPN Peers:1 VPN Peer: IPSEC: Peer ip:192.168.192.81 Ref cnt incremented to:3 Total VPN Peers:1 return status is IKMP_NO_ERROR ISAKMP (0): beginning Quick Mode exchange, M-ID of 1352049028:5096a184IPSEC (key_engine): got a queue event... IPSEC(spi_response): getting spi 0x4dbb61e3(1304125923) for SA from 192.168.192.81 to 12.235.95.31 for prot 3 crypto_isakmp_process_block: src 192.168.192.81, dest 12.235.95.31 OAK_QM exchange oakley_process_quick_mode: OAK_QM_IDLE ISAKMP (0): processing SA payload. message ID = 1352049028 ISAKMP : Checking IPSec proposal 1 ISAKMP: transform 1, ESP_3DES ISAKMP: attributes in transform: ISAKMP: SA life type in seconds ISAKMP: SA life duration (basic) of 28800 ISAKMP: SA life type in kilobytes ISAKMP: SA life duration (VPI) of 0x0 0x46 0x50 0x0 ISAKMP: encaps is 1 ISAKMP: authenticator is HMAC-MD5 ISAKMP (0): atts are acceptable.IPSEC(validate_proposal_request): proposal part #1, (key eng. msg.) dest= 192.168.192.81, src= 12.235.95.31, dest_proxy= 0.0.0.0/0.0.0.0/0/0 (type=4), src_proxy= 10.25.0.128/255.255.255.240/0/0 (type=4), protocol= ESP, transform= esp-3des esp-md5-hmac , lifedur= 0s and 0kb, spi= 0x0(0), conn_id= 0, keysize= 0, flags= 0x4 ISAKMP (0): processing NONCE payload. message ID = 1352049028 ISAKMP (0): processing ID payload. message ID = 1352049028 ISAKMP (0): processing ID payload. message ID = 1352049028 ISAKMP (0): Creating IPSec SAs inbound SA from 192.168.192.81 to 12.235.95.31 (proxy 0.0.0.0 to 10.25.0.128) has spi 1304125923 and conn_id 2 and flags 4 lifetime of 28800 seconds lifetime of 4608000 kilobytes outbound SA from 12.235.95.31 to 192.168.192.81 (proxy 10.25.0.128 to 0.0.0.0) has spi 17882921 and conn_id 1 and flags 4 lifetime of 28800 seconds lifetime of 4608000 kilobytesIPSEC(key_engine): got a queue event...
continues
732

IPSEC(initialize_sas): , (key eng. msg.) dest= 12.235.95.31, src= 192.168.192.81, dest_proxy= 10.25.0.128/255.255.255.240/0/0 (type=4), src_proxy= 0.0.0.0/0.0.0.0/0/0 (type=4), protocol= ESP, transform= esp-3des esp-md5-hmac , lifedur= 28800s and 4608000kb, spi= 0x4dbb61e3(1304125923), conn_id= 2, keysize= 0, flags= 0x4 IPSEC(initialize_sas): , (key eng. msg.) src= 12.235.95.31, dest= 192.168.192.81, src_proxy= 10.25.0.128/255.255.255.240/0/0 (type=4), dest_proxy= 0.0.0.0/0.0.0.0/0/0 (type=4), protocol= ESP, transform= esp-3des esp-md5-hmac , lifedur= 28800s and 4608000kb, spi= 0x110df29(17882921), conn_id= 1, keysize= 0, flags= 0x4 VPN Peer: IPSEC: Peer ip:192.168.192.81 Ref cnt incremented to:4 Total VPN Peers:1 VPN Peer: IPSEC: Peer ip:192.168.192.81 Ref cnt incremented to:5 Total VPN Peers:1 return status is IKMP_NO_ERROR
An overall discussion of PIX-based solutions is beyond the scope of this book. The objectives of this section are only to help you troubleshoot PIX-based VPN solutions. For further details on PIX-based VPN solutions as part of the overall security strategy of Cisco, see Cisco Secure PIX Firewalls by David W. Chapman and Andy Fox (Cisco Press, 2002).
Internet Technologies and Remote Access VPNs

In this section, issues are briey covered that are specic to three popular technologies that offer broadband services for most remote access VPNs:
VPN and ADSL VPN and Internet access through cable TV infrastructure VPN and Internet access over satellite and wireless systems
VPN and ADSL

A typical ADSL architecture is composed of equipment at the ADSL point of presence (POP) and customer premises equipment (CPE). Network access providers (NAPs) manage Layer 2 network cores, and network service providers (NSPs) manage Layer 3 network cores. These roles are divided or shared among incumbent local exchange carriers (ILECs), competitive local exchange carriers (CLECs), and Tier 1 and Tier 2 Internet service providers (ISPs).
733
CPEs can consist of PCs or workstations, remote ADSL terminating units (ATU-Rs), and routers. For example, a residential user might have a single PC connected through Ethernet to an ADSL modem. The end-user might also connect their PC or workstations through Ethernet to a router with an integrated ADSL modem, or a two-port Ethernet router that is then connected to a stand-alone ADSL modem. DSL access multiplexers (DSLAMs) are installed at the ADSL POP, and because the DSLAMs service the local loops between residences and businesses and the POP, they are often located in the ILECs central ofce (CO). DSLAMs connect to a local access concentrator (LAC) or the node route processor (NRP). The LAC provides Layer 3 connectivity from the CPE to the NSP or IP network. More detailed discussion of this topic is divided into the following sections:

PPPoE
PPPoE PPPoE design details PPPoE discovery stage PPPoE session stage Review of the PPPoE discovery and session negotiation Common issues for RA VPNs with PPPoE on ADSL
PPPoE is becoming the technology of choice for new DSL installations. It enables providers to conserve IP addresses and use them per connection, and to track the IP address to a specic client. RFC 2516 provides the standard for communicating through PPPoE. With PPPoE, an ADSL modem acts as an Ethernet-to-wide-area network (WAN) bridge. The PPP network parameters are negotiated and the PPP session is established between the CPE and the LAC or NRP. CPEs that can negotiate PPP parameters and terminate the session include both a host and router. Any host with PPP client software such as RASPPPoE, NTS EnterNet or Windows PPP over Ethernet Client Software Application (WINPoET), can perform this function. A router such as the Cisco 806 dual Ethernet router that sits behind an ADSL modem, or the Cisco 827 that incorporates the ADSL modem and establishes the PPP session, are examples of typical small ofce/home ofce (SOHO) CPEs that can handle all facets of the PPP session. The CPE starts a PPP session by encapsulating PPP frames into a Media Access Control (MAC) frame, then bridging the frame (over Asynchronous Transfer Mode [ATM]/DSL) to the LAC or NRP. As a result, PPP sessions can be established, authenticated, and addressed. The client receives its IP address using IP Control Protocol (IPCP) from the PPP termination point, or the LAC or NRP. An example of a DSL implementation that uses a PPPoE network architecture is shown in Figure 21-8.
734
Figure 21-8 PPPoE over ADSL Architecture Example 8
PPPoE IP=192.168.1.10 GW Points to Unnumbered
PPP Session Validation NRP Establishes a Host Route to 192.168.1.10 6xx in Bridge Mode NRP Terminating Internet Aggregator 6400
PC with a PPPoE Client WINPoET
DSLAM 61xx/62xx
AAA
PPPoE Stages
As specied in RFC 2516, PPPoE has two distinct stages, the discovery stage and the PPP session stage. When a host wants to start a PPPoE session, it must rst perform discovery to identify which server can meet this clients request, then identify the Ethernet MAC address of the peer and establish a PPPoE SESSION_ID. Although PPP denes a peer-to-peer relationship, discovery is inherently a client-server relationship. In the discovery process, a host (the client) discovers an access concentrator (AC) (the server). Based on the network topology, more than one AC can communicate with the host. The discovery stage allows the host to discover all ACs and then select one. When discovery is successfully completed, both the host and the selected AC have the information they need to build a point-to-point connection over Ethernet. After a PPP session is established, both the host and the AC must allocate the resources for a PPP virtual interface; however, this might not be the case for all implementations. Finally, to be in compliance with RFC 2516, the IP MTU must be specied as 1492 for PPPoE.
PPPoE Discovery Stage

The discovery stage consists of four steps:
Step 1 The host broadcasting an initiation packet Step 2 One or more ACs sending offer packets Step 3 The host sending a unicast session request packet Step 4 The selected AC sending a conrmation packet
735
When the host receives the conrmation packet, it proceeds to the PPP session stage, and when the AC sends the conrmation packet, it proceeds to the PPP session stage. At the completion of the discovery stage, both peers know the PPPoE SESSION_ID and the peers Ethernet address, which together dene the PPPoE session uniquely. The host sends the PPPoE Active Discovery Initiation (PADI) packet with the DESTINATION_ADDR set to the broadcast address. The PADI consists of one tag, indicating what service type it is requesting. When the AC receives a PADI that it can serve, it replies by sending a PPPoE Active Discovery Offer (PADO) packet. The DESTINATION_ADDR is the unicast address of the host that sent the PADI. If the AC cannot serve the PADI, it must not respond with a PADO. Because the PADI was broadcast, the host can receive more than one PADO. The host reviews the PADO packets it receives and chooses one. The choice can be based on the services offered by each AC. The host then sends one PPPoE Active Discovery Request (PADR) packet to the AC that it has chosen. The DESTINATION_ADDR eld is set to the unicast Ethernet address of the AC, or the router that sent the PADO. When the AC receives a PADR packet, it prepares to begin a PPP session. It generates a unique SESSION_ID for the PPPoE session, and replies to the host with a PPPoE Active Discovery Session-conrmation (PADS) packet. The DESTINATION_ADDR eld is the unicast Ethernet address of the host that sent the PADR. The PPPoE negotiation process is shown in Figure 21-9.
Figure 21-9 Negotiation Process for a PPPoE Client
VPI/VCI 1/1 VPI/VCI 1/33
PPPoE Client
ATU-R
DSLAM ATM
Aggregator
PADI PADO PADR PADS (Session ID) LCP/IPCP
736
PPPoE Session Stage

After the PPPoE session begins, PPP data is sent as in any other PPP encapsulation. The typical number of steps per exchange in the PPPoe session stage is four steps for link control protocol (LCP), two or four steps for AUTH, and a various number of steps for Network Control Protocol (NCP), it is dependent on the Layer 3 protocols that are in use. At this point, all Ethernet packets are unicast. A PPPoE Active Discovery Terminate (PADT) packet can be sent anytime after a session is established, to indicate that a PPPoE session has been terminated. The packet can be sent by the host or the AC. The DESTINATION_ADDR eld is a unicast Ethernet address.
PPPoE Discovery and Session Negotiation

The Cisco 827 router provides an excellent illustration of PPPoE negotiations. The output from the router is shown in Example 21-23. For this example, IOS v12.2(2)XH is used and the following debug commands are activated:
Dial-on-demand events ATM events Virtual private dialup network (VPDN) events PPPoE protocol PPP packet
Example 21-23 shows the output as a result of debugging the dialer events, ATM events, VPDN events, PPPoE events, and PPP packets for a Cisco 827 router.
Example 21-23 Output from a Cisco 827 Router Showing Successful PPPoE Discovery Stage Negotiation
VPN-dsl#show debug Dial on demand: Dial on demand events debugging is on Generic ATM: ATM events debugging is on VPN: VPDN events debugging is on PPPoE protocol events debugging is on PPP: PPP packet display debugging is on *Oct 18 16:02:18 PST: Sending PADI: vc=0/35 ! The router sends its PAD initiation (PADI). *Oct 18 16:02:18 PST: padi timer expired *Oct 18 16:02:18 PST: PPPoE 0: I PADO L:0004.27fd.970e R:0010.6700.b5a0 0/35 AT0 ! The router receives the LAC response with the PAD offer (PADO), ! with L: and R: over vc/vp 0/35 ATM0. ! I indicates input, L for local, and R is remote. ! The number strings following these letters are MAC addresses of ! the respective host.
737
Example 21-23 Output from a Cisco 827 Router Showing Successful PPPoE Discovery Stage Negotiation (Continued)
*Oct 18 16:02:20 PST: PPPOE: weve got our pado and the pado timer went off *Oct 18 16:02:20 PST: OUT PADR from PPPoE tunnel ! The router sends PAD request (PADR) out. *Oct 18 16:02:20 PST: PPPoE 4922: I PADS L:0004.27fd.970e R:0010.6700.b5a0 0/35 AT0 *Oct 18 16:02:20 PST: IN PADS from PPPoE tunnel ! The router receives the PAD session confirmation (PADS). ! The discovery stage is done. *Oct 18 16:02:20 PST: %DIALER-6-BIND: Interface Vi1 bound to profile Di1 ! The virtual interface is created and referred to as Vix ! (in this example, replace x with 1). ! It bonds to the dialer interface to start the PPP Session stage. *Oct 18 16:02:20 PST: PPPoE: Virtual Access interface obtained.
At this point, the router and AC complete the PPPoE discovery stage. If you enter the command show ip interface brief, you see that a virtual-interface has been established, as shown in Example 21-24.
Example 21-24 IP Interface Status After PPPoE Discovery Stage
VPN-dsl#show ip interface brief Interface IP-Address ATM0 unassigned Dialer1 unassigned Ethernet0 10.10.10.1 Virtual-Access1 unassigned OK? YES YES YES YES Method NVRAM NVRAM NVRAM unset Status up up up up Protocol up up down up
If, for some reason, the router cannot successfully negotiate the rst steps in the discovery stage, you might see output similar to that shown in Example 21-25.
Example 21-25 Output from a Cisco 827 Router for a PPPoE Session Negotiation with a Failed Result
*Oct *Oct *Oct *Oct *Oct *Oct *Oct *Oct *Oct 18 18 18 18 18 18 18 18 18 16:04:38 16:04:38 16:04:38 16:04:40 16:04:40 16:04:40 16:04:42 16:04:42 16:04:42 PST: PST: PST: PST: PST: PST: PST: PST: PST: Sending PADI: vc=0/35 pppoe_send_padi failed padi timer expired Sending PADI: vc=0/35 pppoe_send_padi failed padi timer expired Sending PADI: vc=0/35 pppoe_send_padi failed padi timer expired
Next, you can see the output for the successful negotiation of the PPPoE session stage parameters, as shown in Example 21-26. At this point, the virtual interface is now assigned an IP address, as shown in Example 21-27, and data transfer can be started.
738
Example 21-26 Output from a Cisco 827 Router for Successful PPPoE Negotiation
*Oct *Oct *Oct *Oct 18 16:02:20 PST: Vi1 VPDN: Bind interface direction=2 18 16:02:20 PST: Vi1 LCP: O CONFREQ [Closed] id 1 len 10 18 16:02:20 PST: Vi1 LCP: MagicNumber 0x042A23C5 (0x0506042A23C5) 18 16:02:20 PST: %LINK-3-UPDOWN: Interface Virtual-Access1, changed state to up *Oct 18 16:02:20 PST: Vi1 DDR: Dialer statechange to up *Oct 18 16:02:20 PST: Vi1 PPP: I pkt type 0xC021, datagramsize 20 *Oct 18 16:02:20 PST: Vi1 PPP: I pkt type 0xC021, datagramsize 12 *Oct 18 16:02:20 PST: Vi1 LCP: I CONFREQ [REQsent] id 241 len 18 *Oct 18 16:02:20 PST: Vi1 LCP: MRU 1492 (0x010405D4) *Oct 18 16:02:20 PST: Vi1 LCP: AuthProto PAP (0x0304C023) *Oct 18 16:02:20 PST: Vi1 LCP: MagicNumber 0x02511B20 (0x050602511B20) *Oct 18 16:02:20 PST: Vi1 LCP: O CONFNAK [REQsent] id 241 len 8 ! The CPE refuses *Oct 18 16:02:20 PST: Vi1 LCP: MRU 1500 (0x010405DC) *Oct 18 16:02:20 PST: Vi1 LCP: I CONFACK [REQsent] id 1 len 10 *Oct 18 16:02:20 PST: Vi1 LCP: MagicNumber 0x042A23C5 (0x0506042A23C5) *Oct 18 16:02:20 PST: Vi1 PPP: I pkt type 0xC021, datagramsize 20 *Oct 18 16:02:20 PST: Vi1 LCP: I CONFREQ [ACKrcvd] id 242 len 18 *Oct 18 16:02:20 PST: Vi1 LCP: MRU 1492 (0x010405D4) *Oct 18 16:02:20 PST: Vi1 LCP: AuthProto PAP (0x0304C023) *Oct 18 16:02:20 PST: Vi1 LCP: MagicNumber 0x02511B20 (0x050602511B20) *Oct 18 16:02:20 PST: Vi1 LCP: O CONFNAK [ACKrcvd] id 242 len 8 ! CPE refuses again *Oct 18 16:02:20 PST: Vi1 LCP: MRU 1500 (0x010405DC) *Oct 18 16:02:20 PST: Vi1 PPP: I pkt type 0xC021, datagramsize 20 ! Finally, the CPE agrees. *Oct 18 16:02:20 PST: Vi1 PPP: I pkt type 0xC021, datagramsize 16 *Oct 18 16:02:20 PST: Vi1 LCP: I CONFREQ [ACKrcvd] id 247 len 14 *Oct 18 16:02:20 PST: Vi1 LCP: AuthProto PAP (0x0304C023) *Oct 18 16:02:20 PST: Vi1 LCP: MagicNumber 0x02511B20 (0x050602511B20) *Oct 18 16:02:20 PST: Vi1 LCP: O CONFACK [ACKrcvd] id 247 len 14 *Oct 18 16:02:20 PST: Vi1 LCP: AuthProto PAP (0x0304C023) *Oct 18 16:02:20 PST: Vi1 LCP: MagicNumber 0x02511B20 (0x050602511B20) *Oct 18 16:02:20 PST: Vi1 PAP: O AUTH-REQ id 1 len 40 from VPN-dsl@xyz.net ! CPE starts the AUTH process with a request. *Oct 18 16:02:22 PST: Vi1 PPP: I pkt type 0xC023, datagramsize 7 *Oct 18 16:02:22 PST: Vi1 PPP: I pkt type 0xC021, datagramsize 10 *Oct 18 16:02:22 PST: Vi1 LCP: I ECHOREQ [Open] id 0 len 8 magic 0x02511B20 *Oct 18 16:02:22 PST: Vi1 LCP: O ECHOREP [Open] id 0 len 8 magic 0x042A23C5 *Oct 18 16:02:22 PST: Vi1 PPP: I pkt type 0x8021, datagramsize 12 *Oct 18 16:02:22 PST: Vi1 PAP: I AUTH-ACK id 1 len 5 ! Access Concentrator agrees on PAP AUTH. *Oct 18 16:02:22 PST: Vi1 IPCP: I CONFREQ [Closed] id 241 len 10 *Oct 18 16:02:22 PST: Vi1 IPCP: Address 64.175.247.254 (0x030640AFF7FE) *Oct 18 16:02:22 PST: Vi1 IPCP: O CONFREQ [Closed] id 1 len 22 *Oct 18 16:02:22 PST: Vi1 IPCP: Address 0.0.0.0 (0x030600000000) *Oct 18 16:02:22 PST: Vi1 IPCP: PrimaryDNS 0.0.0.0 (0x810600000000) *Oct 18 16:02:22 PST: Vi1 IPCP: SecondaryDNS 0.0.0.0 (0x830600000000) *Oct 18 16:02:22 PST: Vi1 PPP: I pkt type 0x8021, datagramsize 24 *Oct 18 16:02:22 PST: Vi1 IPCP: I CONFNAK [REQsent] id 1 len 22 *Oct 18 16:02:22 PST: Vi1 IPCP: Address 64.175.245.47 (0x030640AFF52F)
739
Example 21-26 Output from a Cisco 827 Router for Successful PPPoE Negotiation (Continued)
*Oct *Oct *Oct *Oct *Oct *Oct *Oct *Oct *Oct *Oct *Oct *Oct 18 16:02:22 PST: Vi1 IPCP: PrimaryDNS 63.203.35.55 (0x81063FCB2337) 18 16:02:22 PST: Vi1 IPCP: SecondaryDNS 206.13.28.12 (0x8306CE0D1C0C) 18 16:02:22 PST: Vi1 IPCP: O CONFREQ [REQsent] id 2 len 22 18 16:02:22 PST: Vi1 IPCP: Address 64.175.245.47 (0x030640AFF52F) 18 16:02:22 PST: Vi1 IPCP: PrimaryDNS 63.203.35.55 (0x81063FCB2337) 18 16:02:22 PST: Vi1 IPCP: SecondaryDNS 206.13.28.12 (0x8306CE0D1C0C) 18 16:02:22 PST: Vi1 PPP: I pkt type 0x8021, datagramsize 24 18 16:02:22 PST: Vi1 IPCP: I CONFACK [REQsent] id 2 len 22 18 16:02:22 PST: Vi1 IPCP: Address 64.175.245.47 (0x030640AFF52F) 18 16:02:22 PST: Vi1 IPCP: PrimaryDNS 63.203.35.55 (0x81063FCB2337) 18 16:02:22 PST: Vi1 IPCP: SecondaryDNS 206.13.28.12 (0x8306CE0D1C0C) 18 16:02:23 PST: %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access1, changed state to up ! Virtual interface protocol is up and it is in the IPCP phase. *Oct 18 16:02:24 PST: Vi1 IPCP: TIMEout: State ACKrcvd *Oct 18 16:02:24 PST: Vi1 IPCP: O CONFREQ [ACKrcvd] id 3 len 22 *Oct 18 16:02:24 PST: Vi1 IPCP: Address 64.175.245.47 (0x030640AFF52F) *Oct 18 16:02:24 PST: Vi1 IPCP: PrimaryDNS 63.203.35.55 (0x81063FCB2337) *Oct 18 16:02:24 PST: Vi1 IPCP: SecondaryDNS 206.13.28.12 (0x8306CE0D1C0C) *Oct 18 16:02:24 PST: Vi1 PPP: I pkt type 0x8021, datagramsize 24 *Oct 18 16:02:24 PST: Vi1 IPCP: I CONFACK [REQsent] id 3 len 22 ! The IP address 64.175.245.47 is assigned to Dialer 1 *Oct 18 16:02:24 PST: Vi1 IPCP: Address 64.175.245.47 (0x030640AFF52F) *Oct 18 16:02:24 PST: Vi1 IPCP: PrimaryDNS 63.203.35.55 (0x81063FCB2337) *Oct 18 16:02:24 PST: Vi1 IPCP: SecondaryDNS 206.13.28.12 (0x8306CE0D1C0C) *Oct 18 16:02:25 PST: Vi1 PPP: I pkt type 0x8021, datagramsize 12 *Oct 18 16:02:25 PST: Vi1 IPCP: I CONFREQ [ACKrcvd] id 241 len 10 *Oct 18 16:02:25 PST: Vi1 IPCP: Address 64.175.247.254 (0x030640AFF7FE) *Oct 18 16:02:25 PST: Vi1 IPCP: O CONFACK [ACKrcvd] id 241 len 10 *Oct 18 16:02:25 PST: Vi1 IPCP: Address 64.175.247.254 (0x030640AFF7FE) *Oct 18 16:02:25 PST: Vi1 DDR: dialer protocol up *Oct 18 16:02:25 PST: Vi1 PPP: I pkt type 0xC021, datagramsize 10
Example 21-27 IP Interface Status after Completing PPPoE Session Stage Negotiation
VPN-dsl#sh ip int brie Interface IP-Address ATM0 unassigned Dialer1 64.175.245.47 Ethernet0 10.10.10.1 Virtual-Access1 unassigned OK? YES YES YES YES Method NVRAM IPCP NVRAM unset Status up up up up Protocol up up down up
Common Issues for Remote Access VPNs with PPPoE on ADSL

Two of the more common issues that ADSL PPPoE clients encounter are authentication into the providers network, and the MTU of the PPPoE adapter. Clients can choose to use a router or a SW application on their host to negotiate both the authentication and MTU parameters. In almost all cases, the remote access device must be congured to provide a PPPoE username and password to authenticate with the providers authentication server. If the client or router cannot negotiate an IP address with the provider, conrm that the PPPoE
740
username and password are correct. If they are correct and you still cannot obtain an IP address, verify the network infrastructure at home. If using a router to negotiate authentication, switch to a host and use one of the SW PPPoE adapters. If you still cannot negotiate an address, you might have to work with the provider to verify that the service is operational and that you have the correct authentication parameters. In Chapter 22, Remote AccessVPN Troubleshooting Scenarios, a scenario is presented that shows the steps required to change the MTU on some SW PPPoE adapters. Some routers, such as the Cisco827, also provide this feature.
VPN and Internet Access Through a Cable TV Infrastructure

In the last few years, Multiple Service Operators (MSOs) have been upgrading their networks and installing high-speed data communication systems that operate over the cable television (CATV) system to provide Internet broadband connectivity to subscribers. These systems effectively provide a data communications path that is transparent to IP over the last portion of their network. However, exchanging TCP/IP information over the Internet through a CATV network presents it own unique issues and challenges to remote access VPNs, which are addressed in the next section. Subsequent sections related to this topic cover the following:
Overview of data transmission over a CATV network Cable modems and infrastructure Standards for data transmission over cable, and common issues for remote access VPNs over CATV data networks
Overview of Data Transmission over a CATV Network

CATV networks were originally designed and used for one-way distribution of analog television signals, from the operator to the subscriber. Under this conguration, a substantial amount of bandwidth on the CATV infrastructure was unused. By upgrading a portion of the CATV system to ber optics, it is usually possible to enable signal ow in both directions. Most CATV networks that support two-way data distribution are hybrid ber-coaxial (HFC) networks. The signals run in ber-optic cables from the headend center, to node locations near the subscriber. From these nodes, the signal is converted from ber to coaxial cables that run to the subscribers premises. Higher frequencies ow toward the subscriber, and the lower frequencies travel in the opposite direction.
Cable Modems and Cable Infrastructure

The term cable modem refers to a modem that operates over ordinary CATV networks. Basically, the subscriber connects the cable modem to the outlet for the TV, and the MSO or CATV operator
741
connects a cable modem termination system (CMTS) at their end, commonly known as the headend, as shown in Figure 21-10. The CMTS supports the data exchange. Normally, a single channel on a CMTS supports approximately 2000 simultaneous cable modem users. If more cable modems are required, additional channels must be added to the CMTS.
Figure 21-10 High-Level Graphical Representation of a CMTS and Cable Modem Architecture
Cable Modem Termination System (CMTS) Headend
Cisco uBR900 Series Cable Access Router Cable Modem Cable Modem Cable Modem Cable Modem Cable Modem
Almost all cable modems are standalone units with Ethernet interfaces; however, some are available that can be installed internally in a host, or that provide a USB port. The term cable modem is somewhat misleading, as you recall experiences with analog or ISDN modems. A cable modem provides a LAN interface and behaves similarly to other network devices. However, cable modems do display some operating characteristics that are similar to traditional modems. Normal operating ranges can be over 100 km, and the typical data throughput of most modems is 3 to 50 Mbps. The modems can act either as MAC layer bridges or as routers. Major differences between analog and ISDN modems are the online status and speed. Cable modems are online whenever they are powered-up and connected to the cable plant. Cable modems are much faster than conventional telephony modems, which are capable of speeds 25 to 1000 times faster. Remember that this is the speed the subscriber experiences between the modem and the operators CMTS. Actual performance for a host browsing the web varies based on a number of factors with varying levels of inuence. Some of the more common dependencies include the number of cable modems on the segment, the speed of the connection between the operators network and the Internet, and the deployment and effectiveness of proxy cache servers.
Standards for Data Transmission over Cable

Unfortunately, there is no one industry-wide standard that covers the transmission of data over cable networks. In North America, the Data-Over-Cable Service Interface Specications (DOCSIS) addresses cable modems and CMTS. DOCSIS was initiated by a consortium of MSOs and has the support of major cable modem manufacturers and network operators. There is an ongoing battle in Europe between the initial DVB/DAVIC and EuroDOCSIS standards. For the purposes of brevity, the DOCSIS standard is discussed in more detail, and any differences between it and the EuroDOCSIS or DVB/DAVIC standards are noted.
742
The new DOCSIS 1.1 specication is built upon DOCSIS 1.0 (www.cablemodem.com), but differs from it with the following features:
Quality of service (QoS) Dynamic services Concatenation Fragmentation Payload header suppression IP multicast Cable modem authentication SNMPv3 View-based access control and management (VACM) Cable modem account management Fault management Secure software availability
The emerging DOCSIS 2.0 (in development since late 1998) delivers all the capabilities of DOCSIS 1.1, and by providing greater resilience to noise, DOCSIS 2.0 provides more reliable and efcient service delivery. DOCSIS 2.0 is not only compatible with previous versions of DOCSIS, but allows improved performance of 1.0 and 1.1 modems when DOCSIS 2.0 modems and CMTSs are deployed on the network. DOCSIS 2.0 adds throughput in the upstream portion of the cable plantfrom the consumer out to the Internetwhich creates a network that has 30Mbps capacity in two directions. That tripling of data capacity enables services such as videoconferencing and peer-to-peer applications. DOCSIS 2.0 enables operators to create new services for both home and business use, including symmetrical and critical applications. The modulation techniques for DOCSIS 2.0 include synchronous code division multiple access (SCDMA) and advanced frequency agile time division multiple access (A-TDMA). Further discussion about VPN over cable is based on the most commonly deployed solutions todayDOCSIS 1.0.
Cable System Architectural Elements

The cable modem typically is connected to a two-way cable RF path over a low-split HFC cable system. In the downstream direction, the cable modem receives signals in a predened portion of the downstream passband, usually between 50 MHz and a systemdependent upper limit that can be 750 MHz or more. In the upstream direction, or away from the subscriber, the cable modem transmits signals in a predened portion of the upstream passband, which is between 5 and 42 MHz. Similar to an Ethernet segment, data sent downstream from the CMTS is received by all cable modems on the CMTS channel segment. However, the various data over cable
743
implementations are signicantly more efcient with their bandwidth than Ethernet. Intended recipients can be one, some, or all cable modems on the segment.
DOCSIS Characteristics
The Open System Interconnection (OSI) model for the operator interface of a DOCSIS cable modem is shown in Figure 21-11.
Figure 21-11 The OSI Model as Applied to the DOCSIS Industry Standard
OSI Layer
Higher Layers Transport Layer Network Layer Data Layer Physical Applications TCP/UDP IP
DOCSIS DOCSIS Control Messages 802.2 Downstream Minislots MPEG-TS Basic Time Slot Unit Used for Bursts Continuous Stream of Data of Data Transmission Transmitted Upstream
Physical characteristics of the downstream data are listed in Table 21-10.

Table 21-10 Downstream DOCSIS Data Transmission Characteristics Physical Parameters Frequency Bandwidth Modulation Downstream Data Characteristics 54850 MHz (USA) and 65850 MHz (EU) 6 MHz (USA) and 8 MHz (EU) 64-quadrature amplitude modulation (QAM) with 6 bits per symbol (normal) 256-QAM with 8 bits per symbol (faster, but more sensitive to noise) Speed Nature of Data 2756 Mbps Continuous stream
Physical characteristics of the upstream data are listed in Table 21-11.

Table 21-11 Upstream DOCSIS Data Transmission Characteristics Physical Parameters Frequency Bandwidth Modulation Speed Nature of data Upstream Data Characteristics 542 MHz 2 MHz Quadrature phase-shift keying (QPSK) or 16-QAM 3 Mbps Bursts (Variable-length burst: US) (Fixed-length burst: EU)
744
NOTE
In Figures 21-9 and 21-10, there is 12 Mhz between the upstream and the downstream bands. This band is known as the guard band. One downstream channel is normally paired with a number of upstream channels to achieve the balance in required bandwidth. Each modem transmits bursts in time slots that are marked as reserved, contention, or ranging by the CMTS per a vendor-specic algorithm. Characteristics of the CMTS timeslots are highlighted in Table 21-12.
Table 21-12 Characteristics of CMTS Timeslots Time Slot Reserved Contention Ranging Description Set aside for a specic modem. Usually for longer transmissions. Open to all modems. If collision detected, modems resend after random interval. Usually for short transmissions. Adjusts transmission power level and clock of cable modem.
Common Issues for Remote Access VPNs over CATV Data Networks
There are a limited number of issues to troubleshoot when running VPN over CATV data networks. Two common situations you might encounter when working on remote access VPNs, using the Cisco VPN Unity client over CATV networks, are two-way Internet connections and heartbeats that monitor the CPE.
Two-Way Internet Connections

Two-way Internet connections can be implemented by using either an analog modem integrated in the cable modem (a telephone return cable modem), or a modem on the PC host. In the latter conguration, you normally cannot pass data over a VPN IPSec tunnel. This is because the Ethernet and dial interfaces on the PC have different IP addresses, and to successfully pass data with the Cisco VPN 3000 concentrator, the client must present one address. The former conguration, with the analog modem integrated into the cable modem, allows a Cisco VPN Unity client to pass data over the IPSec connection because the client is aware of only one routable address from the cable modem.
Heartbeats
Most clients that are attached to CATV Internet connections obtain their routable IP address from the operator through DHCP. Some operators then monitor the status of the CPE device that obtained the IP address through the use of a regular ping. If the CPE device fails to respond to the pings after a predetermined time interval, the operator assumes that the CPE
745
device is no longer connected to the operators network, and returns the IP address to the DHCP pool. If the CPE device that obtains the IP address is the host that terminates the VPN tunnel, and if split tunneling is not enabled, the CPE does not respond to the pings sent from the operator to the public IP address. The reason for non-response is because the CPE device is assigned an IP address from the concentrator for the duration that the IPSec VPN tunnel is active, and it only responds to IP trafc that is received over the IPSec tunnel. A workaround for this scenario is to use a router to obtain the IP address from the operator, and to congure the router to NAT the host with the VPN client. Select a concentrator and prole that supports IPSec over UDP encapsulation. The router then responds to the operators pings and you can establish and exchange data over the IPSec tunnel.
VPN and Internet Access over Satellite and Wireless Systems

Satellite and wireless-based communication systems deliver Internet connectivity to users who otherwise do not qualify for typical SOHO and residential broadband solutions, such as DSL and CATV. However, because of their inherent designs and features, IPSec VPNs face unique issues when operated over satellite and wireless solutions. In particular, you learn about the following:
Satellite and wireless systems specics Performance solutions in satellite networks IPSec VPN performance issues over satellite systems
Satellite and Wireless Systems Specics

Current Satellite (DBS) systems, such as Starband or Directway, are being deployed in greater numbers to provide Internet access. DBS systems are capable of delivering one-way downstream data rates of 23 Mbps or more; however, they do introduce error rates of 12 percent (www.internettrafcreport.com). Also, they inherently increase the latency that users experience by a minimum of several hundred milliseconds. An inherent delay occurs in the delivery of messages over a satellite link because of the nite speed of light and the altitude of communications satellites. Therefore, the propagation time for a radio signal to travel twice that distance (corresponding to a ground station directly below the satellite) is 239.6 milliseconds (ms) (see RFC 2488). The propagation delay for a message and the corresponding reply (one round-trip time [RTT]) is at least 558 ms. The RTT is not based solely on satellite propagation time; it is increased by other network factors, such as transmission time and propagation time of other links in the network path, and queuing delay in gateways that have terrestrial components. Typically, satellite RTT is 560 ms and the terrestrial side is about 150 ms; hence, the total RTT for the TCP connection is 710 ms (see the following Note). As a result, todays offering can achieve download
746
speeds in the range of 500 kbps to 1 Mbps and upload speeds approaching 128 kbps. Satellite channels are dominated by two fundamental characteristics for noise and bandwidth that are described in subsequent sections of this chapter.
NOTE
Measurements show that the error level is slightly higher. Pchar output follows from a satellite connection, demonstrating 68 percent error loss that varies between day and night, and approximately 0.8s one-way RTT:
....XXX.78.249.254 (misc-XXX-78-249-254.pool.starband.net) Partial loss: 12 / 138 (8%) Partial char: rtt = 813.546203 ms, (b = 0.189682 ms/B), r2 = 0.149781 stddev rtt = 99.374317, stddev b = 0.070578 Partial queueing: avg = 0.369341 ms (133278 bytes) Hop char: rtt = 739.066865 ms, bw = 42.346064 Kbps Hop queueing: avg = 0.362248 ms (1917 bytes)
The text discusses each of the following issues in detail in the subsequent sections:
Noise Bandwidth VPN, TCP, and TCP inefciency over satellite and wireless systems TCP characteristics that impact performance
Noise and Satellite and Wireless Systems

The strength of a radio signal falls in proportion to the square of the distance traveled. For a satellite link, the distance is great and the signal weakens before reaching its destination. This results in a low signal-to-noise ratio (SNR) and increased error rate. Typical error control coding, such as Reed Solomon, can be added to existing satellite services and is currently being used by many other services.
Bandwidth and Satellite and Wireless Systems

The radio spectrum is controlled by licenses and the typical carrier frequencies for current, point-to-point, commercial, satellite services are 6 GHz (uplink) and 4 GHz (downlink), also known as C band, and 14/12 GHz (Ku band). From the point of view of VPN over wireless, existing wireless systems (see Chapter 3, The Cloud, for more details) offer a different spectrum of challenges. Wireless systems typically have higher bit error rates (BERs) than wire-based carriage systems. Mobile wireless systems also include factors such as signal fade, base-station handover, and variable levels of load. The noise and bandwidth characteristics also apply, but the most important point is the affect both
747
systems have over VPN. More information on this topic is included in the Performance Implications of Link Characteristics (PILC) Group of the Internet Engineering Task Force (IETF) through www.ietf.org/internet-drafts/draft-ietf-pilc-2.5g3g-07.txt.
VPN, TCP, and TCP Inefciency over Satellite and Wireless Systems
IPSec is an IP-based set of protocols, which interacts with the TCP/IP stack. As stated in Chapter 19, the tunnel mode of VPN essentially uses protocols, such as AH and ESP, to encapsulate the IP packets. TCP is also involved because some of the calculations and headers involve TCP headers (see Figure 21-5). A problem exists when you run VPN over high-latency networks, such as satellite and wireless, where the throughput degrades signicantly compared to VPN over wire-based technologies. What seems to be the problem? TCP was designed using wire-based assumptions that include the following:
Packet loss is the result of network congestion, rather than bit-level corruption Some level of stability in the RTT because TCP uses a method of damping down the changes in the RTT estimate A best-path route-selection protocol A network with xed bandwidth circuits, not varying bandwidth A switched network with rst-in, rst-out (FIFO) buffers Limited duration of TCP sessions Large payloads and adequate bandwidth Interaction with other TCP sessions
The full description of TCP assumptions and inefciencies are available in RFC 2488 and RFC 2760. You can also see RFC 1323. If these assumptions are challenged, the associated cost is TCP efciency. If TCP is extended to environments where these assumptions are no longer valid, preserving the integrity of the TCP transfer and maintaining a high level of efciency can require the TCP operation to be altered. Overall, because satellite and wireless channels have several characteristics that differ from most terrestrial channels, they can degrade TCP performance.
TCP Characteristics That Impact Performance

Many characteristics can impact performance:
Congestion avoidanceA fundamental assumption of TCP is that it treats all packet loss as an indication of network congestion, and it reduces transmission rates drastically until an optimal rate is found for data transmission. In satellite and wireless networks, packet loss is because of link noise or other transient conditions, rather than congestion, which results in slower data transfer.
748
Receive windowEvery TCP-source that sends data is allowed to send as many bytes as are explicitly allowed in the last packet received from the TCP-destination. Therefore, the destination conrms that it has enough space to store the bytes about to be sent, and this value is known as the Advertised Receive Window. If this value is set too low, which is common, it severely limits the top speeds of a TCP connection regardless of the access rate (link speed). The actual bandwidth can be calculated according to the RTT and the window size by using the following calculation: Max bandwidth = size of the window / RTT [bps] Three-way handshakeThe TCP three-way handshake requires three RTTs before there is any data sent, and this can take two seconds for each connection on a satellite system. Variable response timeTCP is heavily dependent on measuring the RTT between the sender and the receiver. Multiple-access satellite networks such as time-division multiplex access (TDMA) or Demand Assigned Multiple Access (DAMA)-based access systems can have variable response times, which in turn can be considered as lost packets and lead to unnecessary retransmissions. TCP acknowledgmentA signicant factor for resource inefciency is dealing with the sheer volume of ACK packets generated by TCP. This amount can be reduced by using selective ACK, but it cannot be eliminated. Excessive number of concurrent connectionsAs part of the TCP protocol suite, HTTP and HTTP/1.0 use a separate TCP connection for each object to be retrieved. Requests are not sent until after the previous object has been completely received. HTTP1.1 enables up to four parallel TCP connections, yet most browsers use only two TCP connections. The time required to download one web page can be calculated from the following: Time = RTT (#Objects / #TCP) + PageSize / Bandwidth The result of a large number of connections leads to a reduction in throughput of up to 50 percent, which is primarily because of performing slow-starts at frequent intervals and then usually terminating.
Data transmission of small segmentsRelated to the previous discussion on HTTP, this protocol and some applications can force TCP to transmit data in segment sizes smaller than the minimum allowed size, which directly results in inefciencies.
Performance Solutions in Satellite Networks

As explained, TCP was specically designed as a exible protocol that operates on various wired networks. However, it is not optimal for wireless or satellite links, and it proves to be a medium where TCP provides marginal service. Because latency is a constant concern of enterprise VPNs, but enterprise VPNs are not the main concern of satellite providers, the
749
only viable option is to increase the throughput, implementing proprietary solutions to improve or resolve issues introduced by using TCP over satellite networks. To help you understand the nuances of some of the implemented proprietary solutions, the discussion is further divided into the following sections:
Manipulating (tweaking) the TCP stack Boosted session transport protocol The FITFEEL transmission protocol
Manipulating (Tweaking) the TCP Stack

One possible solution to improve performance is explained in Chapter 3, and is based on the Internet Page Accelerator (IPA), which allows increased numbers of concurrent HTTP 1.0 and 1.1 sessions. Another possible solution is tweaking the TCP protocol. Some aspects of this approach are described in RFC 2488. The suggested summary of the recommendations is shown in Table 21-13. FEC stands for forward error correction, PAWS stands for Protection Against Wrapped Sequence Space, and RTTM is Round-Trip Time Measurements.
NOTE
Cisco IOS version 12.2+ allows some functions to be performed on the routers TCP trafc, such as ip tcp timestamp or debug ip tcp sack. RFC 1323 timestamps help TCP to measure RTT accurately to adjust retransmission timeouts. By default, they are disabled in Windows and are considered ineffective. The ip tcp timestamp works with another technique called window scaling, which permits TCP to negotiate a scaling factor for the TCP receive window size. It permits a large TCP receive window of up to 1 GB. This option must be enabled if you want to use receive windows larger than 64 KB. Window scaling is enabled by default in Windows.
Table 21-13 Recommended Tweaking Mechanisms Mechanism Path-MTU Discovery FEC TCP Congestion Control Slow Start Congestion Avoidance Fast Retransmit Fast Recovery Required Required Recommended Recommended Sender Sender Sender Sender continues Use Recommended Recommended Where Sender Satellite Link
750
Table 21-13 Recommended Tweaking Mechanisms (Continued) Mechanism TCP Large Windows Window Scaling PAWS RTTM TCP Selective Acknowledgments (SACKs) Recommended Recommended Recommended Recommended Sender, Receiver Sender, Receiver Sender, Receiver Sender, Receiver Use Where
Numerous software solutions exist on the market, such as TweakMaster of Hagel Technologies, DrTCP, and others. The effect of these measures is moderate, and there is some reasonable improvement to the responsiveness of applications, even when running VPN, but tweaking techniques dont offer radical solutions for the degradation of speed when it comes to using VPN over wireless or satellite. Why? Because when it comes to an overall solution, according to Table 21-13, in some cases both ends, not only the sender, must perform some procedures. In the default TCP stack installations, this is denitely not the case.
Boosted Session Transport Protocol

One example of a different approach to TCP, related to performance issues, is the implementation of the Boosted Session Transport (BST) protocol (see www.ashnetworks.com/). BST is a connection-oriented protocol used instead of TCP on satellite or wireless segments. TCP trafc is converted to BST ows before being sent across the wireless WAN links, and then is converted back to TCP before being sent to the intended destination, as shown in Figure 21-12. BST is available in the NettGain product line from Flash Networks, and has been implemented in satellite networks by StarBand, NASA, SAT-TEL, and VSAT. The BST protocol offers numerous enhancements over TCP:
Pretuned parameters Immediate transmission at full speed Smart congestion avoidance Intelligent bandwidth allocation Smart rate control Intelligent acknowledgments Unlimited window size No three-way handshake Packet loss recovery
751
Figure 21-12 The BST Mechanism
Client
Protocol Translator
TCP/BST
Protocol Translator
Client
TCP
TCP
BST
BST
TCP
TCP
IP
IP
IP
IP
IP
IP
Data Link (Driver)
Data Link (Driver)
Data Link (Driver)
Data Link (Driver)
Data Link (Driver)
Data Link (Driver)
Physical
Physical
Physical
Physical
Physical
Physical
Satellite Network
Standard TCP/IP Standard TCP/IP
The FITFEEL Transmission Protocol

Another solution to the TCP performance problem was introduced by the authors of the Fast Information Transfer For Extremely Errored Links (FITFEEL) protocol, which introduces a simple transmission protocol that performs better than TCP over bad links. The basic assumption of using the TCP proxy concept is that TCP applications can be used effectively on poor links without alteration. This is accomplished by translating TCP to a better protocol over the problematic links, then translating back to TCP at the other end. The FITFEEL addresses aspects of TCP action when there is either a propagation delay, bit error, queuing delay, or buffer overow. The TCP proxy concept is referred to as TCP boomerangs, and the boomerang effect is achieved with proxy software that talks TCP language to the initiating host in the role of the destination host, and so forth. Using this approach, the TCP boomerang trick reects outgoing TCP packet streams to an IP host, which simply and reliably handles the TCP protocol by acting in the role of a proxy.
IPSec VPN Performance Issues over Satellite Systems

Both BST and FITFEEL protocols implement a proprietary form of compression. Given the fact that there is always a transformation of the TCP stack either to the BST stack, or to a
752
proxy TCP, IPSec-based solutions experience signicant degradation of the overall throughput. VPN performance over satellite systems can be disappointing, often limited to dialup speeds. However, a user can make some adjustments to their W2K host to improve performance, but it is signicantly lower than the download speeds that users expect when not using VPN. It all depends on the perspective: either the IPSec VPN shows a signicant degradation in throughput, or the IPSec VPN cannot take advantage of the boosting protocol mechanisms. Using trafc boosting protocols does not affect any of the transport layer security protocols, such as Secure Sockets Layer (SSL) or Transport Layer Security (TLS). This is because they do not modify the contents of the TCP payload. It is not known if boosting protocols pose any potential security risk to Layer 2 protocols, such as PPP, because it does not modify the IP information. On the other hand, they do replace the TCP headers with a new header over the wireless/ satellite hop. As a result, potential security issues exist with IPSec because AH and ESP use the Integrity Check Value (ICV) for calculating much of the TCP header information.
NOTE
The Satellite Service Providers use two main strategies when it comes to erroneous packets: They either request repeat, apply error correction, or use both. The author experiments and measurements with Cisco VPNs over satellite show that Concatenated Viterbi and Reed Solomon error-correction codes, used by Spacenet, allow the users to achieve better performance. See www.spacenet.com/ for details.
Possible resolutions include the following:
Managing two secure and interrelated links, one for the wireless/satellite hop and another over TCP. Using a providers software, allowing non-boosted trafc to pass and using proprietary methods for boosting and compression Transforming the existing trafc to UDP or TCP using extra encapsulation. The most promising solution is creating an IOS-based boosting engine, which can provide an end-to-end VPN over satellite solution for satellite Internet providers.
Information about the interaction of the FITFEEL protocol with IPSec-based VPN solutions was not available at the time this book was written; however, possible solutions are under study. Some of the issues are addressed in the VPN client versions 3.5.x and higher (NAT/UDP and NAT/TCP encapsulations and transparent tunneling), and some of them might become available with the newest Cisco content engines (CTE 1400 and COE 590). Check www.cisco.com regularly for updates. Another approach to this problem is checking if the satellite providers move to another coding technique where they dont need to boost the trafc. One possible solution in this
LAN and General Networking Issues Affecting Remote Access VPNs
753
direction is the emerging Ku-band technology, which essentially uses DOCSIS 1.1 for wireless broadband services. DOCSIS 1.1-based systems are expected to use Ku-band wireless broadband services with expected rates up to 10 Mbps and transmission rates up to 500 kbps. No known issues exist with IPSec-based VPNs and the DOCSIS 1.1 specication.

Three LAN related issues are known to affect remote access VPNs: the improper conguration of a NAT device, availability of necessary rewall holes, and the method a NAT device uses to manipulate multiple VPN clients. Conguration of the NAT device is beyond the scope of this discussion. However, if the device is a Cisco product, you can consult www.cisco.com for the conguration commands, examples, and SW versions. The need for necessary rewall holes to be available was previously discussed. Another alternative is to implement TCP encapsulation on well-known ports. Finally, the third case described for the handling of multiple VPN clients connected behind a NAT device warrants further coverage.
Multiple VPN Clients Behind a NAT Device

Depending on the NAT device used, you can establish multiple remote access IPSec VPN connections to the same concentrator or different concentrators. Other times, you might observe that a single client can establish an IPSec VPN connection to a concentrator, but this client is disconnected if a second client establishes a connection to the same concentrator. In an environment that uses a different NAT device, you observe that you can have multiple IPSec client connections to the same concentrator. The explanations for the different observations are provided now. First, a NAT device in a PAT environment overloads private IP addresses on a single public IP address. To differentiate the trafc destined for each host on the private network, a unique TCP or UDP port is assigned to the private IP address. The NAT device handles all communication with public networks by using its single public IP address, and correctly distributes trafc destined for devices on the private network based on the unique TCP or UDP port assignment. However, when implementing IKE-based VPNs, several manufacturers misinterpreted the ISAKMP specication. These vendors incorrectly designed their products so that the UDP source port of an ISAKMP exchange must be 500. As a result, instead of the traditional NAT, vendors had to identify the different devices on the private network with IKE-based VPN connections by using the SPI as the identier. The VPN 3000 concentrators allow multiple ISAKMP connections from the same IP address, if the source port of each of the ISAKMP streams is different. If you use a Cisco 806 IOS-based NAT device, you already
754
know that the source port behavior is congurable. For other NAT devices, it is recommended that you contact the manufacturers of the equipment to learn their specic capabilities and support plans.
MTUA Critical Factor for Troubleshooting Internet IPSec Connectivity

The MTU, the largest possible size of a network Layer 2 payload or Layer 3 packet, is not constant throughout the Internet. It is the source of many issues for IPSec tunnels. Also, the Path MTU (PMTU) feature of the VPN client might not function if your concentrator is behind a rewall that does not permit Internet Control Message Protocol (ICMP) pings from the Internet. As a result, you need to identify and resolve issues related to the MTU with regards to IPSec communications. Basically, any intermediary IP routers that are encountered on the Internet (hops), which are set to an MTU less than 1500, often fragment packets, which divides them into smaller units before sending them out the respective interface. In an IPSec tunnel, the VPN client and concentrator are the only parties that can change the size of the packets that they exchange. Any attempt to change the packet content and size being sent in an IPSec tunnel by another router or device causes the IPSec connection to fail because the MTU requirements set by the originator of the packets, either client or concentrator, were not met (see the immutable elds concept in Chapter 19). The MTU is normally set in conjunction with the maximum segment size (MSS) and the TCP Receive Window (RWIN). MSS is the largest segment of TCP data that the Microsoft Winsock is prepared to receive on a connection. MSS must be smaller than the MTU by at least 40 bytes, which accommodates the IP and TCP headers that are each 20 bytes. RWIN determines how much data the receiving computer is prepared to receive. If RWIN is set too large, it results in greater loss of data if a packet is lost or damaged. If it is set too small, transmission is slow. Normally, RWIN is set to be four, six, or eight times the MSS (see TCP Windows scale option in RFC 1323). Practical examples in which the MTU is greater or equal to MSS+40 bytes is demonstrated by the following default IOS setting examples, for 8xx series routers running Cisco IOS ver.12.2+:
Under the E0 interfaceip tcp adjust-mss 1452 Under the D1 and E1 (806 router) interfacesip mtu 1492
However, it is far more common to set the MTU for all trafc passing through an interface. Some common MTU settings include the following: MTU of Ethernet interfaces is usually set to 1500 bytes, which is the maximum payload size of an Ethernet frame (see Figure 21-13). MTU of a PPPoE frame is usually set to 1492, because the PPP header is 8 octets: Flag1 octet, Address1 octet, Control1 octet, Protocol ID2 octets, FSC2-4 bytes, and Flag1 octet (see Chapter 5, Dial Technology Background).
755
MTU of frames over dialup connections is usually set to 576 octets, which is the default setting by Microsoft and is based on the average size of Internet packets. When using a cable modem, MTU size is not known to cause fragmentation issues.
Figure 21-13 The Basic IEEE 802.3 MAC Data Frame Format
7 Bytes Preamble
1 Byte SOF
6 Bytes DA
6 Bytes SA
Minimum 46 Bytes, Maximum 1500 Bytes Data
4 Bytes FSC
Maximum Size 1524 Bytes
To illustrate further, the discussion is divided into the following sections:
Determining a Functional MTU Between the VPN Host and Concentrator MTUWhat Difference Does It Make?
Determining a Functional MTU Between the VPN Host and Concentrator

The MTU value that you use with the Cisco VPN client is limited by the minimum MTU value of all segments between your host, and the concentrator to which you are trying to establish an IPSec tunnel. To determine the MTU of this path, you must rst determine the path, then through a sequential process of pings with specic packet sizes, determine the minimum MTU of all the segments. In the following example, the ping utility determines a functional MTU from a client in Northern California by using AT&T Broadband Internet over cable, IP address 12.234.185.224, to www.cisco.com, IP address 198.133.219.25. At the command prompt, enter the following:
C:/>ping -f -l [packetsize] [www.cisco.com]
The elements are as follows:
f indicates dont fragment. -l indicates packetsize. packetsize is the size of the IP packet that you transmit (between 0 and 1500 octets). www.cisco.com is the URL (substitute www.cisco.com for the public address of the VPN concentrator to which you connect, or any public URL, gateway, or server).
If you exceed the minimum MTU of all the segments, the message you will most likely receive is Packet needs to be fragmented, but DF set. If you receive this message, you need to decrease the size of the packet and repeat the ping as many times as required until you receive a successful echo reply from the remote host. To extract the MTU size from this
756
information, assuming that the rst successful echo reply message is when the packetsize is set to 1300, you can examine the results of a ping to 198.133.219.33 from a host with the IP address 12.234.185.224, as shown in Example 21-28.
Example 21-28 Sniffer Capture Results from the Command
C:/>ping f l 1300 198.133.219.33 ! Performed from a Win2K host with IP=12.234.185.224. - - - - - - - - - - - - - - - - - - - - Frame 1 - - - - - - - - - - - - - - - - - - - Frame Status Source Address Dest. Address Size Rel. Time Delta Time Abs. Time Summary 1 M [12.234.185.224] [198.133.219.25] 1342 0:00:00.000 0.000.000 02/03/2002 04:17:54 PM DLC: Ethertype=0800, size=1342 bytes IP: D=[198.133.219.25] S=[12.234.185.224] LEN=1308 ID=440 ICMP: Echo DLC: ----- DLC Header ----DLC: DLC: Frame 1 arrived at 16:17:54.2930; frame size is 1342 (053E hex) bytes. DLC: Destination = Station 00301931778C DLC: Source = Station GtwCom462E8E DLC: Ethertype = 0800 (IP) DLC: IP: ----- IP Header ----IP: IP: Version = 4, header length = 20 bytes ! Indicates the IP header size is 20 bytes. IP: Type of service = 00 IP: 000. .... = routine IP: ...0 .... = normal delay IP: .... 0... = normal throughput IP: .... .0.. = normal reliability IP: .... ..0. = ECT bit - transport protocol will ignore the CE bit IP: .... ...0 = CE bit - no congestion IP: Total length = 1328 bytes ! The complete IP packet includes the IP header (20 bytes) + ! ICMP header (8 bytes) + ICMP payload (1300 bytes). IP: Identification = 440 IP: Flags = 4X IP: .1.. .... = dont fragment IP: ..0. .... = last fragment IP: Fragment offset = 0 bytes IP: Time to live = 128 seconds/hops IP: Protocol = 1 (ICMP) IP: Header checksum = 8BAB (correct) IP: Source address = [12.234.185.224] IP: Destination address = [198.133.219.25] IP: No options IP: ICMP: ----- ICMP header ----ICMP: ICMP: Type = 8 (Echo)
757
Example 21-28 Sniffer Capture Results from the Command (Continued)

ICMP: Code = 0 ICMP: Checksum = B5D2 (correct) ICMP: Identifier = 512 ICMP: Sequence number = 6400 The overall size of all previous fields in the ICMP header is 8 bytes, followed by the 1300 byte payload. ICMP: [1300 bytes of data] Indicates echo ICMP packet requests an echo reply from 198.133.219.25 with packet size 1300. ICMP: ICMP: [Normal end of ICMP header.] ICMP:
! ! ! !
! The following is the echo reply from 198.133.219.25. - - - - - - - - - - - - - - - - - - - - Frame 3 - - - - - - - - - - - - - - - - - - - Frame Status Source Address Dest. Address Size Rel. Time Delta Time Abs. Time Summary 3 [198.133.219.25] [12.234.185.224] 1342 0:00:00.018 0.018.214 02/03/2002 04:17:54 PM DLC: Ethertype=0800, size=1342 bytes IP: D=[12.234.185.224] S=[198.133.219.25] LEN=1308 ID=440 ICMP: Echo reply ! A successful reply for 1300 bytes from 198.133.219.25 ! (the largest size without fragmentation). DLC: ----- DLC Header ----DLC: DLC: Frame 3 arrived at 16:17:54.3114; frame size is 1342 (053E hex) bytes. DLC: Destination = Station GtwCom462E8E DLC: Source = Station 00301931778C DLC: Ethertype = 0800 (IP) DLC: IP: ----- IP Header ----IP: IP: Version = 4, header length = 20 bytes IP: Type of service = 00 IP: 000. .... = routine IP: ...0 .... = normal delay IP: .... 0... = normal throughput IP: .... .0.. = normal reliability IP: .... ..0. = ECT bit - transport protocol will ignore the CE bit IP: .... ...0 = CE bit - no congestion IP: Total length = 1328 bytes IP: Identification = 440 IP: Flags = 4X IP: .1.. .... = dont fragment IP: ..0. .... = last fragment IP: Fragment offset = 0 bytes IP: Time to live = 247 seconds/hops IP: Protocol = 1 (ICMP) IP: Header checksum = 14AB (correct) IP: Source address = [198.133.219.25] IP: Destination address = [12.234.185.224]
continues
758
Example 21-28 Sniffer Capture Results from the Command (Continued)

IP: No options IP: ICMP: ----- ICMP header ----ICMP: ICMP: Type = 0 (Echo reply) ICMP: Code = 0 ICMP: Checksum = BDD2 (correct) ICMP: Identifier = 512 ICMP: Sequence number = 6400 ICMP: [1300 bytes of data] ICMP: ICMP: [Normal end of ICMP header.] ICMP:
The MTU exceeds the parameter 1300 with only 20 + 8 = 28 bytes.
NOTE
The rule for setting MTU is that the largest value that does not result in the error Packet needs to be fragmented, but DF set, is your ISPs MTU less 28 bytes. This excludes the IP (20 bytes) and ICMP (8 bytes) headers.
Based on this rule and the ndings from the example, you can set the MTU size of this VPN client to 1300 + 28 = 1328 bytes. 1300 might not be the maximum MTU that allows the VPN client to establish an IPSec tunnel and pass trafc. After you determine a packet size that does not respond with a successful ping, try to ping the router one hop closer to you, which you can identify with the traceroute utility (tracert on W2K hosts). If thats not successful, try to ping the next router one hop closer, and so on until you either receive a successful response or reduce the packet size and start the ping process over again.
Effects of Packet Size on Performance

Data transfer performance is signicantly impacted by the packet size, which affects the MTU. In this section, you review how latency and throughput, two parameters that are affected by changes in MTU, affect data transfer performance. In particular, you learn about the following:
Packet size versus latency Throughput versus packet size
Packet Size Versus Latency

In this example, a data transfer over a standard ADSL line with a download speed of 600 kbps is examined using MTU packet sizes of 1500 and 576 on the same line.
759
The following formula for latency applies: Latency (per hop) = (MSS + header) 8 / speed
NOTE
MTU = MSS + (IP header + TCP header).
Using these different MTU sizes (1500 and 576), you can calculate the latency as a function of the packet size, as follows: Latency for MTU 1500 = (1460 + 40) 8 / 600,000 = 20 ms delay per hop Latency for MTU 576 = (536 + 40) 8 / 600,000 = 7.69 ms delay per hop Assuming a transfer over 10 hops, the 1500 MTU would yield 200 ms delay, while a 576 MTU would only take 76.9 ms to be downloaded. It is obvious the smaller packets will be transmitted faster. However, the amount of data transferred will be less by a factor of 1500 / 576 = 2.6 times.
Throughput Versus Packet Size

Using the same formula from the previous example, assume you need to transfer a 1 megabyte le over a T1 line: 1 megabyte = 1024 kilobytes = 1,048,576 bytes If MTU = 1500, the delay would be 20 ms per hop and the MSS = 1460. 1 megabyte / MSS = 1,048,576 bytes / 1460 = 718.2. 719 packets are required to transfer 1 megabyte. The time required to transfer 1 megabyte = 719 packets 20 ms per hop = 14.38 seconds per hop. Multiplied by 10 hops, this is 143.8 seconds. If MTU = 576, the delay would be 7.69 ms per hop and the MSS = 536. 1 megabyte / MSS = 1,048,576 bytes / 536 = 1956.3. 1957 packets are required to transfer 1 megabyte. The time required to transfer 1 megabyte = 1957 packets 7.69 ms delay per hop = 15.049 seconds per hop. If you are transferring the 1 megabyte le over the same 10 hops, it will take 150.49 seconds. The difference is because of the fact that, when using larger packets, the overhead is smaller. Every packet carries header information. Smaller packets will require a greater number of packets (more headers) to pass the same amount of data. For example, to transfer 1 megabyte with an MTU of 1500, the overhead would be 719 (packets) 40 (IP header + TCP header) = 28,760 bytes. If using an MTU of 576, the overhead would be 1957 40 = 78,280 bytes; an additional 49,520 bytes of headers are transferred for each megabyte. For the 10-hop transfer, the additional overhead will result in an extra 6.69 seconds difference in transfer time for every megabyte. This difference might be slightly larger in practice when considering TCP options such as sliding windows or TCP Receive window. Also, modern TCP/IP
760
implementations might use larger headers, such as an additional 12-byte header space for timestamps. The provided calculations are not precisely correct because they are based on the assumption that the available access rate (physical line speed) can be used entirely for data trafc. The fact is that the effective throughput depends upon the way that TCP treats the line and line characteristics, which increases and reduces the TCP window. Generally, its logical to assume that larger packets offer improved performance because of the following factors:
NetworkReduced number of headers, as shown in the preceding discussion RoutersFewer routing decisions ClientsFewer protocol processing and device interrupts
If throughput is not the ultimate goal, however, smaller packets might be more responsive because they require less time to travel throughout the network, and consequently, the probability of effects because of interference or any other factors is lower (geometric probability). This result might be preferred in some solutions, such as satellite and wireless, at the expense of throughput. The important factor here is how the error-free communication is managed. If every error requires retransmission, especially in wireless or satellite networks given the nature of these communications, the size of the window and MTU can signicantly affect the overall throughput. If the error-free strategy assumes and applies correction codes, this can affect the performance model in a different way, and it is another factor to consider when comparing two solutions.
NOTE
Experiments with the Cisco Aironet 350 series AP show that the difference between MTU 1400 and MTU 576 can be 1:0.75 in favor of 1400 MTU with an error rate under 5 percent.
Slow or Inaccessible Login to Kerberos Active Directory

Windows 2000 and Windows XP users might be unable to log in or experience unusually long times for logging into a Kerberos Active Directory. This might be the case with either Cisco VPN Unity client or on a host connected through an IPSec VPN tunnel that is started by the Cisco VPN 3002 Hardware client, Cisco Easy VPN client, or Cisco PIX Hardware client. The time to login can exceed 20 minutes.
Source of the Slow Login Is the Use of Kerberos over UDP Fragments
The source of the issue is the use of Kerberos over fragmented UDP packets, and the problem can be especially acute when connected behind a NAT/PAT device that does not handle packet refragmentation correctly.
Summary
761
ResolutionForce Kerberos to Use TCP Instead of UDP

Forcing Kerberos to use TCP instead of UDP packets eliminates this issue. On a Windows 2000 or Windows XP host, you can force Kerberos to use TCP by setting the Registry as follows:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters Value Name : MaxPacketSize Data Type : REG_DWORD Value : 1
Starting with v3.5.1c, the Cisco VPN Unity client installation package automatically changes the Registry to force Kerberos to use TCP. If you do not want to force Kerberos to use TCP when installing v3.5.1c or later versions of the client, change the VPN client installation le, oem.ini, as follows: 9
[Main] DisableKerberosOverTCP = 1
End Notes
1 Managing 2 Help
the VPN Client at www.cisco.com.
le, VPN 3000 Concentrator, v3.5.
3 www.cisco.com/univercd/cc/td/doc/product/vpn/client/rel3_5_1/351_3kcl.htm#xtocid40. 4 What 5 Cisco 6 Help
is a GINA?, Symantec Corporation, http://service4.symantec.com/SUPPORT/ pca.nsf/pfdocs/199852785735. Systems, Inc., Software Bug ID CSCdt55739.
le, VPN 3002 HW Client, v3.5.
7 www.cisco.com/warp/public/471/pix501506_vpn3k.html. 8 www.cisco.com/univercd/cc/td/doc/product/dsl_prod/gsol_dsl/dsl_arch/
gdslarch.htm#xtocid11.
9 www.cisco.com/cgi-bin/Support/Bugtool/
onebug.pl?bugid=CSCdx06180&Submit=Search.
Summary
This chapter focused on remote access VPN troubleshooting techniques. This chapter provided common troubleshooting recommendations and techniques when using the different VPN clients such as the following:
Cisco VPN Unity Software client Cisco 3002 HW client
762
Cisco Easy VPN client Cisco PIX Hardware client
By using the existing variety of broadband technologies and running remote access VPN over cable modem technology, xDSL technology and wireless and satellite technologies were another focus of this chapter. Every one of them poses different requirements and challenges when run with VPN. The provided technology details are designated to help troubleshooting engineers in their efforts. One emphasis of this chapter was to show the different phases and modes of VPN, which provide extensive outputs, using mainly Cisco IOS tools, to outline some of the otherwise hidden steps in the user VPN processes. This information some times can be invaluable when the non-known troubleshooting issue arises.
Review Questions
1 What are the rst three steps to check if the user never receives an Authenticating User
prompt during the initial dialer connection attempt in the VPN software client?
2 What is the CVPND event class and what is its purpose? 3 Name the main severity categories in the Cisco VPN concentrator? 4 In a 3002 HW VPN client, the user is authenticated but cannot pass any data. What
are two possible reasons?

5 Which severity level events are displayed by default on the VPN HW 3002 client? 6 How do you proceed if a NAT/PAT conguration already exists in the router and you
are about to congure an Easy VPN client?

7 What is the command for the Easy VPN client to reset the VPN connection? 8 What is the command for Easy VPN to check the status of the Cisco Easy VPN client
prole?
9 To verify the applied policy in Cisco Easy VPN, what command do you use? 10 In the PIX-based VPN client, how do you verify if the VPN client is active? 11 In the PIX-based VPN client, how do you check that the VPN tunnel has been
established?
12 What are two debug commands to debug the PIX-based VPN establishment of IPSec
and ISAKMP?
Review Questions
763
13 What parameters dene the PPPoE session uniquely? 14 Name the modulation techniques for the DOCSIS 2.0 standard. 15 If the TCP protocol is notied for packet loss, how does it react?
CHAPTER
22
Remote Access VPN Troubleshooting Scenarios

This chapter provides real-world scenarios faced by Ciscos internal remote access (RA) group in supporting their Virtual Private Network (VPN) infrastructure. Each scenario is followed by several possible problems or cases, and each case includes one or more solutions. The chosen cases were derived from over 4000 cases solved by the group. Cisco proudly declares that they implement all their own products in their own network. The solutions provided might not be the only ones for that particular problem; however, they are thoroughly tested and are proven to be the most successful. The scenarios are based on the Cisco VPN 3000 client version 3.0 (also called the Unity client) for Microsoft Windows. Versions of the VPN client 3.5- suport only Windows operating systems. Versions 3.5+ support operating systems other than Windows, including MAC OSX and Solaris 2.6. Also, the VPN client for Linux supports Red Hat version 6.2 Linux (Intel), or compatible libraries with glibc Version 2.1.1-6 or later, using kernel versions 2.2.12 or later. This chapter primarily focuses on the following common troubleshooting scenarios:
Initial preparation for RA VPN troubleshooting Authentication problems and their resolution Trouble passing data after successful authentication RA VPN and xDSL issues and their troubleshooting RA hardware VPN client 3002 issues and their troubleshooting Extranet VPN issues and their troubleshooting
These scenarios assist VPN users and VPN network administrators to solve current issues. In some of the following scenarios, the perspective from the user and the core environment are documented to show the troubleshooting steps that a network administrator and a user should take to solve a particular problem. Table 22-1 is a quick reference to help you get started.
766
Chapter 22: Remote Access VPN Troubleshooting Scenarios
Table 22-1
Scenario Quick Reference Table Scenario Authentication issues (involving an Internet Service Provider [ISP]) Case Details Bad group name or password Location in Chapter See Scenario 1, Case 1
Prompted multiple times for username and password Firewall software MTU set high MTU set low Problems passing data Cannot pass datause Network Address Translation (NAT) connection entry Maximum transmission unit (MTU) causing packet loss Connection keeps getting dropped Cannot browse the internal domain PPPoE Software/Hardware Point-to-Point Protocol over Ethernet (PPPoE) software issues IOS-based PPPoE issues 3002 Connection issues Extranet problems Cannot connect to the concentrator Problems connecting through company Xs rewall
See Scenario 1, Case 2 See Scenario 1, Case 3 See Scenario 1, Case 4 See Scenario 1, Case 5 See Scenario 2, Case 1
See Scenario 2, Case 2 See Scenario 2, Case 3 See Scenario 2, Case 4 See Scenario 3, Case 1 See Scenario 3, Case 2 See Scenario 4 See Scenario 5
Warming Up with Preliminary Troubleshooting Steps

Before getting started, some naming conventions must be dened when referring to specic devices. These devices are given the same host name and IP address throughout the entire chapter. The following devices are referenced as follows:
VPN concentrator Host name: vpn-concentrator IP Address: 10.0.0.1 VPN 3002 Host name: vpn-3002 Private IP Address: 10.2.2.2 Public IP Address: 66.1.1.2 Domain Name: company.com
767
VPN client IP Address: 10.3.3.3 Username: zack Firewall Host name: rewall.company.com IP Address: 65.1.1.2
There are three steps you should always take before moving on to the VPN troubleshooting scenarios. If you cannot verify that all these steps are functioning properly, you will not be able to connect with the VPN client. These steps include determining if you have an Internet connection, making sure that the VPN client is working properly, and checking or creating your proles.
Step 1: Determine if There Is an Internet Connection

When trying to initiate an IPSec tunnel with no Internet connectivity or a bad route to the concentrator, you receive one of two errors. After clicking the Connect button, you are immediately prompted with either Failed to establish a secure connection to the security gateway or Remote peer is no longer responding. The errors are shown in Figure 22-1 and Figure 22-2.
Figure 22-1 Failure to Connect to Gateway Error
768
Figure 22-2
Remote Peer No Longer Responding
If the error Failed to establish a secure connection to the gateway is received, a problem exists with the connection to the Internet. Four things could be wrong:
No physical connection to gateway device Invalid IP addresses of the VPN concentrator or your computer Domain Name System (DNS) resolution problems Firewall blocking connection
To check the physical connection of the PC to the gateway device, the rst thing you do is to make sure that the PCs network interface card (NIC) has a link light. If the left light is glowing (it is usually the left light for most NICs), it means that there is a physical connection. If it is not, make sure that the cables are properly plugged in. In some cases, the connection might require a crossover cable, instead of a straight-through cable. For a detailed explanation of RJ-45 cable types, see www.cisco.com/univercd/cc/td/doc/pcat/rj45__c1.htm. If there is a physical connection, check the status of the IP address, as listed in Table 22-2.
769
Table 22-2
Accessing DOS and IP information in Windows OS Windows 95 Windows 98 Windows NT Windows 2000 How to Access DOS Go to Start, Programs, MSDOS.exe. Go to Start, Programs, MSDOS.exe. Go to Start, Run, type cmd, and click OK. Go to Start, Run, type cmd, and click OK. How to View IP Information Go to Start, Run, and type winipcfg. Go to Start, Run, and type winipcfg. From DOS, type ipcong /all. From DOS, type ipcong /all.
Windows 95/98
Figure 22-3 is an example of winipcfg. If you click the More Info button that is circled, you receive information including DNS servers, Windows Internet Naming Service (WINS) servers, Dynamic Host Conguration Protocol (DHCP) servers, and a Media Access Control (MAC) address. The IP address 10.25.0.146 falls under RFC 1918 NAT. For more information on RFC 1918, see Chapter 10, ISDN Design Solutions.
Figure 22-3 Windows 95/98 winipcfg Output Information
The subnet mask is 255.255.255.240 or /28. The /28 indicates the number of bits allocated for the network. The default gateway is simply the rst hop that all the devices on your subnet go to when they need to access anything outside of your subnet. Lastly, the adapter address is the MAC address of the adapter that you are using.
770
Windows NT/2000 IP Information

The ipcong output from a Windows NT/2000 DOS prompt is shown in Example 22-1.
Example 22-1
Windows NT/2000 ipcong Output Information

C:\>ipconfig Windows 2000 IP Configuration Ethernet adapter Local Area Connection: Connection-specific DNS Suffix . : cisco.com IP Address. . . . . . . . . . . . . : 10.25.0.146 ! IP address falls in the RFC 1918 address range. Subnet Mask . . . . . . . . . . . : 255.255.255.240 ! Subnet mask indicates you have 14 addresses in this subnet. Default Gateway . . . . . . . . : 10.25.0.145 ! The first hop that all devices on your subnet go to first.
After you verify the physical connection and check the IP address, make sure that the PC resolves the host name of the concentrator. Open a DOS window and use the nslookup command, along with the host name of the concentrator to which you are trying to connect. If it resolves properly, it appears as follows:
C:\>nslookup www.cisco.com Server: dns-sjk.cisco.com Address: 171.68.226.120 Name: www.cisco.com Address: 198.133.219.25
If you receive the error *** dns.company.com cant nd www.cisco.com: Non-existent host/domain, it indicates that the VPN client has problems nding the concentrator. Possible causes to investigate are a bad route or a misspelling in the host name or IP address of remote server window, or a local rewall blockage. To test the route, open a DOS prompt window and try tracing to the concentrators IP address or to the companys rewall using the tracert command. You trace to your companys rewall because most rewalls are congured to block Internet Control Message Protocol (ICMP) trafc from entering the network. If ICMP trafc is blocked, you will never get a ping or tracert through to the concentrator. See the tracert in Example 22-2. When you can reach the concentrator or your companys rewall, you should be able to establish an IPSec tunnel by using the VPN client. If you do not know the IP or host name of the rewall, you can simply try to trace to the concentrator, and most likely you will reach the rewall and receive timeouts because rewalls block ICMP packets by default. The trace shows that because you can route to the company rewall, you should be able to route to the concentrator as long as the rewall is congured to allow IPSec through.
771
Because you can trace to the rewall successfully, you have proven that your PC can route to your company correctly.
Example 22-2
Tracing to Your Companys Firewall

C:\>tracert firewall.company.com Tracing route to firewall.company.com [65.1.1.2] over a maximum of 30 hops: 1 30 ms 20 ms 10 ms adsl.dsl.01.ISP.net [63.12.101.254] ! Three datagrams round-trip time 2 30 ms 40 ms 40 ms sl-bb22-sj-5-ISP.net [144.232.18.74] ! Hostname and IP of router 3 41 ms 40 ms 30 ms sl-bb20-sj-15-0.ISP.net [144.232.3.2] 4 30 ms 40 ms 40 ms sl-gw-ISP.net [144.232.3.1] 5 30 ms 40 ms 40 ms sl-company.ISP.net [144.218.1.1] 6 31 ms 40 ms 40 ms firewall.company.com [65.1.1.2] ! The firewall is reached Trace complete.
The tracert command is a simple and valuable tool. Three datagrams are sent, each with a Time To Live (TTL) eld value set to 1. The TTL value of 1 causes the datagram to timeout as soon as it hits the rst router in the path; this router then responds with an ICMP time exceeded message (TEM), which indicates that the TTL has expired. For more information on tracert and ping, see Chapter 4, Troubleshooting Approaches, Models, and Tools.
Step 2: Ensure that the VPN Client Is Properly Installed

The next step is to determine if the VPN client is working properly. To do this, check to ensure that the cvpnd.exe process has started and is currently running. You can immediately determine this if you receive the error The necessary VPN subsystem is not available, when you open the VPN dialer. To check to see if the cvpnd.exe is running in most Windows versions, simply press CtrlAlt-Delete and go to Task Manager. In Task Manager, click the Processes tab, and then click the column called Image Name to sort the process names. If the cvpnd.exe process is not running, two possible problems might have occurred:
The Cisco Systems VPN Service might be disabled in your Windows services. The cvpnd.exe driver might not have been installed properly.
The rst problem is slightly easier to remedy than the second. To enable the Cisco Systems, Inc. VPN Service in Windows NT/2000, go to Start, Control Panel, Administrative Tools, Services. Then look for the Cisco Systems. VPN Service, right-click it and select Properties. From the Properties window, change the Startup Type to automatic, and click
772
Start to start the service. If the cvpnd.exe is now listed in Task Managers processes, the VPN client should work correctly.
NOTE
The Microsoft IPSec policy agent must be disabled in services for VPN to work. The VPN installer is set up to disable it, but there have been cases where it was still enabled.
If you tried to start the cvpnd.exe in services and it failed, there is a chance that the cvpnd.exe driver was not installed properly or you might have installed the new version over the old version.
NOTE
Before installing a new version of the VPN client, always ensure that older versions are uninstalled prior to installation. Some un-installers might not work in a way you expect. To resolve this issue, uninstall the current version; make sure to use the VPN uninstaller that is located in Start, Programs, Cisco Systems VPN Client, Uninstall VPN Client, and then reboot. After the reboot, reinstall the new VPN client, reboot, and test it.
Step 3: Check or Create Your Proles

Before you can connect to a concentrator, you must have at least one prole pointing to that concentrator. Typically, the network administrator creates the proles and distributes them to users. The VPN client software is shipped with a sample user prole. The le is named sample.pcf, and its content is shown in Example 22-3. The *.pcf les are usually stored under C:\Program Files\Cisco Systems\VPN Client\ Proles. For specic information on the meaning of each eld, see www.cisco.com/ univercd/cc/td/doc/product/ vpn/client/nonwin35/user_gd/prole.htm.
Example 22-3
A Sample User Prole That Might Be Shipped with the Installer

[main] Description=sample user profile Host=10.7.44.1 AuthType=1 GroupName=monkeys EnableISPConnect=0 ISPConnectType=0 ISPConnect= ISPCommand= Username=gawf SaveUserPassword=0 NTDomain= EnableBackup=0
Scenario 1: Cannot Authenticate
773
Example 22-3
A Sample User Prole That Might Be Shipped with the Installer (Continued)
BackupServer= EnableNat=0 CertStore=0 CertName= CertPath= CertSubjectName= CertSerialHash=00000000000000000000000000000000 DHGroup=2 ForceKeepAlives=0
The easiest way to create a prole is to open sample.pcf with any text editor. Then modify the necessary entries and save it with a different name in the same directory that is called, for example, NEW_CONNECTION.pcf. Make sure you use the .pcf le extension or the VPN client will not read it. When creating a prole, the following elds must be dened at a bare minimum:
[main] (This does not have to be dened but must be in the le) Host AuthType GroupName Username
After a prole is created, you have the option of cloning entries from the VPN client. Choose the connection entry that you want to clone and select options, then select clone entry. After you enter the name of the cloned entry, it creates a duplicate .pcf le in the Proles folder. After its created, you can modify the properties on the VPN client by choosing options and then properties.

In this scenario, several possible problems are reviewed to demonstrate why authentication might fail when using the VPN software client. Each case identies a possible problem, one or more solutions. This scenario is based on the assumption that you have completed the preliminary troubleshooting steps and have a working Internet connection. Different reasons exist for why VPN authentication might fail, and they are reviewed in this scenario.
Case 1: Bad group name or group passwordA bad group name or group password can cause a connection to fail every time. Case 2: Prompted multiple times for username and passwordMost likely, this is caused by a bad password. This might also be because the deterministic network enhancer (DNE) is not enabled in the Local Area Connection window. Case 3: Firewall softwarePersonal rewall software might be blocking the necessary ports or applications that VPN requires to function.
774
Case 4: MTU set highA fragmentation issue, because the MTU might be set too high. Case 5: MTU set lowThis can cause authentication issues.
Case 1: Bad Group Name or Group Password

In this case, the possibility of a bad group name or group password is examined. Typically, the user receives the error Remote peer is no longer responding or Failed to establish a secure connection to the security gateway. It is difcult to determine what the problem is based on solely on the connection error messages, because a single error can parent multiple problems. The group name and group password is not the same as the username and password used for authentication on a Remote Authentication Dial-In User Service (RADIUS) server. The group name and password are stored on the VPN concentrator, and on the VPN client. In essence, it is a way for the VPN administrator to group different user requirements into different client groups and eventually to apply group features or policies to all members of the group. For example, some users NAT within their home local-area network (LAN). When they connect to the concentrator, it must recognize that the user is NATing and adjust. The concentrator can tell if the user is NATing or not, based on the group name and password used to connect. The group name and encrypted password are stored on the .pcf le that is located within the C:\Program Files\Cisco Systems\VPN Client\Proles folder. The best way to re-enter a group name and password for a specic prole is to clone the connection entry because the password is encrypted in the .pcf le, which contains the necessary information for the client to establish an IPSec tunnel to the concentrator. Further analysis on what you can do with .pcf les is included in some of the later cases, but for now, refer to Step 3 in the previous section of this chapter. The best way to troubleshoot this type of case is to examine the log for multiple Internet Security Association and Key Management Protocol (ISAKMP)/Oakley retransmissions while trying to initiate a connection. Refer to Example 22-4. If multiple retransmissions exist, it is likely that the group password is corrupted. To re-enter the group name and group password, get the group password from the VPN administrator and clone the connection entry by highlighting the entry you want to clone, then go to Options, Clone Entry. Simply ll in the name of the entry, group name, and password.
Example 22-4
Example of a Connection Attempt with a Corrupted Group Password

49 00:30:30.482 12/26/01 Initiating connection. <Output Omitted> Sev=Info/6 DIALER/0x63300002
775
Example 22-4
Example of a Connection Attempt with a Corrupted Group Password (Continued)

56 00:30:36.430 12/26/01 Sev=Info/4 IKE/0x63000013 SENDING >>> ISAKMP OAK AG (Retransmission) to 10.0.0.1 57 00:30:41.448 12/26/01 Sev=Info/4 IKE/0x63000013 SENDING >>> ISAKMP OAK AG (Retransmission) to 10.0.0.1 58 00:30:46.465 12/26/01 Sev=Info/4 IKE/0x63000013 SENDING >>> ISAKMP OAK AG (Retransmission) to 10.0.0.1 ! After four attempts to initiate an ISAKMP/Oakley key exchange with ! no response, the client stops sending. 59 00:30:51.492 12/26/01 Sev=Warning/2 IKE/0xE3000079 Exceeded 3 IKE SA negotiation retransmits... peer is not responding 60 00:30:51.492 12/26/01 Sev=Info/4 CM/0x63100014 Unable to establish Phase 1 SA with server 10.0.0.1 because of DEL_REASON_PEER_NOT_RESPONDING ! The concentrator will never allow a client to begin phase 1 if ! the group password is invalid. <Output Omitted>
When multiple backup concentrators are listed in the .pcf le, and if the VPN client cycles rapidly through all the connection entries and returns with Failed to establish a secure connection to the security gateway, both the group name and password might be corrupted. If that is the case, clone the connection entry and re-enter the group name and password.
Case 2: Prompted Multiple Times for Username and Password

In this case, you have already tested your Internet connectivity and lowered your MTUs. You are about to connect, but after entering username and password at the VPN username and password prompt, you do not connect. Instead, you continually get prompted for your username and password. This problem can be one of two things: Either there is a problem with the RADIUS username and password, or there might be an issue with one of the DNE miniports.
Bad Username or Password

Ninety-ve percent of the time, a bad username or password is related to a bad RADIUS account. Unfortunately, versions below VPN client v3.5 do not identify why you have to reenter your password, it just keeps prompting you. The solution to this problem is to contact your network administrator (RADIUS administrator) and request a reset of your username and password. When using the VPN client release 3.5.1, if the RADIUS Expiry option is selected on the VPN 3000 concentrator as the IPSec authentication method for the group, the VPN
776
concentrator can provide enhanced login failure messages to the VPN client describing specic error conditions. These conditions include the following:
Password expired Restricted login hours Account disabled No dial-in permission Error changing password Authentication failure
The password expired message appears when a user, whose password has expired, rst attempts to log in. The other messages appear only after three unsuccessful login attempts. For more information on VPN client release 3.5.1, see www.cisco.com/univercd/cc/td/doc/ product/vpn/client/rel3_5_1/351_3kcl.htm.
Problem with the DNE Miniport

To troubleshoot the issue, DNE rst must be explained. DNE is a network driver interface specication (NDIS) compliant module, which resides under the NDIS module of the Windows OS and is essentially an extension of NDIS functionalitysee more about DNE architecture under www.deterministicnetworks.com/dne.asp. DNE has solved numerous well-known problems when using competitive NDIS intermediate drivers, and it is available for Windows, Linux, HP-UX, and Solaris versions. DNE appears as a network device driver to all protocol stacks, and as a protocol driver to all network device drivers. It supports all known network protocols and network adapter types. Every physical device listed under the Device Manager of Windows OS, has a supporting DNE driverone for every LAN adapter (NIC card), USB driver, or wide-area network (WAN) protocol (Internet Protocol [IP], Point-to-Point Tunneling Protocol [PPTP], Layer 2 Tunnel Protocol [L2TP]). If any physical adapter or protocol has ever been installed and then later removed from any particular system, the DNE supporting driver still exists until it is removed manually. If the DNE extension is installed, the newly installed physical driver or protocol obtains a newly populated DNE driver. The DNE extension includes DNE plugins, which can be invoked when inbound or outbound packets match prespecied lters. A DNE plugin written for one operating system usually requires only to be recompiled to run on other operating systems. The number of lters is not dened; there can be thousands of them. The DNE plugins provide frame or packet inspection (including MAC-level), to modify, delete, insert, or redirect them. The redirect function is especially important when redirecting packets from a virtual VPN IP to the ISPs IP address.
777
In DNE-related issues, the user has a valid RADIUS account but still is unable to authenticate. The user gets prompted for username and password multiple times, and cannot authenticate. For this case, you should always check the Windows Device Manager for bad DNE miniports. To check DNE functionality, rst open the Windows Device Manager by right-clicking My Computer, and select properties. From the Properties window, select the tab labeled Hardware, then click Device Manager. Scroll down to the Network Adapters and expand the window by clicking the + next to it. From there, you should see a list of your network adapters. Remove any extra Ethernet adapters that are bound to a DNE miniport with a red cross through it. There must be at least one functioning DNE miniport bound to each adapter, so make sure not to remove them all. After removing all the extra disabled DNE miniports, try the connection again.
Case 3: Firewall Software

Several different rewall software solutions are available for home users, but the three leaders are ZoneAlarm, Black Ice, and Norton Personal Firewall. Cisco recommends using Zone Labs ZoneAlarm with the Cisco VPN 3000 client because of its compatibility with the VPN client. Although Cisco recommends ZoneAlarm, we also show you how to congure NetworkIces BlackICE, another popular software rewall. Despite what rewall client you choose, you must allow all VPN applications and port numbers. There are a couple of reasons why Cisco endorses ZoneAlarm, besides the fact that it is compatible with the Cisco VPN client. One major reason is its ease of use, by using applications instead of port numbers to block data. So you see what applications are trying to access your computer, and you can then make better decisions on whether to block them or not. ZoneAlarm Pro is compatible with Microsoft Windows 95/98/Me/NT/2000 and XP. A majority of Cisco employees that use rewall software use ZoneAlarm.
NOTE
As of December 2001, Cisco embedded ZoneAlarm stateful rewall into the new release of the Cisco VPN 3.5 client. For more information, visit www.zonelabs.com/store/content/ home.jsp.
ZoneAlarm Conguration
Getting the VPN client to work with ZoneAlarm is actually pretty simple. When ZoneAlarm is rst installed, it blocks everything and is in stealth mode; no one on the Internet can see you. As you start bringing up applications that need to access the Internet, it asks you if you would like each application to access the Internet. The rst time you try
778
to connect with the VPN client, you are prompted three times to permit access. First, for the cvpnd.exe, second for the ipsecdialer.exe, and lastly for the Extended Authentication (Xauth) application (VPN user authentication). After you approve the application, they are placed into ZoneAlarms programs, see Figure 22-4. From there, you will need to grant Trusted and Internet Access in ZoneAlarm Plus and Allow Connect in ZoneAlarm Pro. This will allow the VPN client to traverse through ZoneAlarm freely.
Figure 22-4 Allowing the VPN Client to Pass Through the ZoneAlarm Software Firewall
Network ICE BlackICE Defender Conguration

Network ICE BlackICE Defender is a trafc monitoring security product. If you properly congure it, BlackICE Defender can work with the VPN client. It must be congured in Trusting, Nervous, or Cautious mode, and if you use Nervous or Cautious mode, you must add the public IP address of the VPN concentrator to the list of trusted addresses. You can congure the VPN client to work with Paranoid mode when using Tunnel-everything mode. Split Tunneling requires BlackICE to be in Trusting, Nervous, or Cautious mode. The Cisco VPN client rewall has the following requirements for BlackICE (BlackICE Defender 2.5 or greater, or BlackICE Agent 2.5 or greater). For BlackICE Defender 2.5, copy the BICTRL.DLL le from the Cisco installation release medium to the BlackICE
779
installation directory on the VPN client PC. This is a mandatory step for making a connection with BlackICE. BlackICE Defender version 2.9 and greater includes the BICTRL.DLL le in the Network ICE distribution medium, so you do not need to copy it from the Cisco installation release medium. Some types of rewall software require you to enter specic port numbers to access the Internet. The port numbers that the VPN client requires to be open are covered in Scenario 5, Case 1.
Case 4: MTU Set High

If the user has gone through Case 1 and veried that the Internet connectivity and routing is functioning, the next step is to check the MTU. In this case, you analyze why the user cannot authenticate when trying to initiate an IPSec tunnel with the MTU set at 1500. One of two things can happen: Either the user cannot authenticate at all, or the user can pass data successfully. If the user can authenticate but cannot pass any data, see Scenario 2, Case 1. The size of the MTU is an integral part for a successful VPN connection. The MTU for the most common encapsulation of IP over an Ethernet transmission link (www.faqs.org/rfcs/ rfc894.html) is 1500 bytes. By convention, the MTU includes the entire IP datagram, including all IP headers, but excludes link encapsulation headers. See Chapter 21, Remote Access VPN Troubleshooting, for details. IPSec causes major issues with the MTU setting because it lengthens each IP packet by one, or possibly by two IP headers. The length of these headers depends on the type of IPSec protocol that you are using; however, the headers cannot exceed 80 bytes per packet. If an application emitted a 1500-byte packet that must travel though an IPSec tunnel, the added IPSec headers require fragmentation of each packet. See Figure 22-5. Most believe that the only downside to fragmentation in a worst-case scenario is some minor performance issues; however, fragmentation can cause the inability to pass data or the failure to authenticate with VPN.
Figure 22-5 Fragmented Packets Traversing Through the Network
Packet Size 799 Packet Size 1598 Packet Size 799
The best way to handle this problem is to avoid fragmentation completely. By lowering the interface MTU, your interface does not emit packets that need to be fragmented after IPSec encapsulation for transport through Ethernet-size-capable routers and links, as shown in Figure 22-6.
780
Figure 22-6
MTU Emitting 1400-Byte Frames and Not Requiring Fragmentation
Packet Size 1400 Packet Size 1400
To illustrate the nuances surrounding lowering an MTU, the text discusses the following issues:
Determining what MTU will work Applying the MTU size to the PC Adjusting the MTU size in the registry
Determining What MTU Will Work

Remember that 1400 is not always the correct number; you might have to decrease the MTU even further, but 1400 is an excellent starting point. The MTU size depends on your ISPs equipment because your packets must traverse across their routers. To determine what the MTU size is on your connection, at the DOS prompt, type the following: C:/>ping -f -l [packetsize] [www.your_isp.com] where
-f is dont fragment; this is the variable that tells DOS not to break the packet into smaller pieces. -l is an option that allows you to enter [packetsize]. [packetsize] is the amount of data that you want to send (valid range is from 0 to 65,500). {www.your_isp.com] is your ISPs URL (you can also use any public URL, gateway, or server).
If you exceed the MTU of the ISP, you receive the message Packet needs to be fragmented, but DF set. If you receive this message, you must decrease the size of the packet and repeat the ping again. Continue this process until you receive a successful echo reply from the remote host. Assume that the rst successful echo reply message is when the packet size is set to 1372. In calculating the MTU, remember that when you specify -l <n>, the IP packets that you generate are actually <n> + 28 bytes long. So when you apply the MTU size on your interface card, the size is 1372 + 28 = 1400.
781
Applying the MTU Size to the PC

A few ways exist to apply the MTU to your PC. The most common and simplest way is to use the SetMTU application that comes with the Cisco VPN client. See Figure 22-7. You can also adjust the MTU in the registry, or use applications such as TweakMaster (Rose City Software), but both are substantially more difcult and risky. TweakMaster is similar to the Cisco VPN SetMTU application, and if you are interested you can download it at www.pattersondesigns.com.
Figure 22-7 The SetMTU Application
Adjusting the MTU Size in the Registry

In some circumstances, you might nd that MTU adjustment applications such as the Cisco VPN client Set MTU or TweakDUN application do not have the capabilities of lowering the MTU on some interfaces. In that case, you have the option of adjusting the MTU in the registry, which is all the MTU applications really do. This next section describes in detail how to lower the MTU in the following versions of the Windows operating system:
Windows 9x Setting the MTU manually in the registry Windows XP only
Windows 9x
There is an optional parameter in the registry called MaxMTU that can be associated with adapter bindings. Adding this optional key inuences the outbound MTU, as seen by the IP
782
protocol stack, and the announced maximum segment size (MSS) during Transmission Control Protocol (TCP) setup. If MaxMTU is missing from a binding, the default MTU for the adapter (1500 for Ethernet) is assumed. If you see fragmentation problems, set MaxMTU on your active TCP network interface to 1400. Remember to reboot after you make any registry changes because they do not take affect until the PC has rebooted.
NOTE
When adjusting settings in the registry, fairly minor changes in your networking conguration can cause the parameter to disappear. Please read the documentation suggested in the following links. The location of the MaxMTU in the Windows 9x registry is as follows:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Class\netTrans\000 n
You can learn more about it at http://support.microsoft.com/support/kb/articles/q158/4/ 74.asp. The location of the MaxMTU in the Windows NT registry is as follows:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services Key: Adapter Name \Parameters\Tcpip
For Windows 2000 and later, the MaxMTU value is located under the following key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services Key: Tcpip\Parameters\Interfaces\ ID for Adapter
NOTE
There is a bug in the SP1 version of W2K, and MaxMTU does not work. Either upgrade to SP2, or delete MaxMTU from the registry. See http://support.microsoft.com/support/kb/ articles/q120/6/42.asp for more information.
Windows NT/2000
You might prefer to follow the directions from Microsofts web site. However, some easy steps to manually set the MTU value in Windows 2000 are described in the following list. This method is designed for Windows 2000, but it is similar for other Windows operating systems. You should only perform this process if you suspect that the Cisco VPN client SetMTU application is not functioning correctly. For example, if you still observe MTUrelated issues, despite the fact that you have lowered the MTU, this is a good way to conrm that the MTU is set to your intended value. The steps are as follows:
1 Open the registry using regedt32 (regedit can be used, but this example is designed
for regedt32).
2 From the HKEY_LOCAL_MACHINE window, go to \SYSTEM\CurrentControlSet\
Services\Tcpip\Parameters\Interfaces (these are all the adapters that your PC has, unfortunately they do not have a name associated with them).
783
3 Highlight the adapter you want to drop the MTU on, and look in the right window for
something called MTU:REG_DWORD:0x514 (it can be a different number from 0x514, this number is the MTU size in hex).
4 In the right window, double-click MTU:REG_DWORD:0x514; a box called
DWORD Editor opens.

5 Change the Radix radio button to Decimal; this is your MTU value. 6 Change the MTU to the desired value and close regedt32. 7 Reboot.
If you are unsure of what adapter you are lowering the MTU on, try dropping the MTUs down on all adapters listed. It does not hurt your uplink to have the MTU set to 1400 instead of 1500. If there is no MTU eld for that adapter, you can add one by highlighting the adapter, then go to Edit, and Add Value. Choose REG_DWORD from the drop-down menu, name it MTU, and press OK.
Windows XP Only
This example demonstrates how to lower the MTU on a PPPoE adapter. First, locate the following key:
HKLM\SYSTEM\CurrentControlSet\Services\Ndiswan\Parameters\Protocols\0
After you locate the key, add all these values: Value Name: ProtocolType Data Type: REG_DWORD Value Data: 0x00000800 Value Name: PPPProtocolType Data Type: REG_DWORD Value Data: 0x00000021 Value Name: ProtocolMTU Data Type REG_DWORD Value Data: The appropriate MTU size (in decimal) (we recommend 80 Hex or 128 Decimal)
To do so,
1 Click Start, click Run, type regedit, and click OK. 2 Locate and click the following key in the registry:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Ndiswan\Parameters
3 On the Edit menu, point to New, and click Key.
784
4 Type Protocols, and press ENTER. 5 On the Edit menu, point to New, and click Key. 6 Type 0, and press ENTER. 7 On the Edit menu, point to New, and click DWORD Value. 8 Type ProtocolType, and press ENTER. 9 On the Edit menu, click Modify. 10 Type 800, and click OK. 11 On the Edit menu, point to New, and click DWORD Value. 12 Type PPPProtocolType, and press ENTER. 13 On the Edit menu, click Modify. 14 Type 21, and click OK. 15 On the Edit menu, point to New, and click DWORD Value. 16 Type ProtocolMTU, and press ENTER. 17 On the Edit menu, click Modify. 18 Type the appropriate MTU size (decimal value), and click OK. 19 Quit Registry Editor.
Case 5: MTU Set Low

The last case discussed how lowering the MTU reduces problems with the IPSec connection; however, too low an MTU can inhibit the ability to authenticate. Ciscos remote access team has encountered many cases where the user was familiar with the MTU issue, and lowered their MTU to 576 without trying a higher number such as 1400. These users were trying to save time on reboots (you have to reboot each time you make an MTU change) by lowering it to 576, assuming that the lower the MTU the better the VPN works. This assumption is incorrect for two reasons: First, too low an MTU can inhibit the overall performance of your Internet connection, and second, it can cause the Xauth to fail during VPN authentication.
Scenario 2: Can Authenticate but Problems Passing Data

In this scenario, the user can authenticate on the concentrator, but cannot pass data. The ability to pass data consists of downloading e-mail, browsing the companys internal web
785
sites, and accessing the internal domain. Different things might be wrong based on the characteristics, and each possible issue is covered in the following cases. These cases introduce the following issues:
Cannot pass trafc and using NAT connection entry MTU causing packet loss Connection keeps dropping Cannot browse the internal domain
Case 1: Cannot Pass Trafc and Using NAT Connection Entry

If you are using NAT on your LAN, you must use a specic connection entry on the VPN client. The concentrator must be aware that you are using NAT, because that might be the main reason for the not passing data issue. The Internet Assigned Numbers Authority (IANA) RFC 1918 reserved the following three blocks of IP address space for private networks (see www.ietf.org/rfc/ rfc1918.txt?number=1918 for more information):
10.0.0.010.255.255.255 172.16.0.0172.31.255.255 192.168.0.0192.168.255.255
To identify if you are using NAT, check your IP address. Refer to Table 22-2 to determine the IP address that your computer is using. If your address is in any of the three ranges listed above, you are NATing and you must use the NAT connection entry. The NAT connection entry, or prole, does not point you to a different concentrator from the standard connection entry. The main difference between the two proles is the group that you are assigned by the concentrator. If you review the two proles, NAT and standard, you will notice that each has a different group name and password (the password is encrypted). The concentrator has a group set up to allow IPSec clients to operate through a rewall, using NAT through UDP. The easiest way to create groups is to create a base group. After you have the base group that works with your current network, you can add groups and have them inherit the settings from the base group. Both the standard and NAT groups have the same properties except for the group name, password, and the IPSec over User Datagram Protocol (UDP) box must be checked on the NAT group. It is located under Mode Cong. After you have created both groups on the concentrator, users can use the new groups after they have their .pcf les modied. See Chapter 20, Remote Access VPN Design and Conguration Solutions, for more information about creating groups on the concentrator.
786
Case 2: MTU Causing Packet Loss

In Scenario 1, Case 1, it was explained how the default MTU size (1500) can cause authentication failures. The method to test MTU size was also explained and although this information was covered in detail already, this case advises you that different types of problems are associated to the MTU setting. The MTU is the largest number of bytes that a frame can carry, not counting the frames header and trailer. A frame is a single unit of transportation on the data link layer. It consists of header data, plus data passed down from the network layer, and possibly trailer data. An Ethernet frame has an MTU of 1500 bytes, but the actual size of the basic Ethernet frame can be up to 1524 bytes (20-byte header, 4-byte CRC trailer). If you can connect with the Cisco VPN client but cannot send or receive data, it is likely an MTU problem. Common failure indicators include the following:
You can receive data, such as mail, but not send it. You can send small messages (about ten lines), but larger ones time out. You cannot send attachments in e-mail. While browsing the web, you can bring up small pages with mostly text, but the larger graphical sites, or parts of them, do not come up.
If you are experiencing any of these issues, you must lower your MTU. To determine what size to set your MTU and where to set it, see Scenario 1, Case 1.
Case 3: Connection Keeps Dropping

There are a couple of reasons why a VPN connection might be dropping. It can be a problem with the ISP, or ports can be closing on a rewall that you are going through. It is unlikely that the concentrator is dropping your connection, but it is not impossible. In this case, you are shown how to use some tools to help maintain your VPN tunnel, and ways to pinpoint where the problem exists. The following sections cover these issues:
Bad ISP connections Sending keepalives
Bad ISP Connection

The rst thing to determine is the quality of your ISP connection by using the ping or tracert commands. Set up a continuous ping to your corporate rewall or concentrator (if it is in front of the rewall). This identies if there is any heavy latency or packet loss along the way, and both of these issues can cause a tunnel to drop. For certain technologies, such as satellite, you have to expect some degree of latency. Satellite services can result in up to 1500-3000 ms round-trip time (RTT), depending on the
787
packet size. That much latency does not disrupt browsing capabilities to the external web, but it does severely impair the speed of a VPN connection. Some VPN over satellite users have compared it to speeds of analog dialup connections. To set up a continuous ping to your corporate rewall, use the ping command from Example 22-5.
Example 22-5
Continuous ping to the Corporate Firewall to Determine if There Is Packet Loss

C:\>ping -t w 4000 firewall.company.com ! The w sets the ping to 4000 ms before timing out Pinging firewall.company.com [65.1.1.2] with 32 bytes of data: Reply from 65.1.1.2: bytes=32 ! 4000 ms or more may cause a Reply from 65.1.1.2: bytes=32 Reply from 65.1.1.2: bytes=32 Request timed out. ! Packet loss Reply from 65.1.1.2: bytes=32 Request timed out. <Output Omitted> time=240ms TTL=249 problem time=240ms TTL=249 time=245ms TTL=249
time=242ms TTL=249
If you see any dropped packets, try tracing to the rewall a couple of times. By trace routing to the rewall, you can see exactly where the packets are getting dropped, or where the latency occurs. If you are losing packets and cannot route to your corporate rewall, you must contact your ISP. Provide them information, including how many packets are dropped and the host name of the router that you are experiencing latency connecting to or dropping packets on.
Sending Keepalives
If you run the ping and traceroute tests and nd that your ISP connection is stable, try turning on ForceKeepAlive for that prole. There is a feature in each connection entry prole called ForceKeepAlive, which basically sends out Internet Key Exchange (IKE) and Encapsulating Security Payload (ESP) keepalives for a connection at approximately 20second intervals. It helps prevent the NAT device or rewall from dropping your connection. Try turning ForceKeepAlive on and see if it helps. To turn ForceKeepAlive on, open the .pcf le with any text editor for the prole that you typically use. The proles are located under C:\Program Files\Cisco Systems\VPN Client\Proles. After it is open, set ForceKeepAlive = 1, which turns it on. It should dramatically reduce the number of dropped connections if it is associated with your rewall or NAT device. The ForceKeepAlive is covered in more detail in Scenario 5, Case 1.
Case 4: Cannot Browse the Internal Domain

In this case, the user can connect to the concentrator and even pass data such as e-mail, and browse internal web sites. However, the one thing that does not work is accessing the
788
internal NT domain (Network Neighborhood or My Network Places), where the user has zero to limited access to the domain. This issue can be frustrating initially because it appears everything except domain access is working. You can take two steps to solve this problem: adding the WINS addresses or further lowering the MTU.
Adding WINS IP
WINS is a NetBIOS name service dened in RFC 1001 and RFC 1002. WINS servers basically maintain a database of computer names to IP addresses. When WINS is congured, a computer rst tries to use a WINS server for name registration and resolution. If that fails, the computer then resorts to subnet broadcasts. Unlike LMHOSTS, WINS is useful in a DHCP network where IP addresses are constantly changing because each client, during boot up, registers its name and IP address with the WINS server. In general, this step is not necessary because when the concentrator performs the conguration mode, it pushes a packet of IP addresses to the client, including WINS IPs. However, because of computer-related issues or version-related bugs, you might consider the following steps. Assign statically the corporate WINS addresses to your TCP/IP settings. The WINS addresses help guide your computer to and through the domain by giving it access to a database of computer locations. This eliminates a lot of the problems with nding the domain controller and other Microsoft issues that you might encounter. To add WINS addresses to your TCP/IP, use the following instructions. For Windows 95/98,
1 Under Control Panel, double-click Network. 2 Under the Conguration tab, highlight the adapter that you are using with ->TCP/IP
next to it (for example 3COM->TCP/IP), then click Properties.

3 Under the WINS tab, enter the WINS IP addresses.
NOTE
On Windows 95/98 workstations, the workgroup name of the workstation must be the same as the domain name that you are trying to log into, or you will not see a browse list. For Windows NT/2000,
1 Right-click My Network Places, which is located on your desktop and select
Properties.
2 Right-click and select Properties on the Local Area Connection that is not crossed out. 3 Highlight TCP/IP, then click Properties. 4 Click Advanced. 5 Under the WINS tab, enter the WINS IP addresses.
789
Still Cannot Browse Correctly

If you are still having problems browsing the intranet and the domain, you might need to modify some networking settings. In this section, you learn how to ne-tune your network settings to work best with VPN:
Windows 95/98 Windows NT/2000 Lower the MTU
Windows 95/98
A majority of the time, this problem occurs with users who are dialing to an ISP, and connecting with VPN. Most dialup-only users cannot change the browser characteristics because they do not have the le and printer sharing for Microsoft Networks service congured in the Network Control Panel. To install le and printer sharing for Microsoft Networks service, go to Network in the Control Panel, click Install, and select Service. Then, choose Microsoft as the vendor along with le and printer sharing, and click Add. These settings must be congured and they are different from the File and Print Sharing buttons in the Control Panel. After the settings are installed, you can select the properties for this service under the Advanced tab. Two options can be changed, and setting the Browse Master to disable ensures that the user gets the Browse list more quickly through the tunnel. For information about the rogue master browser problem and for many other good tips for people experiencing the preceding problem, go to www.cisco.com/warp/public/473/ winnt_dg.htm#xtocid882960.
NOTE
Windows NT/2000
NT has a Registry key that indicates to the OS whether or not to maintain a list of servers for the browser function. It also indicates how the node acts in the browser context. If the key value is set to Auto (the default), the PC tries to force an election. When the workstation boots on an isolated LAN segment or for dialup, the result is that it cannot nd a master browser (or backup master browser). After the tunnel is up, it sends out subnet broadcasts for a backup server, which gets forwarded across. If these go unanswered, it asks for an election. The Registry key to change is as follows (try setting it to No): HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Services/Browser/ Parameters/MaintainServerList
790
Lower the MTU

After you complete the WINS modications, and if you are still having problems browsing the domain, try lowering the MTU. This rarely occurs but there have been cases where the MTUs were set just a little too high. Try lowering them by 50 and see if that xes the issue. For information on how to lower your MTU, refer to Scenario 1, Case 1.
Scenario 3: PPPoE Software/Hardware Problems

PPPoE was covered in great detail in Chapter 21. In this case, the types of problems you might encounter with PPPoE are identied. As you might know, the use of PPPoE software continues to increase, especially in the DSL industry. PPPoE can be used with cable, but it is rarely used by cable ISPs. Companies such as AT&T @Home currently use a static computer name to authenticate their users. Numerous PPPoE clients are in use today, but only three comprise 90 percent of the market. These three main PPPoE clients are NTS Enternet 300 (SBC), WinPoet (Verizon, Earthlink), and RASPPPoE (Freeware). The subsequent sections cover each client (after rst presenting an overview of PPPoE and the MTU issue). This section demonstrates to you how to congure and troubleshoot the following two topics:
PPPoE Software Issues IOS-based PPPoE Issues
PPPoE is similar to a dialup connection: you bring up a dialer on your PC, type a username and password, and hit connect. Your user information is then passed to an authentication server through the access concentrator, and if you are successfully authenticated, you get connected. All PPPoE negotiations are done on the ISP side, so after you get connected, you can connect with your VPN client (see Figure 22-8).
Figure 22-8 The Basic PPPoE Infrastructure; All the PPPoE Negotiations Are Done on the ISP Side
Corporation AAA
PPPoE Client
PPPoE
VPN Tunnel
SSG ISP
CPE RFC 1483 Bridged
DSLAM
Aggregation Device Cisco 6400
Tunnel
Extranet
791
Case 1: PPPoE Software Issues

Based on previous discussions, the MTU issue is one of the greatest problems faced by VPN users, and unfortunately, it also carries over to PPPoE. The MTU settings when using the PPPoE protocol are the main contributor to most of the problems.
NOTE
The Set MTU application in the VPN client does not have the capability to adjust the MTU on a PPPoE virtual adapter. As of October 2002, there are no plans to add PPPoE adjustment capabilities to the VPN 3000 Client Set MTU application.
If you try to connect without lowering the MTU on your PPPoE adapter, you might experience severe problems such as failure to download e-mail, failure to browse the intranet, and failure to browse the internal domain. In the following three sections, you learn about the steps required to lower the MTU on all three of the major PPPoE clients.
MTU Settings in NTS Enternet 300

NTS Enternet 300 has proven to be one of the dominant PPPoE clients in the market, particularly on the West coast. It is a solid client, easy to congure, and it works well with Ciscos VPN client. This section focuses on conguring NTS Enternet 300 on multiple Windows operating systems. For Windows 95/98,
1 On the main desktop, right-click My Network Places and go to Properties. The
Network window opens.

2 Double-click the Network TeleSystems PPPoE Adapter. 3 On the Network TeleSystems window, click the Advanced tab, and then click
MaxFrameSize. Change the value, which varies from case to case but ranges from 1200 to 1400.
4 Reboot the computer.
For Windows NT/2000,

Network and Dial-Up Connections window opens.

2 Right-click and go to Properties on each connection until you nd the connection that
has the NTS Enternet PPPoE Adapter.

3 After you nd the correct connection, click Congure on the right side of the window. 4 On the next window, click the Advanced tab, then click MaxFrameSize. Change the
value, which varies from case to case but ranges from 1200 to 1400.
792
MTU Settings in WinPoet

Winpoet is another widely used PPPoE client. Although it is widely used it is not considered by most to be a great PPPoE client. It is difcult to modify MTU settings for it to work with the Cisco VPN client. Essentially, the Cisco VPN client and WinPoet do not work well together. Fortunately for the PPPoE users, they can use any PPPoE client. So there are no limitations prohibiting a user from switching PPPoE clients. We have formulated a method to adjust the MTU using WinPoet, which follows; however, Cisco recommends switching to another PPPoE client such as NTS Enternet or RASPPPoE. WinPoet does not provide user control over the PPPoE MTU under Windows 95/98. But for Windows NT/2000, you can control it by explicitly setting the following registry key: HKLM/system/currentcontrolset/control/class/<guid>/<adapternumber> adapter( 000x) : Value: MaxFrameSize Value type: DWORD Data: 1400 (or less) The <guid> and <adapternumber> can vary on different systems. Browse through the registry, looking for the MaxFrameSize value.
WARNING
Edit the registry only if you are comfortable doing so. Incorrect registry entries can make your PC unstable or unusable. If you are not familiar with editing the registry, contact desktop support for assistance.
MTU Settings in RASPPPoE

RASPPPoE is another good PPPoE client, and it is freeware. It gives users the ability to adjust the MTU without having to touch the registry and has been successfully tested with Ciscos VPN client. If you are interested in downloading or for more information on conguring RASPPPoE, visit http://user.cs.tu-berlin.de/~normanb/. For Windows 95/98,
Network window opens.

2 Find the PPP over Ethernet Protocol that is bound to the network card in your PC, then
double-click it.
3 Under the General tab, check Override Maximum Transfer Unit. Change the value,
which varies from case to case but ranges from 1200 to 1400.
793
For Windows NT/2000,

1 On the main desktop, right-click My Network Places and go to properties. The
Network and Dial-Up Connections window opens.

2 Right-click the connection that the PPPoE Protocol was installed for, and go to
Properties.
3 When the window opens, double-click PPP over Ethernet Protocol. 4 Under the General tab, check Override Maximum Transfer Unit. Change the value,
which varies from case to case but ranges from 1200 to 1400. Additional information about this topic can be found at http://user.cs.tu-berlin.de/ ~normanb/README2K.HTM.
Case 2: IOS-Based PPPoE Issues

In todays environment, more and more devices support PPPoE. It is no longer just software and routers that can support PPPoE; devices such as the PIX 501 and 506, and the VPN 3002 hardware client also support PPPoE. There is a long list of Cisco routers that support PPPoE, including the 806, 826, 827, 827-4V, 828, SOHO 77, and SOHO 78. Although each one supports PPPoE, each one meets different needs. For more information on these product specications, see www.cisco.com/univercd/cc/td/doc/product/access/acs_x/827/ 827rlnts /820feat.htm. Hundreds of routers on the market support PPPoE. Although some were built to work with both PPPoE and VPN, others were built to meet the need for only one of the two. The following information provides output from a series of debug commands, which is not possible from a majority of routers on the market.
Cisco 800 Series PPPoE Connection Problem

This case demonstrates how a Cisco 806 router connects to an ISP using PPPoE. The 806 router connects to a generic ADSL modem and there is no other equipment besides the PC. In Example 22-6, the output shows the router trying to complete the PPPoE negotiation, but the Ethernet1 (WAN) interface is bouncing. You can also see what the log viewer displays with all lters set to high. The PPPoEs link control protocol (LCP) sends keepalives to the core. See the shaded comments in Example 22-6.
Example 22-6
PPPoE Router Trying to Connect While the WAN Link Bounces

806-ADSL#debug vpdn pppoe events and 806-ADSL#debug ppp negotiation THE LOG VIEWER IS OPEN 04:42:15: Vi1 LCP: echo_cnt 2, sent id 34, line up
continues
794
Example 22-6
PPPoE Router Trying to Connect While the WAN Link Bounces (Continued)
04:42:25: Vi1 LCP: echo_cnt 3, id 35, line up 04:42:35: Vi1 LCP: echo_cnt 4, sent id 36, line up 04:42:45: Vi1 LCP: echo_cnt 5, sent id 37, line up 04:42:56: Vi1 PPP: Missed 5 keepalives, taking LCP down ! LCP misses 5 keepalive responses and then takes the line down. ! The keepalives act as integrity packets. 04:42:56: Vi1 IPCP: Remove link info for cef entry 165.1.1.1 04:42:56: Vi1 IPCP: State is Closed 04:42:56: Vi1 PPP: Phase is DOWN 04:42:56: PPPoE 12997: Shutting down 04:42:56: PPPoE : Shutting down client session 04:42:56: PPPoE 12997: O PADT L:0002.1762.ad36 R:0002.3b00.9d43 Et1 04:42:56: %DIALER-6-UNBIND: Interface Vi1 unbound from profile Di1 04:42:56: Vi1 PPP: Phase is ESTABLISHING, Passive Open 04:42:56: Vi1 PPP: No remote authentication for call-out 04:42:56: Vi1 LCP: State is Listen 04:42:56: %LINK-3-UPDOWN: Interface Virtual-Access1, changed state to down 04:42:56: Vi1 LCP: State is Closed 04:42:56: Vi1 PPP: Phase is DOWN 04:42:56: Di1 IPCP: Remove route to 165.1.1.1 04:42:57: %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access1, changed state to down ! End of the process for taking down all phases, and ! removes the IP route from the table. Here the LOG VIEWER reports these events... 2 04:42:24.164 01/31/02 Sev=Warning/3 IKE/0xE3000062 Could not find an IKE SA for 10.0.0.1. KEY REQ aborted. ! ! ! ! This message usually indicates that at least one of the parameters of the SA has changed and as a result, the VPN tunnel is terminated. In this particular case, the reason is a flapping WAN connection, which results in changing the DHCP-based IP address.
3 04:53:57.140 01/31/02 Sev=Warning/2 IKE/0xE3000080 Received an IKE packet from someone other than the Concentrator that we are currently connected to... discarding packet. 4 04:55:06.023 01/31/02 Sev=Warning/3 IKE/0xE3000002 Function initialize_qm failed with an error code of 0x00000000(INITIATE:822) When you initiate a disconnect, a message similar to The VPN is terminated... is displayed. 04:43:16: Sending PADI: Interface = Ethernet1 ! Beginning the new negotiation of PADI-PADO 04:43:20: Sending PADI: Interface = Ethernet1 04:43:20: padi timer expired 04:43:28: Sending PADI: Interface = Ethernet1 04:43:28: padi timer expired 04:43:28: PPPoE 0: I PADO L:0002.1762.ad36 R:0002.3b00.9d43 Et1 04:43:30: PPPOE: weve got our pado and the pado timer went off
Scenario 4: 3002 Connection Problems
795
Example 22-6
PPPoE Router Trying to Connect While the WAN Link Bounces (Continued)
04:43:30: OUT PADR from PPPoE tunnel 04:43:30: PPPoE 13380: I PADS L:0002.1762.ad36 R:0002.3b00.9d43 Et1 04:43:30: IN PADS from PPPoE tunnel 04:43:30: %DIALER-6-BIND: Interface Vi1 bound to profile Di1 04:43:30: PPPoE: Virtual Access interface obtained. 04:43:30: Vi1 PPP: Phase is DOWN, Setup 04:43:30: Vi1 PPP: Treating connection as a callout 04:43:30: Vi1 PPP: Phase is ESTABLISHING, Active Open ............................................. 04:43:37: Vi1 IPCP: I CONFREQ [ACKrcvd] id 4 len 10 04:43:37: Vi1 IPCP: Address 66.1.1.2 (0x030642201A01) 04:43:37: Vi1 IPCP: O CONFACK [ACKrcvd] id 4 len 10 04:43:37: Vi1 IPCP: Address 66.1.1.2 (0x030642201A01) 04:43:37: Vi1 IPCP: State is Open 04:43:37: Di1 IPCP: Install negotiated IP interface address 66.44.44.1 04:43:37: Di1 IPCP: Install route to 66.1.1.2 04:43:37: Vi1 IPCP: Add link info for cef entry 66.1.1.2 ! End of the new negotiation - The new IP is installed under dialer interface. There is connectivity and the VPN session can start again.
See Chapter 21 for a detailed explanation of PPPoE.
Upgrading the Routers Firmware

Because PPPoE is a relatively new technology, it is still going through growing pains, especially with VPN. Many companies, other than Cisco, who manufacture SOHO routers, are frantically trying to develop products that meet the PPPoE/VPN needs of the consumer. Some of these routers might not function as expected and they might not work with the Cisco VPN client right out of the box. The best approach when you have problems connecting to a VPN concentrator through a new router is to upgrade the rmware. Almost all companies post a copy of their latest rmware release on their web sites, along with instructions on how to implement it. Immediately upgrade the routers rmware to eliminate this possible cause. If you use a router with rewall capabilities and the rmware upgrade does not solve the problem, try to open up the rewall completely. If it works, you know you have to work on getting the correct ports open. See Scenario 5, Case 1 for more information on what ports and protocols must be allowed on a rewall.

This scenario is designed to solve some fundamental problems you might run into when deploying a Cisco VPN 3002 solution within your company. The cases focus on establishing the connection to the concentrator, and on some general debugging techniques that you
796
can perform on the 3002. To simplify matters, the Cisco recommendation for authentication is used in the scenarios. However, there are ve different authentication mechanisms/ systems that can be used with the Cisco VPN 3000 concentrator, which are as follows:
NT domain RADIUS or RADIUS proxy RSA security SecurID (SDI) Digital certicates Internal authentication
Cisco recommends using RADIUS authentication. As you know, many companies already use RADIUS with their current dialup environment, so they can use the already built infrastructure. Also, the conguration required on the VPN concentrator to authenticate using a RADIUS server is relatively easy. Using RADIUS to authenticate 3002 clients is more secure than internal authentication because you can deny access to specic users immediately and easily. Internal authentication requires that you add users individually to the concentrator; therefore, users are authenticated by the concentrator itself. It is not the preferred method of authentication because many companies already have a dialup environment that uses RADIUS, so instead of managing two types of user authentication, RADIUS and internal VPN, just use the existing one. With one method, if you need to terminate a users access to all devices, you can simply terminate one account on the RADIUS server. The following Cant connect to the Concentrator scenario, as shown in Figure 22-9, is entirely based on 3002 authentication by a RADIUS server.
Figure 22-9 The VPN 3002 Network Model Used in Scenario 4
VPN 3060 Concentrator Internet VPN 3002 Client Internal Network Firewall with Hole RADIUS Server
In this case, the user connects the 3002 to a generic DSL modem, and uses PPPoE for the standard DSL connection, and RADIUS for the concentrator. If you are not using PPPoE, the trouble shooting process is less difcult because you either use a static IP address or pull one through DHCP. If not using PPPoE, ignore the PPPoE section. You try to establish a VPN connection with the 3002 client to the concentrator, but are unable to establish a tunnel. You should take three troubleshooting steps to resolve this issue:
797
Check the interfaces status on the 3002 Conrm the group name and password are correct Conrm the username and password are valid
Check the Interfaces Status on the 3002

The rst thing to check is the status of the interfaces. Are they Up or Down? To view interfaces on the 3002, go to Conguration, Interfaces. From there, if you have been given an IP address, subnet information, and your allocated DNS servers, you can check status (Up/Down). See Figure 22-10. In Figure 22-10, both the public and private interfaces are Up. The private interface is to your private network (internal LAN), and the public interface is to the public network, which uses the IP address provided by your ISP.
Figure 22-10 Checking the Interface Status on the VPN 3002
There are a total of nine different operational status messages that can be associated to either Public or Private interfaces. The status messages are as follows:
UP (green)Congured, enabled, and operational; ready to pass data trafc. DOWN (red)Congured but disabled or disconnected. TestingIn test mode; no regular data trafc can pass. Dormant (red)Congured and enabled but waiting for an external action, such as an incoming connection.
798
Not Present (red)Missing hardware components. Lower Layer DownNot operational because a lower-layer interface is down. Unknown (red)Not congured or not able to determine status. Not ConguredPresent but not congured. Waiting for DHCP/PPPoEWaiting for DHCP or PPPoE to assign an IP address.
If the interface is Down, the problem can be one of two things. Either there is a problem with the ISPs physical connection or the PPPoE connection is failing. Before calling the ISP, always check to see if you have entered a bad username or password. One way to do this is to run two event classes, PPPOEDBG and PPPOE. To add event classes on the 3002, go to Conguration, System, Events, Classes and click Add. Scroll down the list until you nd PPPOEDBG or PPPOE, and change the severity to log to 1-9, then click Add. The severity to log determines what is sent to the log based on the severity level. After you have the event classes (debugs) set up, go to the Filterable Event Log that is located under Monitoring, Filterable Event Log, and click Get Log. If you see a display similar to Example 22-7, you know it is either the PPPoE username or password. Try reentering the username and password on the Public interface, then retest. If the PPPoE authentication is still failing, work with your ISP to reset your PPPoE username and password.
Example 22-7
Log from a VPN 3002 Using PPPOEDBG and PPPOE Event Classes and a Bad PPPoE Username
23 03/02/2002 03:55:36.240 SEV=6 PPPOEDBG/4 RPT=11 Building PADI Packet. ! Usually the first step in the PPPoE connection. 24 03/02/2002 03:55:36.240 SEV=8 PPPOEDBG/11 RPT=19 Sending Packet down to IP. 25 03/02/2002 03:55:36.260 SEV=8 PPPOEDBG/12 RPT=214 Received Packet from IP. 26 03/02/2002 03:55:36.260 SEV=6 PPPOEDBG/7 RPT=9 Processing Received PADO Packet. 27 03/02/2002 03:55:36.260 SEV=6 PPPOEDBG/5 RPT=8 Building PADR Packet. 28 03/02/2002 03:55:36.260 SEV=8 PPPOEDBG/11 RPT=20 Sending Packet down to IP. 29 03/02/2002 03:55:36.280 SEV=8 PPPOEDBG/12 RPT=215 Received Packet from IP. 30 03/02/2002 03:55:36.280 SEV=6 PPPOEDBG/8 RPT=8 Processing Received PADS Packet.
799
Example 22-7
Log from a VPN 3002 Using PPPOEDBG and PPPOE Event Classes and a Bad PPPoE Username (Continued)
31 03/02/2002 03:55:36.280 SEV=7 PPPOEDBG/10 RPT=8 Building PPP Stream. 32 03/02/2002 03:55:36.310 SEV=8 PPPOEDBG/12 RPT=216 Received Packet from IP. 33 03/02/2002 03:55:36.310 SEV=8 PPPOEDBG/13 RPT=192 Sending Packet to PPP. 34 03/02/2002 03:55:36.310 SEV=8 PPPOEDBG/12 RPT=217 Received Packet from IP. 35 03/02/2002 03:55:36.310 SEV=8 PPPOEDBG/13 RPT=193 Sending Packet to PPP. 36 03/02/2002 03:55:37.710 SEV=8 PPPOEDBG/12 RPT=218 Received Packet from IP. 37 03/02/2002 03:55:37.710 SEV=8 PPPOEDBG/13 RPT=194 Sending Packet to PPP. 38 03/02/2002 03:55:37.710 SEV=2 PPP/39 RPT=8 PAP authentication failed received.. check/verify username/password . ! This indicates either the username or password is incorrectly configured. 39 03/02/2002 03:55:37.710 SEV=8 PPPOEDBG/12 RPT=219 Received Packet from IP. 40 03/02/2002 03:55:37.710 SEV=8 PPPOEDBG/13 RPT=195 Sending Packet to PPP. 41 03/02/2002 03:55:39.720 SEV=8 PPPOEDBG/12 RPT=220 Received Packet from IP. 42 03/02/2002 03:55:39.720 SEV=6 PPPOEDBG/9 RPT=8 Processing Received PADT Packet. 43 03/02/2002 03:55:39.720 SEV=6 PPPOE/6 RPT=18 PPPoE Session Terminated. ! The PPPoE session terminated so there is no connectivity.
After you get the public/PPPoE interface up, you should be able to ping external devices such as www.cisco.com. To ping on the 3002, go to Administration, Ping, then enter the host name or IP address of any host (for example, www.cisco.com). If the ping says Alive, you have Internet connectivity.
800
Conrm the Group Name and Password Are Correct

Now that a physical connection to the Internet is conrmed, try to connect to the concentrator. The best way to ensure that you have the correct username and password stored on the 3002 is to re-enter it. The location of the group name and password is found under Conguration, System, Tunneling Protocols, IPSec. If you do not know the group name and password, contact the network administrator. Cisco recommends turning on six event classes when troubleshooting this type of case, to cover a wide spectrum of possible issues. Do not set the severity to log level to 1-13, because this would capture too much information to digest at once; 1-9 severity level should sufce. The list of event classes that should run when troubleshooting is below. It is easier to read the output in the log if you run them in coordinating pairs, such as AUTH and AUTHDBG:
AUTH AUTHDBG IPSEC IPSECDB IKE IKEDBG
While running the capture log, if there is a bad group name or password, unfortunately there is no error indication; however, many phase 1 initializations are displayed. See Example 22-8.
Example 22-8
Common Log of Output if There Is a Group Name or Password Failure

5 03/02/2002 05:47:32.410 SEV=4 IKE/41 RPT=368 10.0.0.1 IKE Initiator: New Phase 1, Intf 12, IKE Peer 10.0.0.1 local Proxy Address 66.1.1.2, remote Proxy Address 10.0.0.1, SA (ESP-3DES-MD5) 6 03/02/2002 05:48:21.211 SEV=4 IKE/41 RPT=368 10.0.0.1 IKE Initiator: New Phase 1, Intf 12, IKE Peer 10.0.0.1 local Proxy Address 66.1.1.2, remote Proxy Address 10.0.0.1, SA (ESP-3DES-MD5) 7 03/02/2002 05:48:49.182 SEV=4 IKE/41 RPT=368 10.0.0.1 IKE Initiator: New Phase 1, Intf 12, IKE Peer 10.0.0.1 local Proxy Address 66.1.1.2, remote Proxy Address 10.0.0.1, SA (ESP-3DES-MD5)
Problems with User Authentication

Depending on your VPN authentication method, verify that you have a valid corporate username and password with the organization that manages authentication and controls the RADIUS servers, digital certicate servers, NT domain, and VPN 3000 concentrators.
Scenario 5: Extranet Issues
801

This scenario addresses the requirement for users that have a need to access their corporate network from a location outside of their corporate rewall, such as a customer site. These are the typical Extranet VPN situations. To ensure that your VPN works properly, it requires specic ports on your customers rewall to be open, and if they are not, your companys VPN concentrator will be unable to communicate with the VPN client. Simply put, these cases can be described as problems connecting through customers site rewall. The typical situation here is that an employee (user) from your company works on a customer site and tries to connect to the concentrator at your company, using your VPN software client (typically). The user can browse the web and ping the corporate rewall, but it cannot connect to the concentrator. When the user hits connect on the VPN client, it cycles through all the back-up concentrators and times out. The client initiates the ISAKMP key exchange but the concentrator cannot reach the client to accept it, and the client receives the error Remote peer no longer responding. Typically, most companies block the ports and protocols that VPN requires. In some cases, the rewall might need to allow the IP address of the concentrator that you are connecting to, but that depends on the type of rewall. The ports required to be open on a rewall to support VPN are as follows and are discussed in this section:
ESP 50 UDP 500 ISAKMP UDP 10,000 (Allow IPSec Through NAT) Tunnel keepalives Dead Peer Detection
In addition, the following issues are discussed:
Protocol 50ESP
All IKE 3.x clients require that ESP protocol 50 be enabled on the corporate rewall if encryption is specied in the groups transform, and all 2.x clients require it if encryption is specied in the VPN Group. Macintosh 3.x and 2.x clients also require ESP 50. For a more detailed explanation of ESP and ISAKMP and how they work, see Chapter 19, VPN Technology Background.
UDP 500ISAKMP
All IKE clients and LAN-to-LAN IKE tunnels require UDP Port 500 and their respective protocol to establish a tunnel. IKE negotiation uses UDP on port 500. Ensure that your access lists are congured so that UDP port 500 trafc is not blocked at interfaces that are
802
used by IKE and IPSec. In some cases, you might need to add a statement to your access lists to explicitly permit UDP port 500 trafc. If UDP port 500 is being blocked by your rewall, you are unable to establish a VPN tunnel.
UDP 10,000 (Allow IPSec Through NAT)

Unlike the other two ports, this port number is congurable on the VPN concentrator. You have the choice of using a number between 4001 and 49,151; the default is 10,000. See Figure 22-11 to determine where to modify the port number.
Figure 22-11 The NAT Port Number Congured on the Concentrator
NOTE
In version 3.5x of the VPN client, IPSec can be encapsulated in UDP or TCP packets, which enables secure tunneling through both NAT and Port Address Translation (PAT) devices and rewalls. This feature enables the VPN client to operate in an environment where the standard ESP, Protocol 50 or IKE, UDP 500 cannot normally function, or can only function with modication to the existing rewall conguration. This provides a signicant benet to users who want to VPN from within an external network. This feature does not work with proxy-based rewalls.
Tunnel Keepalives
In some cases, the VPN tunnel can drop when going through a rewall because the port on an ESP-aware NAT/Firewall closes after short periods of inactivity. To reduce the chance of the tunnel dropping, you can modify the .pcf le for that connection. Use a text editor to
803
open the .pcf le for the connection entry that you are using; the .pcf les are located under C:\Program Files\Cisco Systems\VPN Client\Proles. Then set the ForceKeepAlives=1. By turning on the ForceKeepAlive, you direct the VPN client to send IKE and ESP keepalives for a connection at approximately 20-second intervals. This signicantly reduces the risk of a rewall closing a port because of inactivity.
Dead Peer Detection

The Cisco VPN client supports the ability to dynamically connect to multiple gateways and uses IKE keepalives or Dead Peer Detection (DPD) to determine tunnel status. The introduction of PIX OS 6.x supports the version of keepalives used by the Cisco VPN client. The same method is used for immediate multiple peer failover with the PIX, as is used for the VPN 3000 series concentrators. The DPD protocol is the successor to the Keepalive protocol. These protocols systematically test the remote end of a VPN tunnel and notify their host when messages can no longer be passed. DPDs are passed every 30 seconds, and the concentrator drops the connection if it does not receive a reply within ve minutes. From the concentrator log, VPN administrators can see the DPD exchange with the VPN client (see Example 22-9). Both the client and the concentrator agree to use DPD.
Example 22-9
Concentrator Capture of the DPD Exchange and a DPD Disconnect

30 17:08:51.400 Peer supports DPD 01/25/2002 Sev=Info/5 IKE/0x43000001
<Output Omitted> 83 17:09:13.752 01/25/2002 Sev=Info/6 IKE/0x4300003D Sending DPD request to 10.3.3.3, seq# = 2948297981 84 17:09:13.752 01/25/2002 Sev=Info/4 IKE/0x43000013 SENDING >>> ISAKMP OAK INFO *(HASH, NOTIFY:DPD_REQUEST) to 10.3.3.3 85 17:09:13.758 01/25/2002 Sev=Info/5 Received ISAKMP packet: peer = 10.3.3.3 IKE/0x4300002F
86 17:09:13.758 01/25/2002 Sev=Info/4 IKE/0x43000014 RECEIVING <<< ISAKMP OAK INFO *(HASH, NOTIFY:DPD_ACK) from 10.3.3.3 <Output Omitted> 584 02/26/2002 17:03:02.300 SEV=4 IKE/123 RPT=35497 10.3.3.3 IKE lost contact with remote peer, deleting connection (keepalive type: DPD) ! Based on DPD keepalives, after 5 minutes of no response from the client, ! the concentrator drops the connection. <Output Omitted>
804
Extranet issues can vary, depending on software functionality. In the VPN client version 3.5x, there are additional encapsulation options for UDP or TCP, specically for NATbased connections (see Figure 21-5). This functionality can reduce rewall-related issues that users experience when trying to connect from an external network, such as a customers premises. Using the following ports are preferred because these ports are usually open in a companys rewalls: TCP port 80 (http), TCP port 22 (ssh), or TCP port 443 (https). Extranet issues can vary depending on the software functionality. In the VPN Client version 3.5x, additional encapsulation options exist for UDP or TCP, specically for NAT-based connections (see Figure 22-12). This functionality can reduce rewall-related issues that users experience when trying to connect from an external network, such as a customers premises. Using the following ports are preferred because they are usually open in a companys rewalls: TCP port 80 (http), TCP port 22 (ssh), or TCP port 443 (https).
Figure 22-12 TCP Encapsulation in a NAT Mode for Cisco VPN Software Client
Summary
805
Summary
The provided scenarios reect about 90 percent of the problems you face with Ciscos RA VPN solutions. This chapter is based on real world examples; everything you just read has been used in real situations. The chapter covers the following:
VPN 3000 software clientSeveral scenarios and cases on troubleshooting VPN client problems. MTUHow crucial the MTU is in regards to VPN and several methods to lower it. Software rewallsTroubleshooting problems with the VPN client and some of the better-known software rewalls in the market, such as ZoneAlarm. DNEWhat DNE is and its function with VPN. PPPoEWhat PPPoE is and how to get VPN to work several of the commonly used PPPoE clients. VPN 3002 Hardware clientHow to troubleshoot some of the larger problems.
As previously stated, this part does not include solutions that are not specically for enterprise remote access use. This part does not include any recently announced solutions or expected standards because they are not implemented, and consequently, there is no available information for possible troubleshooting issues. The information provided in Part V, VPN reects troubleshooting practices for remote access VPN solutions that are currently in production at the time of writing this book.
APPENDIX
Answers to Review Questions

This appendix contains the answers to the review questions at the end of each chapter (except for the scenarios chapters). Some questions might have multiple correct answers. In those cases, the best answer is supplied here with an explanation. The questions are repeated here for your convenience.
Chapter 1
1 Why are remote access networks considered the most difcult type of network to
support? Many of the components of the remote users location are not under an enterprises control.
2 What are the main categories that the management should consider when making
remote access service decisions? Cost, availability, support, in-source versus out-source, and billing.
3 Give an example for narrowband, baseband, and broadband services.
Narrowband and baseband are synonyms and refer to legacy POTS and nonvideo-capable systems. Cable modems are typical broadband systems.
4 Explain what MMDS and LMDS stand for.
Multichannel Multipoint Distribution System (MMDS) and Local Multipoint Distribution Service (LMDS) are wireless broadband technologies for Internet access.
5 Name two benets of dial-in modem technology for remote access.
Backward compatibility and high availability for minimum cost.

6 Name two limitations of dial-in modem technology for remote access.
Dial-in modem technology has reached its theoretical maximum and has a low speed.
808
Appendix A: Answers to Review Questions
7 Name two benets of ISDN for remote access.
The technology is dened as a viable alternative when the end user requires more bandwidth than dial-in. Also, it has a variety of data and voice services.
8 Name two limitations of ISDN technology for remote access.
Interface compatibility limitations and cost.

9 Name two benets of Frame Relay for remote access.
Provides peak bandwidth availability and lower response time.

10 Name two limitations of Frame Relay technology for remote access.
The cost and when run over T1 circuits it inherits the limitations of T1s for repeaters in every mile.
11 Name two benets of VPN for remote access.
The expected cost reduction and unprecedented mobility.

12 Name two benets of cable modems for remote access.
Enormous bandwidth that can be shared between many users. Cable modems that are based on coax cable eliminate most traditional copper-based network problems.
13 Name two benets of xDSL for remote access.
It offers great data rates and a variety of services.

14 Name two limitations of wireless and satellite for remote access.
High latency and security issues.
Chapter 2
1 What does Shannons Law state?
Shannons Law states that error-free transmission is possible as long as the transmitter does not exceed the channels capacity.
2 What does the Nyquist sampling theorem state?
The Nyquist theorem states that digital sampling must take place at twice the highest frequency, to reconstruct the analog signal accurately.
3 What does DMT stand for? How many subchannels does the standard (ANSI) ADSL
dene? DMT stands for Discrete Multitone. The standard (ANSI) ADSL system divides the frequency spectrum into 256 subchannels (subcarriers).
Chapter 2
809
4 Why is CAP modulation sometimes called suppressed QAM?
Because, unlike QAM, CAP is not sending the carrier over the line.
5 What is the typical speed in the 802.11b standard? What coding techniques provide
these speeds? 1 and 2 Mbps with 11-bit Barker code. 11 and 22 Mbps with Complementary Code Keying (CCK).
6 How wide is the high carrier in 802.11a; how many subchannels does it have, and how
wide is each subchannel? Each high-speed carrier is 20-MHz wide and is broken up into 52 subchannels, each approximately 300-kHz wide.
7 How does the 802.11g standard relate to 802.11a and 802.11b?
802.11g uses the same OFDM technology as 802.11a and operates in the same 2.4-GHz band as 802.11b.
8 What is the relation between the terms clocking, timing, and synchronization?
Clocking refers to both timing and synchronization.

9 What interface uses the pseudo-ternary coding technique? What is the size of the
frame? The S/T interface. The size is 48 bits.

10 What does 2B1Q stand for and which interface does it use? What is the size of the
frame? Two binary one quaternary (2B1Q) over the U-interface. The frame is 240 bits in length.
11 What is perfect scheduling in the physical layer?
Perfect scheduling is the interaction between the E-bit and D-bit of the frame of the S/T interface that provides a contention mechanism called perfect scheduling.
12 How do T1 circuits meet the ones density requirements?
By using zero-suppression schemes.

13 Explain how the 24 framing bits in ESF are broken down and how they are used.
Of the 24 framing bits in an ESF, 6 bits are used for synchronization, 6 bits for error checking, and the remaining 12 bits are used for a 4-kbps facility data link (FDL).
810
Chapter 3
1 Is Asynchronous Transfer Mode (ATM) a synchronous or asynchronous technique?
Explain. It is a synchronous technique. The word asynchronous in ATM is not associated with embedded start-stop techniques, but with sporadic presence of user data.
2 Name three of the advantages of digital signaling over analog signaling?
Better quality of service; simplied maintenance; synergy with digital switching.

3 What does FDM stand for? What rule does FDM obey?
FDM stands for frequency-division multiplexing and obeys the rule some bandwidth all of the time.
4 In North America, how many voice channels are in a standard multiplexing scheme
for FDM? For North America, a standard voice multiplexing scheme is 12 voice channels, 4 kHz each, totaling a bandwidth from 60 to 108 kHz.
5 Describe the main phases of pulse code modulation (PCM).
Sampling, quantization, and coding. The rst two functions are performed by a codec device, and the coding is performed by a DSU/CSU.
6 What does TDM stand for? What rule does the TDM obey?
TDM stands for time-division multiplexing and obeys the rule all the bandwidth, some of the time.
7 What is the purpose of bit number 193 in TDM?
Bit number 193 is a framing bit; it is used for time synchronization.

8 What is a frame in TDM?
A frame is a sequence of time slots, each containing a sample from one of the channels.
9 What do DS1 and DS-1 stand for? What is the difference between DS1 and DS-1?
DS1 stands for digital service 1, which is a digital interface with a 1.544-Mbps data rate. DS-1 stands for digital signal level 1, which is a framing specication for transmitting digital signals at 1.544 Mbps on a T1 facility in the U.S.
Chapter 4
811
10 What is out-of-band signaling? What is robbed bit signaling?
Out-of-band signaling uses frequencies outside of the normal frequency band for signaling; it is the core of SS7. In contrast, in-band signaling relies on using certain bits out of the frame format in the frequency band, which is why it is sometimes called robbed bit signaling (RBS).
11 What do CO, LEC, CLEC, and ILEC stand for? What do they have in common?
CO stands for central ofce, LEC is local exchange carrier, CLEC is competitive LEC and ILEC stands for incumbent LECs. All of them belong to the rst tier of exchange carriers.
12 What is the role of tandem switches in carrier networks?
The secondary switch, called the tandem, provides a trunk-to-trunk switching for both LECs and IXCs.
13 What are the main caveats when the enterprise outsources service with the service
provider? They include the commitment of the other party and control of the information.
14 What are the three main topologies in Ciscos Ethernet to the First Mile (EFM)?
Ethernet over point-to-point copper; Gigabit Ethernet over point-to-point optical ber; point-to-multipoint optical ber topology.
15 What does CDMA stand for? Name the 3G minimum speed requirements, as dened
by ITU. CDMA stands for Code Division Multiple Access. 3G, 144 kbps mobile, 384 kbps walking, 2.4 Mbps stationary.
Chapter 4
1 What is the name of the layer above the network layer in the DoD model?
Host-to-host layer.
2 Name at least one keyword for each of Layer 2, Layer 3, and Layer 4 of the OSI
model. Layer 2: Frame; Layer 3: Packet; Layer 4: Segment.

3 What is the communication subsystem in the seven-layer OSI model?
The communication subsystem includes the rst three layers of the model.
812
4 What is the baseline of the system?
The baseline is the expected behavior of the system.

5 Name at least ve of the key concepts in the troubleshooting process.
Baseline, topology, gathering, tools, and solutions.

6 What are the complete and the shortest IOS commands to save the running
conguration to the NVRAM? The complete command is #copy running-cong startup-cong. The shortest command is #wr.
7 What are the complete and the shortest IOS commands to cancel all debugging in the
router? The complete command is #undebug all. The shortest command is #u all.
8 Why does the CDP use a multicast address?
Using a multicast address prevents routing because Cisco routers do not forward this trafc, unless specically congured.
9 When troubleshooting the serial interface, you see HDLC protocol type 0x2000, what
is it? HDLC protocol type 0x2000 stands for CDP protocol.

10 Is it recommended that you disable the CDP over the dialer interface? If so, what is
the command? The extensive information from CDP output requires the CDP to be disabled in interfaces, which cannot be controlled or user-owned. The command is #no cdp enable.
11 What is the measurement of the spread when measuring the path characteristics with
Pchar? The standard deviation.

12 What does ICMP type 3 mean?
ICMP type 3 means Destination Unreachable.

13 What is the command to see the statistics when using Service Assurance Agent
(SAA)? #show rtr collection-statistics
Chapter 5
813
Chapter 5
1 Name two added features in ITU-T V.92 standard, compared to ITU-T V.90.
Modem on Hold and Quick Connect.

2 Name two limiting factors for the ability of the modem to connect.
The distance from the central ofce and the signal-to-noise ratio.
3 If the SNR is 40, how many times higher is the signal strength than noise strength?
100.
4 How would you troubleshoot a case in which a pad of 3dB might be the root of the
problem? Make a long-distance call to the same number and see if the quality is better.
5 If AMI needs to transmit the octet 1 0 0 1 0 1 1 0, and the rst mark is +, what are the
next marks? Write the entire octet. +00-0+-0.

6 If the preceding LSB in B8ZS is positive, what is the combination for 00000000?
000+-0-+.
7 What is the main disadvantage of dial-back authentication?
This type of authentication requires a xed phone number, which cannot be used by travelers.
8 Name the main phases of the PPP protocol.
Link Dead, Link Establishment phase, Authentication phase, Network-Layer Protocol phase, Link Termination phase.
9 What is the value 0xC223 in the protocol eld of PPP?
0xC223Challenge Handshake Authentication Protocol (CHAP).

10 Which protocol in the PPP suite establishes and congures the data-link connection?
Link Control Protocol (LCP).

11 What is the address eld value of the PPP protocol?
11111111.
12 Which packet types of LCP terminate the data-link connection?
05, Terminate request; and 06, terminate acknowledgement.
814
Chapter 6
1 List three ways for using dial as a backup solution.
Using a backup interface, using a oating static route, and using a dialer watch.
2 What is the main advantage of the dialer watch solution?
The router dials immediately when the primary route is lost. It does not depend on line protocol, encapsulation, or interesting trafc.
3 What is the line conguration command to congure a modem to use the modemcap
usr_sportster?
Router(config-line)#modem autoconfigure type usr_sportster
4 What is the global conguration command to dene a group named dial as a
TACACS+ group?
Router(config)#aaa group server tacacs+ dial
5 What is the default protocol and port number of RADIUS authentication and
accounting? UDP 1645 and UDP 1646.

6 What is the line conguration command to automatically select the PPP protocol
during text authentication?

Router(config-line)#autoselect ppp
7 What is NFAS and what is its function?
Non-Facility Associated Signaling (NFAS) allows a single D channel to control multiple PRI circuits.
8 What is the interface conguration command to ensure that voice calls are sent to a
modem?
Router(config-if)#isdn incoming-voice modem
9 What is the purpose of the command no exec?
It prevents a person from obtaining a login prompt when they connect to a line on which it is congured.
10 What is the best way to test a backup solution?
Physically unplug the cable from the main interface.

11 How would you connect to a network access server to connect as a text dial-out
device? Telnet or Secure Shell (if enabled).

12 True or False: PC software is required to use a router to perform PPP dial-out.
Chapter 7
815
False. PC software is only required to attach a network modem to a virtual communications port for dial-out.
13 What is the most scaleable way to use large-scale dial-out?
Store the client information and phone numbers on an AAA server.

14 What is the main purpose of a group-async interface?
It allows you to consolidate many async interfaces into a group for ease of conguration.
15 What does the interface command group-range do?
It species which lines are part of the group-async interface.
Chapter 7
1 What SQ value shows up in the output of show modem operational-status,
indicating the most stable connection possible? 0.

2 True or False: Upgraded modem rmware does not have to be stored in ash after it
is copied to the modem. False. The router needs to access the version in ash at the next maintenance period or when the router is reloaded.
3 What is the controller conguration command required to correctly congure the
distance of a circuit that is 639 feet?

Router(config-controller)#cablelength short 655
4 If you are receiving a blue alarm, what bit pattern is the equipment receiving?
All 1s.
5 What color is an alarm in which the controller status shows Receiver has loss of
Frame? Red Alarm.

6 What happens if one end of a T1 receives a yellow signal?
A Yellow Alarm is declared because of an incoming yellow signal from the far end. In effect, the circuit is declared to be a one-way link.
7 What information is negotiated in the IPCP stage of NCP of a modem dial call?
IP address, WINS address, and DNS address.
816
8 What modem AT command shows the connection information for a call that was
previously disconnected? ATI11.

9 What does BERT stand for?
Bit error rate tester.

10 What is the primary advantage that the AS5300 MICA modems have over the
Microcom modems in the AS5200 series? With out-of-band signaling, the router has access to real-time data while the modem is connected.
11 What does the call timer show?
The duration of the current active call in seconds.

12 What command on an AS 5200 and AS5300 shows a summary of all disconnect
reasons and the number of disconnects for every reason? #show modem call-stats.
13 What does CSM stand for and what is the command to show the processes of this
device? CSM stands for call switching module. The #debug modem csm command starts call switch module debugging.
Chapter 9
1 What is the scope of the I.431 and I.432 standards?
I.431 denes the Primary Rate Interface, and I.432 denes the Basic Rate Interface.
2 Where does the name D channel come from? What are the operational speeds of the
D channel for BRI and PRI? The name D channel comes from Delta. It operates at 16 kbps for BRI and 64 kbps for PRI.
3 What is a V-reference point in ISDN?
A V-reference point denes the interface in a Local Exchange (LE) between the Local Termination (LT) and Exchange Termination (ET).
4 What are the important pins in a S/T interface?
3, 4, 5, and 6.
Chapter 9
817
5 What is the modulation of the ISDN U-interface?
The U-Interface uses frequency-division multiplexing and echo cancellation.

6 What is the bit rate of the S/T interface and U-interface?
S/T interface192 kbps; U-interface160 kbps.

7 How many INFO messages participate in the BRIs Layer 1 initialization? What does
INFO0 mean? INFO0 to INFO4; INFO0 means no signal.

8 Which bit in the ISDN frame indicates line activation?
The A bit set to 1 indicates the activation of the line.

9 What makes up DLCI in ISDN? What is the length of DLCI, TE, and SAPI?
TEI and SAPI in the LAPD protocol represent the 13-bit data-link connection identier (DLCI). TEI is 7 bits; SAPI is 6 bits.
10 What are the two indicators that Layer 2 is active?
Receiving a UA message with SAPI = 0 or TEI = xxx, where xxx is not 0 or 127.
11 What does TE = 127 mean?
TEI = 127 is a broadcast.

12 What is the dynamic range of TEI?
TEI ranges from 64126.

13 What does SAPI = 0 indicate?
Call control procedure.

14 How do you distinguish an incoming from an outgoing call?
Check the reference ag in the Q.931 message. A message of 0 is sent by the call originator, and 1 means that the message was sent by the other party.
15 Which ISDN protocol provides information about Bearer capability. Name three basic
types of Bearer capabilities. Bearer capability is part of the format of the ISDN Q.931 protocol, which provides information for the type of the call56-kbps data, 64-kbps data, or 56kbps voice.
818
Chapter 10
1 Name the most common ISDN switch types in the U.S. and Canada.
basic-5ess, basic-dms100, basic-ni1.

2 Type a command that sets up the switch-type NI1 for a Cisco IOS Software ISDN
router in global conguration mode. Router(cong)#isdn switch-type basic-ni

3 Type a command to dene a local pool of 63 IP addresses for your core router, starting
with 20.18.15.1, if the pool name is LOCAL_POOL. router(cong)#ip local pool LOCAL_POOL 20.18.15.1 20.18.15.62
4 What is the theoretical maximum number of ports in PAT?
The total number of these ports is theoretically 216 = 65,536.

5 How much memory consumes one NAT translation?
Each NAT translation consumes about 160 bytes of memory.

6 Name at least ve protocols that are supported by Cisco IOS Software NAT.
HTTP, TFTP, Telnet, Archie, Finger, NTP, and NFS.

7 In the case of the virtual interfaces, what happens with the route when the connection
is tear-down? In the case of the virtual interfaces, because of his dynamic nature, the route is gone as soon as the connection is gone.
8 Name three main functions of multilink systems.
Multilink systems must do the following: receive PDUs of a negotiated size; combine multiple physical links into one logical link (bundle); receive and reassemble upper-layer protocol data units (PDUs).
9 Why would you use multilink PPP between a remote ofce and corporate
headquarters? To increase bandwidth and reduce network latency.

10 On which interface types can you use multilink PPP?
On any interface that supports DDR rotary groups and PPP, including ISDN, synchronous, and asynchronous lines.
11 What does the MRRU stand for and at which stage of the PPP protocol is it used?
MRRU stands for Maximum Received Reconstructed Unit (MRRU). It is used during LCP negotiation to indicate to its peer that it is willing to be included in the multilink bundle.
Chapter 11
819
12 What is the purpose of using the endpoint discriminator (ED) option in MP?
The ED option determines which bundle to add the link to, and its primary use is to generate uniqueness in identifying MP bundles.
13 What Cisco IOS Software command displays the status of the stack group members?
The show sgbp command displays the status of the stack group members.
14 Name the ve possible states of the peer in the stack-group.
The ve possible states for a peer in the stack-group are the following: IDLE, CONNECTING, WAIT_INFO, AUTHOK, and ACTIVE.
Chapter 11
1 Type a command to determine if the spoong is enabled in dialer interface in Cisco
IOS ISDN router. Router#show interfaces dialer 1 I should see on the very rst line of the output: Dialer1 is up (spoong), line protocol is up (spoong).
2 Dene the active period in snapshot routing. Is it congurable? What is its duration?
The active period is a time slot when the routing protocols updates can be sent over the interface. It is congurable and can be between 5 and 100 minutes.
3 In a snapshot routing conguration, use an IOS command to ensure termination of a
quiet period within two minutes. Router#clear snapshot quiet-time interface

4 What are the main elements of the dialer proles in DDR?
The main elements of dialer proles include dialer interfaces, dialer pools, physical interfaces and dialer map class (optional).
5 Use an IOS command to map the IP address 161.3.2.1 with the destination phone
number 773-5555. Router(cong-if)#dialer map ip 161.3.2.1 name gateway broadcast 7735555

6 Dene the Dialer1 as a member of pool number 3 with the highest priority.
Router(cong-if)#dialer pool-member 3 priority 255

7 Create an ACL to deny tcp trafc on port 8008. Type the appropriate IOS command.
Router(cong)#access-list 101 deny tcp any any eq 8008
820
8 Congure the users IOS router for callback with 200 packets in the queue and 20
seconds drop time. Explain. The correct conguration is Router(cong-if)#dialer hold-queue 200 timeout 20 under the dialer interface. The dialer hold-queue 200 timeout 20 species that up to 100 packets can be held in a queue until the core router returns the call. If the core router does not return the call within 20 seconds plus the length of the enable timeout on the central site router, the packets are dropped.
9 In a callback conguration, type the IOS command, specifying that the core router
interface will wait ve seconds after disconnecting the initial call before making the return call. Router(cong-if)#dialer enable-timeout 5
10 Type the IOS command to bring the second B channel up after the inbound trafc
exceeds 20 percent. 804-isdn (cong-if)#dialer load-threshold 51 inbound

11 What conditional priority means in voice features conguration of ISDN?
Conditional means that voice call bumps data call only if the user has two data connections in the same direction; otherwise, the calling party receives a busy signal.
12 If the users router has two data calls in progress and it is congured with
Router(cong)#pots dialing-method enblock, what should you expect when making a voice call to any of his LDNs? Initially expect to hear a dial tone, then a busy signal, if the voice priority is not set up to Always.
Chapter 12
1 What is the command to see the status of the D channel of the IOS-based ISDN
router? In which mode of the IOS router can you type the command? The command is show interfaces bri 0. The command is available for both privileged and user modes.
2 If you want to see what IP address has triggered the last call in Cisco 77x router, what
command should you type? The command is

Router>show packet
Chapter 12
821
3 What do you look for in the output of the IOS command Router#sh isdn status to be
sure if the physical layer in BRI is functional? Look for Layer 1 Status: ACTIVE. Any other message shows physical layer issues.
4 What IOS command enables you to distinguish between internal and external ISDN
issues? The IOS command is Router#debug bri. If the router is sending requests for establishment of the activation bit and the response is not coming back, the possible issues are external. If there is no request from the router, concentrate your attention to it.
type? The command is

Router#debug isdn Q921
6 Under normal circumstances, what messages should you not see from the output of
Router#debug isdn q921? Under normal circumstances, you should not see SABME, IDREQ, and IDASSN messages. Otherwise, you have a clear indication that Layer 2 is trying to reinitialize.
7 What are you looking for in the output of the IOS command Router#sh isdn status to
be sure if Layer 2 is functional? First, TEIs = number, where the number has to be between 64 and 126. Second, SAPI has to be 0. Third, every line should have State = MULTIPLE_FRAME_ESTABLISHED.
8 In the output from the command Router#debug isdn q921, what does TX ->...ai = 127
mean? ai = 127 means that the BRI is broadcasting and requesting TEI assignment from the ISDN switch.
type? The command is

Router#debug isdn q931
10 What is the bearer capability in Q931 messages for 64 kbps data, 56 kbps data, and
voice calls? 8890 for 64 kbps data call. 0x8890218F means it is a 56-kbps data call. 0x8090A2 means it is a voice call.
822
11 What is the name of the message indicating that the LCP negotiation is successful?
Incoming message CONFACK.

12 What is the recommended IOS command to troubleshoot the dialer trafc when the
router makes outgoing data calls? The command is

Router#debug dialer packets
13 How many lines of PPP CHAP negotiation indicating success can you see in the
output of #debug ppp authentication? Two lines if the CHAP negotiation is two ways: one for incoming and one for outgoing. If it is one-way CHAP negotiation, theres only one incoming line.
14 If you receive cong nack during the PPP authentication negotiation, what does it
mean? It means that one side is congured for PAP, but the other is congured for CHAP authentication.
15 When testing the voice features, what are the two recommended IOS commands you
can use? The commands are

Router#debug pots csm Router#debug pots driver
Chapter 14
1 Does Frame Relay perform ow control over the frames?
No, Frame Relay drops frames on congestion.

2 Name the FRF implementation agreement that governs data compression over Frame
Relay. FRF.9.
3 Dene the main components of the full LAPF protocol.
The full LAPF protocol includes core LAPF and control LAPF.
4 Name the components of the Frame Relay format.
Beginning and ending Flag eld, Address eld, Information (Data) eld, and FCS eld.
5 What is the maximum frame size that FCS can provide error detection for?
The FCS code provides error detection for frames up to 4096 bytes in length.
Chapter 15
823
6 What is the zero-insertion procedure and why is it necessary?
Zero-insertion is looking for non-ag data pattern 011111. It inserts a zero to distinguish between ags and data.
7 How many DLCI Address eld formats are available?
The default Address eld format is 2 bytes or 10 bits. The extended address frame format can be 3 bytes (16 or 17 bits) or 4 bytes (23 bits).
8 What does the DE bit stand for and who can set it?
Discard eligible (DE) indicates the importance of the packet. It can be set by the user and by the network.
9 Name the LMI numbers for Consortium and AnnexD specications.
Consortium uses DLCI = 1023 for LMI. AnnexD uses DLCI = 0 for LMI.
10 What is the main difference between the core format and control protocol format of
LAPF? The main difference between the core format and the control protocol format is the control eld.
11 Name the four categories of signaling messages of the LAPF control protocol.
LMIs, T1.617 AnnexD messages, CLLM messages, and SVC messages.

12 What is the purpose of the Dummy Call Reference in the Q.931 header?
To indicate that the message is not a call establishment, disconnect, or status message.
Chapter 15
1 Dene the term access rate (link speed).
The link speed determines how rapidly (maximum rate) the end user can inject data into a Frame Relay network.
2 What is the recommendation for setting the committed interval Tc in Frame Relay?
Tc should be set to four times the end-to-end transit delay.

3 Dene the committed information rate (CIR).
CIR is the allowed amount of data that the network is committed to transfer under normal conditions.
4 Dene the excess information rate (EIR).
EIR identies the bits transmitted per second, over the time period of Tc, which are beyond the committed information rate.
824
5 Dene the explicit congestion notication types.
Normal, mild, and severe congestion.

6 What is the area of operation of UNI in Frame Relay.
The UNI operation area is locally dened between the DTE/DCE peers.
7 Dene the area of operation of NNI.
The NNI interface is concerned with the transfer of information between two network nodes that belong to two different Frame Relay networks.
8 Name the three Frame Relay multicast messages.
Addition, Deletion, Presence.

9 If n is the number of connected routers, dene the number of physical connections in
a full-mesh topology. n (n 1) / 2.
10 Name the two main methods to control congestion in Frame Relay networks by using
explicit notication. Rate adoption algorithm and consolidated link-layer management (CLLM).
11 What is transit delay? How do you obtain a rough estimate of transit delay?
This term refers to the time to send a frame across the link between two points. The delay is a function of the access rate of the link, distance, and the size of the frame. A rough estimate can be obtained by the equation Delay = frame size / link access rate.
12 Name the four main specic and common specications of LMI.
Virtual circuit status messages, multicasting messages, global addressing messages, and simple ow control.
13 Name the three LMI types that are supported by Cisco.
Cisco, ANSI, Q.933a.

14 Can InARP run without LMI?
No, because InARP LMI messages determine which PVC to map.
Chapter 16
1 What is dynamic mapping?
Using Inverse ARP to request the next hop protocol address for a specic DLCI.
Chapter 16
825
2 For Router-frame, map the IP address 10.0.0.1 to DLCI = 100, using the IETF
encapsulation.
Router-frame(config-if)#frame-relay map ip 10.0.1.1 100 broadcast ietf
3 Can you use IP unnumbered with Frame Relay?
You can, but you must use point-to-point subinterfaces and static routes or dynamic routing for your trafc to get routed.
4 Can you ping your own interface address? Can you ping one spoke router from
another? In point-to-point interfaces, you can. In point-to-multipoint interfaces, you cannot, unless you congure Frame Relay map.
5 What happens to deleted subinterfaces?
Deleted subinterfaces show up as deleted until the router is reloaded.

6 In point-to-point congurations that are running EIGRP, type the command for
Router-frame that prevents all routing updates for interface Serial3/0:0.64?

Router-frame(config)#passive-interface Serial3/0:0.64
7 Congure the Frame Relay broadcast queue for Router-framesubinterface S3/
0:0.71 with queue size 100, byte rate 1200, and packet rate 120.
Router-frame(config-if)#frame-relay broadcast-queue 100 1200 120
8 Can you congure the Cisco router as a DCE?
You can, if you use the frame-relay intf-type [dce | nni] command in the general conguration mode.
9 Under the interface Serial3/0:0.200, what is the backup delay command with enable
delay = 5 seconds and disable delay = 10 seconds?

Router-frame(config-if)#backup delay 5 10
10 For Router-frame and interface Serial1, what is the command for TCP header
compression, which is active only for the destinations that are sending compressed headers?
Router-frame(config-if)#frame-relay ip tcp header-compression passive
11 For Router-frame and interface Serial4/2:0.200, dene that FRF9 payload
compression will be performed on CSA 3.

Router-frame(config-if)#frame-relay payload-compression FRF9 stac csa 3
12 Enable the multicast routing in Router-frame.

Router-frame(config)#ip multicast-routing
826
13 In Router-frame, for interface Serial4/2:0.100, dene the upper limit of the rate for
trafc shaping to 128000.

Router-frame(config-if)#traffic-shape rate 128000
14 What Frame Relay timer denes the Cisco autosense feature? How do you congure
it? N391. At every N391 interval, LMI autosenses the LMI type. The default is 6 attempts in 60 seconds. It is congurable with the command frame-relay lmin391dte value.
Chapter 17
1 What are the signals on the physical layer provided by DTE?
Data Terminal Ready (DTR) and Request To Send (RTS).

2 What are the two available options for 56-kbps congurations for Cisco routers?
56-kbps DSU/CSU and 56-kbps switched modes.

3 In the command service-module 56k network-type dds, what is DDS and what are
the data rates provided by DDS? DDS stands for Dataphone Digital Service and provides rates between 2.4 Kbps and 56 Kbps.
4 Serial 1 is congured with the command service-module t1 timeslots 1-2. What is
the congured bandwidth on Serial 1? 64 2 = 128 kbps.

5 Name the WIC T1 Pinouts (8 pin RJ48S).
1, 2, 4, and 5.
6 What is the command to loopback your equipment?
loopback dte
7 Name two checkpoints for a failing CSU.
Line or internal clocking and impedance mismatch.

8 In the show frame-relay map IOS command, if the DLCI is dened and active, what
does this mean? The message dened and active indicates that the DLCI can carry data and that the router at the far end is active.
Chapter 19
827
9 What happens with the incoming DLCI in the switch?
The incoming DLCI number changes to match the far-end of the connection. Before sending the frame, the switch recalculates the new FCS and replaces this portion in the outgoing frame. It then sends the frame out.
10 How do you know if the DLCI is active but not congured in the router?
Type #show frame-relay pvc and check for an unused, active non-zero value.
11 Under what conditions does the properly congured LMI in a Cisco router not send
packets over the DLCI? When the PVC is listed as inactive or deleted.
12 Which LMI message reports the PVC status for each PVC congured on the
interface? The full status message.

13 What is the order of the Cisco LMI autosense full status enquiry message?
The order is ANSI, ITU, and Cisco.

14 How are Num Status Enq. Sent, Num Status msgs Rcvd, and Num Status
Timeouts related in erroneous conditions? In erroneous conditions Num Status Enq. Sent = Num Status msgs Rcvd + Num Status Timeouts.
15 When debugging the serial interface, what does the message illegal serial line type
xxx mean? The message indicates that the encapsulation is Frame Relay or HDLC, and the router attempts to send a packet with an unknown packet type.
Chapter 19
1 Name the major VPN types of Cisco Enterprise VPN solutions?
The major Cisco Enterprise VPN solutions are Cisco remote access VPN, Cisco site-to-site VPN, and extranet VPN solutions.
2 What ports need to be open in the corporate rewall to ensure PPTP functionality?
TCP port 1723 and the GRE protocol ID 47.

3 What is the purpose of control messages in the L2TP protocol?
Control messages are used in the establishment, maintenance, and clearing of tunnels and calls.
828
4 Dene voluntary mode and compulsory mode in PPTP-based VPN.
When a remote user starts the tunnel, it is called voluntary mode. When the initiation of the tunnel is done by the NAS, it is often referred to as compulsory mode.
5 What is the minimum set of negotiable attributes in IKE SA?
The minimum set of negotiable attributes are the encryption algorithm, hash algorithm, authentication method, and information about a group over which to perform the Dife-Hellman key exchange.
6 What does SPI stand for in IPSec?
SPI stands for security parameter index and is a 32-bit number assigned to the initiator of the SA request by the receiving IPSec endpoint.
7 What are the valid authenticating methods in IPSec?
The valid authenticating methods in IPSec are preshared key, digital signature standard (DSS) signatures, RSA signatures, encryption with RSA, and revised encryption with RSA.
8 What is the main difference between main mode and aggressive mode?
Aggressive mode is used when identity protection is not needed.

9 What is the main difference between transport mode and tunnel mode in IPSec?
In transport mode, only the IP payload is encrypted and the original IP headers are left intact. In tunnel mode, the entire original IP datagram is encrypted and it becomes the payload in a new IP packet.
10 Dene the unidirectional and bidirectional security associations (SA). What kind of
SA is an IKE SA? An IPSec SA? Unidirectional means that, for two-way communication between devices, there must be at least two SAsone in each direction. The term bidirectional means that, once established, either party can initiate Quick Mode, Informational, and New Group Mode exchanges. IPSec SA is unidirectional; IKE SA is bidirectional.
11 What is ICV and how is it calculated?
ICV stands for Integrity Check Value (ICV). The computation of ICV is over IP header elds that are either immutable in transit or that are predictable in value upon arrival at the endpoint for the SA.
12 Which ports have to open in the companys rewall to ensure ISAKMP, ESP, and AH
operation? ISAKMP: UDP port 500; ESP: protocol 50; AH: protocol 51.
Chapter 20
829
13 What is the advantage of XAUTH among other authentication methods? What is type
1 authentication in XAUTH? XAUTH is designed in a way to provide a method to leverage legacy authentication methods that are widely deployed today with existing and future authentication mechanisms. Type 1 authentication in XAUTH is RADIUS-CHAP.
14 What is the size of the prime in DH Group 5?
1536 bits (600h).

15 What does PFS stand for? Explain PFS.
PFS stands for perfect forward secrecy (PFS). In PFS, a shared secret encryption key can be calculated that has no relationship to the preceding key.
Chapter 20
1 Why is the AH protocol considered less secure than ESP?
AH does not provide data condentiality.

2 Which part of the ESP packet is not protected?
ESP does not protect the new IP header.

3 What is a one-to-many NAT or PAT?
A one-to-many NAT or PAT consists of one external address being mapped to many internal addresses.
4 What is split tunneling?
Split tunneling is a feature that allows clients to simultaneously send and receive data across a VPN tunnel, while also communicating directly with resources on the Internet.
5 Name the three main types of rewalls.
Packet lter, proxy, and stateful inspection rewalls.

6 Describe how to calculate the session load on the VPN concentrator.
The session load per concentrator is the total number of active connections divided by the maximum number of sessions congured on the concentrator.
7 What does VRRP stand for?
VRRP is Virtual Router Redundancy Protocol (VRRP), which is a standard proposed by IETF that provides IP routing redundancy. It is designed to provide transparent fail-over at the rst hop IP router.
830
8 What is Reverse Route Injection?
Reverse Route Injection is when the concentrator is congured to advertise routes on the private interface by using OSPF or RIP.
9 What is the Group Lock conguration in a VPN concentrator?
Group Lock allows users to be authenticated only if they are members of a particular group.
10 Name the two mandatory settings on your VPN client.
Host name or IP address of remote server and authentication parameters.

11 Dene the network extension mode for the VPN 3002 Client.
Network Extension mode is when the private interface is congured with an IP address that is routable in the network connected to the concentrator that is terminating the VPN tunnel.
12 For the Router-EzVPN, type the IOS command to start the XAUTH login sentence.
Router-EzVPN#crypto ipsec client ezvpn xauth
13 When typing the IOS command show crypto ipsec client ezvpn, how do you nd out
if IPSec is up and running? Check for the line IPSEC_ACTIVE in the output.
14 In PIX 501, how do you check if you are running client mode, or network extension
mode? Type PIX#show vpnclient and look for a line that starts with vpnclient mode.
Chapter 21
1 What are the rst three steps to check if the user never receives an Authenticating User
prompt during the initial dialer connection attempt in the VPN software client? Check if the Internet connection is okay, if the group name and group password are correct, and if the DNS service is resolving the name of the concentrator.
2 What is the CVPND event class and what is its purpose?
CVPND is Cisco VPN Daemon (main daemon), which starts client service and controls messaging process and ow.
3 Name the main severity categories in the Cisco VPN concentrator?
Fault, Warning, Information, Debug, and Packet decode.
Chapter 21
831
4 In a 3002 HW VPN client, the user is authenticated but cannot pass any data. What
are two possible reasons? The correct client mode was not selected, either Network Extension or Client mode. If Network Extension mode is used, another client might have an overlapping subnet.
5 Which severity level events are displayed by default on the VPN HW 3002 client?
By default, the VPN 3002 displays all events of severity level 1 through 3 on the console.
6 How do you proceed if a NAT/PAT conguration already exists in the router and you
are about to congure an easy VPN client? Remove any manual NAT/PAT conguration on the router before conguring the easy VPN client.
7 What is the command for the Easy VPN client to reset the VPN connection?
The command is
Router-EzVPN#clear crypto ipsec client ezvpn
8 What is the command for Easy VPN to check the status of the Cisco Easy VPN client
prole? The command is

Router-EzVPN#show crypto ipsec profile
9 To verify the applied policy in Cisco Easy VPN, what command do you use?
The command is
Router-EzVPN#show crypto isakmp policy
10 In the PIX-based VPN client, how do you verify if the VPN client is active?
Type PIX#show vpnclient and look for the line vpnclient enable.
11 In the PIX-based VPN client, how do you check that the VPN tunnel has been
established? Type the command Router#show crypto isakmp sa, and look to see if the created entry has a non-zero value.
12 What are two debug commands to debug the PIX-based VPN establishment of IPSec
and ISAKMP? The commands are

Router#debug crypto ipsec sa Router#debug crypto isakmp sa
832
13 What parameters dene the PPPoE session uniquely?
The PPPoE session ID and the peers Ethernet address.

14 Name the modulation techniques for the DOCSIS 2.0 standard.
The modulation techniques for DOCSIS 2.0 include S-CDMA (synchronous code division multiple access) and A-TDMA (advanced frequency agile time division multiple access).
15 If the TCP protocol is notied for packet loss, how does it react?
The packet loss for TCP is an indication of congestion. It reduces transmission rates drastically until an optimal rate is found.
5259IX.fm.1 Page 834 Friday, October 11, 2002 11:07 AM
INDEX
Numerics
108 Bert Test, 132 11-bit chipping, 50 22 second issue (ISDN), resolving, 387396 2B+D, 238 2B1Q (two binary one quaternary) signaling, 55, 5859 3G wireless, 9192 56-kbps ex modems, 14 5ess switch types (ISDN), 259260 5-GHz UNII band, 5152 77x routers, accessing IOS routers, 366367, 369 800 toll-free numbers, dialup, 13 802.11a specication, 5152 802.11e specication, 53 802.11g specication, 52 804 routers, calling from 77x routers, 366369
A
access servers, 13 activating Layer 2 in ISDN routers, 320321 active periods (snapshot routing), 291 adaptive shaping, 487488 ADCs (analog-to-digital converters), 39 Address eld Frame Relay frames, 421423 LAPD frames, 244 PPP frames, 134 addressing, Frame Relay ARP, 453 Inverse ARP, 454 RARP, 454 adjustable CIRs, 437 administratively down interfaces on Frame Relay new installs, troubleshooting, 548549
ADSL (asymmetric DSL) , 24, 732 PPoE, 733 discovery stage, 735 negotiations, 736739 session stage, 736 advanced Frame Relay congurations bridging, 474476 compression, 476477 payload compression, 480481 Van Jacobson header compression, 477480 frame switching, 469470 generic traffic shaping, 484486 IP multicast, 482483 IP unnumbered, 469 ISDN backup, 471473 traffic shaping, 483484 ELMI, 487488 map classes, 486487 AES (Advanced Encryption Standard), 618 aggregate CIR, 436437 agile time division multiple access (A-TDMA), 742 AH (Authentication Header) format, 614 ICV calculation, 615 alarms states of T1 circuits, 184, 186 alternate mark inversion. See AMI AMI (alternate mark inversion), 61, 130 ones density, 131 amplitude, 40 amplitude-shift keying (ASK), 40 analog dialup services, 12 limitations of, 14 VPNs, 13 analog modems, 126 signal loss, 127 analog pads, echo removal, 129130 analog-to-digital converters (ADCs), 39 Annex A LMI type, 453 Annex D LMI, 516520 Annex D LMI type, 451 ANSI (American National Standards Institute) standards, Frame Relay, 415
836
ANSI T1.617 Annex D LMI
ANSI T1.617 Annex D LMI, 516520 application layer (OSI model), 99 Application Service Providers (ASPs), 8586 applications, accessing remotely, 8 applying timestamps, 313314 approaches to troubleshooting, models, 101102 AR (access rate), Frame Relay, 434 architecture ISDN C-plane, 236 Layer 1, 237241 Layer 2, 242247 Layer 3, 248252 ARP (Address Resolution Protocol), 453 AS5x00 routers, 205207 AS5200 router commands, 207, 209 AS5300 router commands, 209214 AS5400 router commands, 215 ASK (amplitude-shift keying), 40 ASPs (Application Service Providers), 8586 asymmetrical CIR, 437 A-TDMA (agile time division multiple access), 742 authentication OTPs, 228 PAP, 133 PPP, 340, 396398 remote access VPN users, 637 servers, 133 timeouts (dialup), 219221 VPNs client authentication, 619 DH algorithm, 624627 HMAC, 627628 key management, 624627 RADIUS, 621623 user/identity authentication, 620 Authentication phase (PPP), 136, 197 authenticator GINAs, 705 Auto-RP, 483 availability of remote access services, 7 of phone services for ISDN, 309310
B
B (Bearer) channels (ISDN), 234 Layer 1, 237241 devices, 238 interfaces, 239241 Layer 2, 242 LAPD frame format, 242247 logical link establishment (LAPD), 246247 Layer 3, 248 Q.931, 248252 NFAS, out-of-order detection, 227 B8ZS (bipolar 8-zero substitution), 131132 backup interfaces, DDR configuration, 147 BACP (Bandwidth Allocation Control Protocol), 16 bandwidth of modems, 126 on demand, ISDN BRI configuration, 376 Bandwidth Allocation Control Protocol (BACP), 16 bandwidth interval, Frame Relay, 434 Barker sequence, 50 baseline behavior network topology, discovering, 103105 performance, establishing, 105109 basic-5ess switch types (ISDN), 259260 SPIDs, configuring, 260262 BBFW (Broadband Fixed Wireless) P2MP solutions, 53 Bc (committed burst rate), 434 Be (excess burst rate), 434 bearer services, Frame Relay, 438 BECNs (backward explicit congestion notications), 441443, 536 Frame Relay Address field bit, 421 BERTs (bit error rate testers), testing T1 circuits, 183184 bidirectional procedures, 439 billing expenses, 7 binary phase-shift keying (BPSK), 50 BISDN (Broadband ISDN), 235 bit errors, checking on T1 circuits, 183184 bit-robbing signaling, 65
CDP (Cisco Discovery Protocol), discovering network topology
837
blue alarms, 185 Boosted Session Transport, 29, 750 BPSK (binary phase-shift keying), 50 BRI (Basic Rate Interface), 57, 237241 D channel, testing, 327 developing troubleshooting process in remote services environments, 359 accessing remote users router, 365369 preconguring routers on both ends, 364365 end-to-end communications, 386 routing issues, resolving, 399 troubleshooting LEC switch settings, 387 initializing, 241 keepalive mechanism, 323 performance issues LEC switch problems, 382386 line problems, 377382 routing, 377 settings, 382 service layers, viewing, 360363 SPIDs, 253 bridging Frame Relay, 474, 476 broadband wireless services, 25 limitations of, 27 LMDS, 2627 MMDS, 2526 unlicensed frequencies, 27 broadcast queues, Frame Relay conguration, 468 BST (Boosted Session Transport), 29, 750 budgeting remote access costs, 6 bursty trafc, 414
C
C/R (Command/Response) bit, Frame Relay Address eld, 421 cable modems, 740 services, 20 limitations of, 22 standards, 21
cabling long versus short lengths, 183 shorts, detecting, 223 calculating CIR, 435 ISDN BRI load at full utilization, 376 maximum DLCIs per interface, 467 RER, 444 call clearing messages, 251 Call Reference eld (Q.931 messages), 249 callback function, PPP, 344347 ISDN configuration, 303305 called-party number verication, 306 caller ID screening, 306 calling IOS routers from IOS 77x routers, 366369 CAP (carrierless amplitude/phase modulation), 44 Capacity Theorem, 38 captured Log Viewer results, viewing, 688699 carrierless amplitude/phase modulation (CAP), 44 carriers, 69 CO, 81 first-tier exchange carriers, 80 IXCs, 81 switching systems, 7071 tandem office, 83 T-carriers, 75 E1, 77 T1, 7677 categories of ISDN network designs, 258259 CATV (cable TV) cable modems, 2022, 740 data transmission, 740 standards, 741744 heartbeats, 745 two-way Internet connections, 744 Cause messages (ISDN BRI), 331334 CCITT (Comit Consultatif International Tlphonique et Tlgraphique), 12 CCP (Compression Control Protocol), 352 CCS (common channel signaling), 78 CDMA2000 1xEV, 91 CDP (Cisco Discovery Protocol), discovering network topology, 103
838
CDSL (consumer DSL)
CDSL (consumer DSL), 24 cell switching, 70 CERT (Computer Emergency Response Team), 77 Challenge Handshake Authentication Protocol (CHAP), 340 change management of remote access VPNs, 636 channel banks, 73 channels, ISDN, 234 CHAP (Challenge Handshake Authentication Protocol), 340 charge backs, 7 Chinese Remainder Theorem, 625 CIR (committed information rate), 435 adjustable CIRs, 437 aggregate CIR, 436437 asymmetrical CIR, 437 flexible CIR, 437 zero CIR, 436 circuit switching, 70 Cisco Discovery Protocol, 103 Cisco Easy VPN client, 713 client status, displaying, 716 debugging IPSec key events, 717719 initial troubleshooting checklist, 714, 716 monitoring, 720721 resetting connection, 717 restrictions, 713714 Cisco IOS 77x routers, accessing ISDN routers, 366369 commands, 102 ISDN available phone services, 309310 voice privacy, conguring, 308309 NFAS groups, 393 Cisco Mobile Ofce initiative, 89 Cisco PIX VPN clients 501 VPN Client, configuring, 669670 506 VPN Client, configuring, 669671 connectivity, verifying, 722732 restrictions, 722 Cisco UBR7200 Series routers, 21 Cisco UBR7246 Universal Broadband Router, 26 Cisco VPN 3000 Concentrator, IPSec over UDP, 639
Cisco VPN 3002 router connection establishment, 795796 verifying group name/password, 800 verifying interface status, 797799 HW Client, 706 conguring, 665666 Event Log, 708712 initial troubleshooting checklist, 707 Cisco VPN IOS Client, conguring, 666668 Cisco VPN Unity client, 663664 Concentrator Event Log, 699701 event classes, 702704 event security levels, 704705 Event Log Viewer, 685 Client Log Viewer, starting, 686 ISAKMP, 688 reviewing captured data, 688699 incompatible GINAs, 705706 restrictions, 676679 troubleshooting checklist, 682685 classifying enterprise VPNs, 593595 data link layer VPNs, 599603 rewall-based VPNs, 597598 network VPNs, 604607 remote access VPNs, 595 site-to-site VPNs, 596 troubleshooting tools, 110 clear interface bri0 command, 318 CLECs (competitive LECs), 80, 732 client authentication, 619 Client mode conguration, Cisco VPN 3002 routers, 706 CLLM (consolidated link-layer management), 442443 clocking issues, 55 Frame Relay isolating, 499500 troubleshooting, 493498 SCTE, 499 CO (central ofce), 81 code values for LMIs, 520521 codecs, 73
conguring
839
coded orthogonal FDM (COFDM), 52 coding schemes 2B1Q, 5559 AMI, 61, 130 B8ZS, 131132 COFDM, 52 DSL, 4142 HDB3, 132 pseudo-ternary signaling, 5557 WLANs, 48 zero-suppression, 6162 COFDM (coded orthogonal FDM), 52 Comit Consultatif International Tlphonique et Tlgraphique (CCITT), 12 commands AS5200 series routers, 207209 AS5300 series routers, 209214 AS5400 series routers, 215 clear interface bri0, 318 debug bri, 316317 debug interface serial, 523524 debug isdn q931, 325, 328 debug ppp negotiation, 220221 deub ppp authentication, 340 extended ping, 111 isdn autodetect, 262 isdn timeout signaling, 318 logging console, 548 loopback, troubleshooting T1 circuits, 183 mtrace, 578 ping, 110114 replies, 112 syntax, 110 service timestamps, 313 short format, 102 show cdp neighbors, 103 show controllers bri0, 316 show dialer, 373374 show interface serial 0, 502505 show isdn active, 372 show isdn status, 315, 320, 360363 show modem operational status, 224 tracert, 114115
committed burst rate (Bc), 434 committed interval (Tc), 434 comparing remote access and site-to-site VPNs, 633634 X.25 and Frame Relay features, 414415 components of Frame Relay networks, 419 compression, Frame Relay, 476477, 538, 540543 hardware compression, 537 payload compression, 480481 software compression, 542543 Van Jacobson header compression, 477480 Concentrator Event Log, 699701 event classes, 702704 event security levels, 704705 conguration management of remote access VPNs, 635 conguration negotiation phase (LCP), 335336 conguring DDR backup, 173176 with backup interfaces, 147 with dialer watch, 148 with oating static routes, 148 dialer profiles, 297, 299303 dial-in large-scale, 160164 PPP dial-in, 151159 text dial-in, 150151 dial-out large-scale, 171173 PPP dial-out, 168171 text dial-out, 164168 Frame Relay bridging, 474476 broadcast queues, 468 compression, 476477 frame switching, 469470 generic trafc shaping, 484486 IP multicast, 482483 IP unnumbered, 469 ISDN backup, 471473 payload compression, 480481 point-to-multipoint connections, 458461
840
conguring
point-to-point connections, 461466 routing protocol overhead estimates, 467468 trafc shaping, 483488 Van Jacobson header compression, 477480 ISDN BRI, bandwidth on demand, 376 DDR, 294303 IP pools, 262265 MMP, 278284 NAT, 267271 PAT, 266267 per-user conguration, 272273 POTS interfaces, 306308 PPP callback, 303305 snapshot routing, 290292 SPIDs, 260262 spoong, 290 switch type, 259260 voice privacy, 308309 PPP callback, 304305 remote access VPNs Cisco PIX 501 VPN Client, 669670 Cisco PIX 506 VPN Client, 669, 671 Cisco VPN 3002 HW Client, 665666 Cisco VPN IOSClient, 666668 Cisco VPN Unity Client, 663664 VPN 3000 Concentrator, 648649 lters and rules, 650651 Group Lock, 662 IKE peer identity validation, 662 IKE proposals, 656, 658659 IPSec SAs, 661 load balancing, 654655 redundancy, 653 reverse route injection, 655 SAs, 659660 congestion control mechanisms, Frame Relay, 441 BECNs, 536 CLLM, 443 FECNs, 535 rate adoption algorithm, 442
windowing, 443 connection speeds increasing, 226 limitations of, 128 of modems, 126127 connection termination phase (PPP), 352353 connectionless data integrity, 608, 614 connectivity of Cisco PIX VPN client, verifying, 722732 testing, 110117 console logging, 548 Consortium LMI, 513515 Status Enquiry message format, 514515 Status message format, 515 constellations, 40 contention resolution, 57 Control eld LAPD frames, 244245 LAPF control protocol, 424425 PPP frames, 135 control LAPF, 419 Control plane. See C-plane core aspects of Frame Relay, 413 core LAPF, 419 core routers, 257 DLCI settings, verifying, 560562 Frame Relay point-to-multipoint configuration, 458460 IP pool assignment, 262, 264265 NFAS groups, 393 point-to-point Frame Relay configuration, 462465 corporate managed services, 8 cost-effective ISDN solutions DDR, 294295 dialer proles, 296303 PPP callback, 303305 snapshot routing, 290292 spoofing, 290 costs of remote access, budgeting, 6 counter parameters for LMIs, 521, 523 CPE (customer premises equipment), 5 C-plane, 236, 417418
demand circuits (OSPF)
841
creating dial peers, 307308 VPN client profiles, 772 CSU/DSU (channel service unit/data service unit) pinouts, 499 custom design ISDN switches, 260 customer premises equipment (CPE), 5
D
D (Delta) channel, 234 Layer 1, 237241 devices, 238 interfaces, 239241 Layer 2, 242 LAPD frame format, 242247 logical link establishment, 246247 Layer 3, 248 Q.931 message format, 248252 TDM, 393 testing, 327 D/C (data/control) bit (Frame Relay Address eld), 421 DACs (digital-to-analog converters), 39 DARPA (Defense Advanced Research Projects Agency), 97 data centers, 8789 Data Encryption Standard, 617 Data eld (LAPD frames), 246 Data eld (PPP frames), 135 data link connection identiers. See DLCIs data link layer (OSI model), 98 Frame Relay, 506 LMI issues, 513526 miscongured PVCs, 507513 ISDN BRI, 319324 data link layer protocols, 599601 L2TP, 602603 PPTP, 600601 PPP, 134 Authentication phase, 136, 396398 frame elds, 134135 LCP, troubleshooting, 387396
Link Dead phase, 135 Link Establishment phase, 135136 Link Termination phase, 137 Network Layer Protocol phase, 137 troubleshooting, 138 data transmission over CATV, standards, 740744 dB (decibel), 128 DBS (Direct Broadband Satellite) systems, 28 BST, 29, 750 FITFEEL protocol, 751 IPA, 28 IPSec, 752753 LEO satellites, 30 manipulating TCP stack, 749750 performance, 749 VPNs, 745746 bandwidth, 747748 error control coding, 746 DDR (dial-on-demand routing), 294295 configuring, 173176 with backup interfaces, 147 with dialer watch, 148 with oating static routes, 148 dialer profiles, 296 conguring, 297303 Windows 2000, 399408 DDS (Dataphone Digital Service), 495 DE (discard eligible) bit, Frame Relay Address eld, 421, 434 debug bri command, 316317 debug information, timestamping, 313314 debug interface serial command, 523524 debug isdn q931 command, 325, 328 debug ppp authentication command, 340 debug ppp negotiation command, 220221 debugging Cisco Easy VPN client connection, IPSec key events, 717719 Frame Relay LMI, 552 Defense Advanced Research Projects Agency (DARPA), 97 dening service levels, 9 delivered erroneous frames, 445 demand circuits (OSPF), 293
842
demodulation
demodulation, 39 dense mode (PIM), Frame Relay multicast conguration, 482483 design objectives of remote access VPNs, 634635 designing enterprise services, 3034 Frame Relay network parameters, 434 CIR, 435437 ISDN networks hub and spoke, 257 IP pools, 262265 MLP, 273277 MMP, 278285 NAT, 267271 PAT, 266267 per-user conguration, 272273 Destination Unreachable messages (ICMP), 113114 detecting dirty phone lines, 223224 shorts in modem cables, 223 source of frequent disconnections, 226 devices AS5200 routers, commands, 207, 209 AS5300 routers, commands, 209214 AS5400 routers, commands, 215 AS5x00 routers, 205207 cable modems, 740 codecs, 73 Frame Relay, 419 ISDN, 238 switch types, 252253 modems, 125 56-k ex modems, 14 analog, 126 analog dialup services, 1213 bandwidth, 126 cable modem services, 20 connection speeds, 126127 digital, 126 malfunctioning, 225 PCM, 13 Shannons Capacity Theorem, 12
repeaters, 126 DH (Dife-Hellman) algorithm, 624627 DHCP (Dynamic Host Conguration Protocol) servers, verifying reachability, 227 dial peers, creating, 307308 dial-back authentication, 134 dialer maps, 294 dialer proles, 294296 configuring, 297303 dialer watch, DDR conguration, 148 dial-in large-scale dial-in, configuring, 160164 PPP dial-in conguring, 151159 network design, 143144 text dial-in conguring, 150151 network design, 143 troubleshooting procedure verifying incoming connection type, 192194 verifying modem operability, 191192 verifying PPP negotiation, 194200 dial-on demand backup routing, conguring with backup interfaces, 147 with dialer watch, 148 with floating static routes, 148 dial-out ISDN, 372374, 376 large-scalet, 146 conguring, 171173 PPP dial-out conguring, 168171 network design, 145 text dial-out conguring, 164168 network design, 144 troubleshooting procedure, 200205 dial up 800 toll-free numbers, 13 analog, 1214 authentication PAP, 133
DSSS (direct sequence spread spectrum)
843
servers, 133 time outs, 219221 disconnections, isolating source of, 221223 Frame Relay, 17 benets of, 18 limitations of, 18 standards, 1718 ISDN, 14 benets of, 1516 limitations of, 16 PPP, 134 Authentication phase, 136 frame elds, 134135 Link Dead phase, 135 Link Establishment phase, 135136 Link Termination phase, 137 Network Layer Protocol phase, 137 troubleshooting, 138 retrains, 221223 diffused-beam WLANs, 45 digital modems, 126 digital pads, echo cancellation, 129130 digital sampling, Nyquists sampling theorem, 39 digital transmissions, clocking, 55 digitalization of voice, 73 digital-to-analog converters (DACs), 39 Direct Broadband Satellite. See DBS systems direct-beam WLANs, 45 direct sequence spread spectrum (DSSS), 49 dirty phone lines, as source of slow line speeds, 223224 discard eligible (DE), 434 disconnections, troubleshooting, 221223 Discrete Multi-Tone. See DMT displaying Cisco Easy VPN client status, 716 ISDN BRI service layers, 360363 distance vector routing protocols, size estimation, 467
DLCIs (data link connection identiers), 421 channel assignments, 422423 CIR, 435 aggregate CIR, 436437 asymmetrical CIR, 437 exible CIR, 437 zero CIR, 436 mismatched settings, troubleshooting, 556562 per interface limitations, 466467 DMT (Discrete Multi-Tone), 4244 CAP, 44 SF structure, 43 DOCSIS (Data-Over-Cable Service Interface Specications), 741744 satellite communications, 54 DoD (Department of Defense) interconnection model, 97 down interfaces, troubleshooting Frame Relay new installs, 548552 DPD (Dead Peer Detection), 803804 dropped calls (ISDN), resolving 22 second issue, 387396 DS0, 77 DSL (digital subscriber line) coding schemes, 4142 PPoE, 733 discovery stage, 735 negotiations, 736737, 739 session stage, 736 xDSL services, 22 ADSL, 24 CDSL, 24 FDIs, 2223 HDSL, 24 IDSL, 24 RADSL, 24 SDSL, 24 TDRs, 23 VDSL, 25 DSLAMs (digital subscriber line access multplexers), 733 DSSS (direct sequence spread spectrum), 49
844
E1
E
E1, 77 EA (extended address) bit (Frame Relay Address eld), 421 echo, removing, 129130 Effective Isotropic Radiated Power (EIRP), 50 EFM (Ethernet to the First Mile), 596 ELMI (Enhanced Local Management Interface), 567 Foresight adaptive shaping, 487488 enabling ForceKeepAlive, 787 encapsulation DDR backup solutions, 148 over Frame Relay, 447 encoding schemes 2B1Q, 55, 5859 AMI, 61 COFDM, 52 zero-suppression, 6162 encryption AES, 618 DES, 617 remote access VPNs, 638 endpoint migration, Frame Relay, 584585 end-to-end communications Frame Relay, 528533 ISDN BRI, 386 22 second issue, 387396 LEC switch settings, 387 PPP authentication, 396398 routing issues, 399 end-user routers (ISDN), 257 configuring, 262 enterprise ISDN networks, 258259 enterprise remote access services, provisioning, 3034 Frame Relay, 3133 ISDN, 31, 33 xDSL, 3334 enterprise VPNs, 593594 categories of, 595 data link layer, 599601
L2TP, 602603 PPTP, 600601 firewall-based, 597598 network layer layer, 604 Layer 3 tunneling, 605 SAs, 605607 remote access, 595 site-to-site, 596 errors on T1 circuits, 187 E-Series protocols, 14, 233 ESF (Extended Super Frame) signal format, 63 ESP header format, 616618 establishing baseline behavior network topology, 103105 performance characteristics, 105109 estimating transit delay, 444 ET (Exchange Termination), 238 Ethernet to the First Mile (EFM), 596 Event Log, Cisco VPN 3002 HW client, 708712 excess burst rate (Be), 434 expenses, billing, 7 extended bus architecture (ISDN), 237 extended ping command, 111
F
far end, 96 far-end crosstalk (FEXT), 23 fast busy signals, debugging, 226 fast-dial, 15 Fast Information Transfer For Extremely Errored Links (FITFEEL) protocol, 751 FCS (frame check sequence) eld Frame Relay frames, 420 LAPD frames, 246 PPP frames, 135 FDIs (Feeder Distribution Interfaces), 22 FDM (frequency-division multiplexing), 7172, 414 DMT, 42 FECNs (forward explicit congestion notications), 421, 441443, 535
Frame Relay
845
Feeder Distribution Interfaces (FDIs), 22 Fermat/Euler Theorem, 625 FEXT (far-end crosstalk), 23 FHSS (frequency hopping spread spectrum), 48 ber-optic networks, SONET, 80 elds of ICV, 608610 of LAPD frames Address eld, 244 Control eld, 244245 Data eld, 246 FCS eld, 246 Flag eld, 243 of PPP frames, 134135 lter GINAs, 705 rewall-based VPNs, 597598 rewalls, implementing in remote access VPNs, 640641 rst-tier exchange carriers, 80 FITFEEL (Fast Information Transfer For Extremely Errored Links) protocol, 751 Flag eld Frame Relay frames, 420 LAPD frames, 243 PPP frames, 134 apping lines, 562566 apping links, 526528 apping routes, 572 oating static routes, DDR conguration, 148 ForceKeepAlive, enabling, 787 Foresight adaptive shaping ELMI, 487488 fragmentation process, 610 Frame Relay, 448 Frame Relay, 17 addressing ARP, 453 Inverse ARP, 454 RARP, 454 ANSI standards, 415 benefits of, 18 bidrectional procedures, 439 bridging, 474, 476 broadcast queues, 468
CIR, 435 aggregate CIR, 436437 asymmetrical CIR, 437 exible CIR, 437 zero CIR, 436 compression, 538, 540543 conguring, 476477 hardware compression, 537 software compression, 542543 congestion control mechanisms, 441 CLLM, 443 rate adoption algorithm, 442 windowing, 443 core aspects, 413 C-plane, 417418 CSU/DSU pinouts, 499 data link layer troubleshooting, 506 LMI issues, 513526 miscongured PVCs, 507513 design parameters, 434 DLCIs mismatched settings, troubleshooting, 556562 per interface limitations, 466467 ELMI, 487488 end-to-end connectivity, 528533 flapping lines, 563566 flapping links, 526528 frame switching configuration, 469470 full-mesh topology, 441 generic traffic shaping, 484486 host migration, 580585 IAs, 415416 initial troubleshooting steps, 492493 IP multicast, 440 checking IGMP group members, 576577 checking upstream neighbor availability, 574576 conguring, 471473 group ags, 573 multicast trace reporting, 577580 testing remote users router, 577
846
IP unnumbered conguration
IP unnumbered configuration, 469 ISDN backup configuration, 471473 LAPF control protocol, 424 Control field, 424425 Information field, 426429 logical frame processing, 422 T1.618 frame format, 419423 limitations of, 18 LMIs, 449 Annex D, 451 Cisco-Consortium, 451 code values, 520521 counter parameters, 521, 523 ITU-T Q.933 Annex A, 453 timers, 522 multiplexing, 414 network components, 419 new install issues, 548556 NNI, 439 partial-mesh topology, 441 payload compression, configuring, 480481 performance parameters, 562 RER, 444 throughput, 444 transit delay, 444 physical layer clocking problems, 493498 DSU/CSU, testing, 501 loopback testing, 500 performance issues, 501505 point-to-point connections conguring, 461 hub conguration, 462, 464 spoke conguration, 465466 provisioning enterprise remote access services, 3133 pseudo-ternary signaling, 5557 QoS parameters, 445 remote user router, verifying status, 553 serial interface configuration, verifying, 551 service architecture, VCs, 418 service functioning, checking, 553555
standards, 1718 traffic shaping, 483484, 534 BECNs, 536 FECNs, 535 apping routes, investigating, 572 high RTT numbers, investigating, 567569 map classes, 486487 slow performance, investigating, 569572 verifying settings, 566 UNI, 438 upper-layer protocol interoperability, 445 encapsulation, 447 fragmentation, 448 multiprotocol support, 445447 Van Jacobson header compression. configuring, 477480 variable length framing, 415 VCs, 415 versus X.25, 414415 VoFR, 440 framing techniques ESF, 63 T1, 62 ESF signal format, 63 SF signal format, 6263 T3, M23 signal format, 6364 frequency, 40 frequency-division multiplexing. See FDM frequency-shift keying (FSK), 40 frequent disconnections, detecting source of, 226 FRF (Frame Relay Forum) IAs, 415416 FSK (frequency shift-keying), 40 full-mesh topology, Frame Relay, 441 funding remote access, 6
G
Gang of Four, 449 generic trafc shaping, 484486
interfaces
847
geographic requirements for remote access deployment, 7 GINA, 705 global dialer software, 13 group ags, 573 Group Lock parameter, conguring on VPN 3000 Concentrators, 662 group members, 573 GSM/GPRS (Global System of Mobility/General Packet Radio Service), 91
I
IAs (Implementation Agreements), 415416 ICMP (Internet Control Message Protocol), message types, 112113 Destination Unreachable, 113114 IDBs (interface descriptor blocks), 273 IDSL, 24 IE (information element) elds, LAPF control protocol, 426429 IEEE 802.11a specication, 5152 IEEE 802.11e specication, 53 IEEE 802.11g specication, 52 IGMP (Internet Group Message Protocol) group members, verifying on Frame Relay networks, 576577 IKE (Internet Key Exchange) key management, 624627 peer identity validation, configuring on VPN 3000 Concentrators, 662 proposals, configuring on VPN 3000 Concentrators, 656659 remote access VPN authentication, 638 ILECs (incumbent LECs), 80, 732 illegal serial line type xx messages, 524 immutable ICV elds, 608610 incompatible GINAs, 705706 increasing slow connection speeds, 226 Information Elements eld (Q.931 messages), 251252 Information eld Frame Relay frames, 420 LAPF control frames, 426429 information transfer messages, 245 initial troubleshooting steps, Frame Relay, 492493 in-sourcing remote access support, 7 installation issues, Frame Relay, 548556 interconnection models DoD, 97 OSI, 98100 interfaces, 469 Frame Relay, broadcast queues, 468 ISDN, 239241
H
H (Hybrid) channel, ISDN, 234 hardware compression, 537 hardware simulators, 110 Hash-based Message Authentication Code (HMAC), 627628 HDB3 (high density binary 3), 132 HDSL (high-data rate DSL), 24 heartbeats, 745 helpdesks, supporting remote access users, 7 HFC (hybrid ber-coaxial) networks, 20 HMAC (Hash-based Message Authentication Code), 627628 host migration, Frame Relay, 580585 Host Page Accelerator (HPA), 28 hosting services, 8789 HPA (Host Page Accelerator), 28 hub and spoke network design, 142 ISDN, 257 hub conguration Frame Relay point-to-multipoint configuration, 458460 point-to-point Frame Relay connections, 462, 464465 hybrid systems, 20 line-coding techniques, 5354 modulation, 5354
848
internal standard PCI modems
internal standard PCI modems, 21 International Telecommunication Union Telecommunication Standardization Sector. See ITU-T Internet hosting services, 8789 Internet Page Accelerator (IPA), 28 interoperability of Frame Relay and upper-layer protocols, 445 encapsulation, 447 fragmentation, 448 multiprotocol support, 445447 Inverse ARP (Address Resolution Protocol), 454 IOS-based troubleshooting methods, 102 IP addressing, ISDN conguration NAT, 267271 PAT, 266267 IP datagrams, fragmentation, 610 IP multicast Frame Relay networks, 482483 multicast trace reporting, 577580 remote users router, testing, 577 verifying IGMP group members, 576577 verifying upstream PIM neighbor availability, 574576 group flags, 573 IP pools, dening, 262, 264265 IP unnumbered Frame Relay conguration, 469 IPA (Internet Page Accelerator), 28 ipcong command (Windows NT/2000), verifying IP addressing conguration, 769770 IPSec AH, 614615 authenticating remote access VPNs, 638 connectionless data integrity, 608 ESP header, 616618 ICMP processing, 611612 ICV calculation, 615 ICV fields, 608610 IP fragmentation, 610 modes, 612 over satellite systems, 752753 over TCP, 640 PMTU discovery, 610611
SAs, configuring on VPN 3000 Concentrators, 661 selecting mode for remote access VPNs, 637 IR (infrared) radio-channel, 45 ISAKMP (Internet Security Association and Key Management Protocol), 688 ISDN (Integrated Services Digital Network), 14 accessing routers from IOS 77x routers, 366369 B channel, 234 benefits of, 1516 channels, 234 C-plane, 236 custom design switches, 260 D channel, 234 TDM, 393 data link layer, activation procedure, 320321 DDR, 294295 dialer proles, 296303 design solutions NAT, 267271 PAT, 266267 dial-out, 372374, 376 H channel, 234 hub and spoke design, 257 IP pools, configuring, 262, 264265 Layer 1, 237238, 241 devices, 238 interfaces, 239241 Layer 2, 242 LAPD frame format, 242247 logical link establishment, 246247 Layer 3, 248 Q.931 messages, 248252 limitations of, 16 load interval, 376 local loop, 234 MLP, 273277 MMP, 278, 280 conguring, 281282 sample implementation, 282284 verifying, 284285
LAPF
849
network design, categories of, 258259 new install issues, 369, 371 NISDN, 235 per-user configuration, 272 virtual interface templates, 272 virtual proles, 273 POTS interfaces, configuring, 306308 PPP callback, 303305 LCP, 387396 PRI 1.544-Mbps interface, 6465 2.048-Mbps interface, 65 PRI circuits, 188 Layer 1 status, verifying, 188 Layer 2 status, verifying, 188190 provisioning enterprise remote access services, 3133 pseudo-ternary signaling, 5557 security, 305 snapshot routing, 290292 SPIDs, 253 spoofing, 290 supplementary phone services, 309310 switch types, 252253, 259260 voice privacy, configuring, 308309 isdn autodetect command, 262 ISDN BRI bandwidth on demand, configuring, 376 developing troubleshooting process in remote services environment, 359 accessing remote users router, 365369 preconguring routers on both ends, 364365 viewing service layers, 360363 end-to-end communications, 386 resolving routing issues, 399 troubleshooting LEC switch settings, 387 keepalive mechanism, 323 performance issues LEC switch problems, 382386 lines, 377382 routing, 377 settings, 382
isdn timeout-signaling command, 318 I-series protocols, 234 isolating Frame Relay clocking problems, 499500 ISPs, 8586 ISDN networks, 258259 ITFS (Instructional Television Fixed Service), 25 ITU-T (International Telecommunication Union Telecommunication Standardization Sector), 12 E-series protocols, 233 I-series protocols, 234 Frame Relay standards, 415 Q.933 Annex A, 453 Q-series protocols, 234 IXCs, 81
J-L
keepalive mechanism ISDN BRI, 323 spoofing, 290 key management, 624627 L2TP (Layer 2 Tunneling Protocol0, 602603 LAN-specic VPN issues inability to log in, 760 MTU settings, 754756, 758 NAT, multiple client handling, 753 packet size, 758, 760 LAN-to-LAN VPNs, 596 LAPD (Link Access Procedure on the D channel), 242, 248 Address field, 244 Control field, 244245 Data field, 246 FCS field, 246 Flag field, 243 frame format, 242247 logical link establishment, 246247 LAPF control protocol, 424 Control eld, 424425 Information eld, 426429
850
LAPF
T1.618 frame format, 419 Address eld, 421423 elds, 420 Flag eld, 420 logical frame processing, 422 large-scale dial-in, conguring, 160164 large-scale dial-out configuring, 171173 network design, 146 last mile, 9091 LATAs (local access and transport areas), 80 layer 1/2 status of PRI circuits, verifying, 188190 Layer 3 tunneling, 605 layered architecture DoD model, 97 ISDN BRI, 237241 C-plane, 236 LAPD, 242244, 246248 Q.931, 248249, 251252 OSI Reference Model, 98100 layered approach to troubleshooting, 96 LCP (link control protocol) phase of PPP, 194196 configuration negotiation phase, 335336 magic numbers, 339 troubleshooting, 335339 LDN (local directory number), 308 LDNs (Local Directory Numbers), 252 LE (Local Exchange), 238 LEC (local exchange carrier) switch problems, ISDN end-to-end communications, 387 performance issues, 382386 legacy DDR, 294295 limitations of analog dialup services, 14 of analog modem connection speeds, 128 of cable modems services, 22 of Cisco Easy VPN client, 713714 of Cisco PIX VPN client, 722 of Cisco Unity client, 676679 of ISDN services, 16 of wireless broadband services, 27
line coding techniques B8ZS, 131132 errors, 130 HDB3, 132 in hybrid networks, 5354 in wireless LANs, 4445 line problems Frame Relay, investigating, 493498 ISDN performance issues, 377382 line provision, verifying, 354 linecode violations of T1 circuits, 186 link compression, 477 Link Dead phase (PPP), 135 Link Establishment phase (PPP), 135136, 335339 link speeds, 434 Link Termination phase (PPP), 137 link-state protocols OSPF, demand circuits, 293 size estimation, 467468 listen option (Netcat utility), 117 LMDS (Local Multipoint Distribution Service), 2527 LMIs (Local Manaagement Interfaces), 449 ANSI T1.617 Annex D, 516, 518520 Annex D, 451 Cisco-Consortium, 451 code values, 520521 Consortium LMI, 513515 Status Enquiry message format, 514515 Status message format, 515 counter parameters, 521, 523 debugging, 552 ITU-T Q.933 Annex A, 453 timers, 522 load balancing, conguring on VPN 3000 Concentrators, 654655 load interval, 376 local loop, 234 Local Multipoint Distribution Service, 2527 log les, timestamping, 313314 logging console command, 548 logical frame processing, LAPF, 422 logical link establishment (LAPD), 246247
modulation
851
long cable lengths, 183 loopback command, troubleshooting T1 circuits, 183 loopback testing, Frame Relay, 500 magic numbers, 339 lost frames, 445 LT (Local Termination), 238 LTI (linear time-invariant) systems, 47
M
magic numbers, 339 malfunctioning modems, detecting, 225 managing Frame Relay host migration, 580585 endpoint migration, 583585 host preparation, 581583 routing options, 583 mandatory user participation, troubleshooting ring options, 354355 map classes, dening, 486487 marking malfunctioning modems, 225 MDF (main distribution frame), 81 message switching, 70 Message Type eld (Q.931 messages), 249250 messages CLLM, 442 ICMP, 112113 Destination Unreachable, 113114 illegal serial line type xxx, 524 ISDN BRI Cause Messages, 331332, 334 SABME, 322 M-frames, 63 Microsoft Windows 2000, DDR troubleshooting procedures, 399408 migration strategies, Frame Relay, 580585 endpoint migration, 583585 host preparation, 581583 routing options, 583 minimum acceptable throughput, 435 miscongured PVCs, troubleshooting, 507513 misdelivered frames, 445
mismatched DLCI settings, investigating, 556562 MLP (multilink PPP), 273277, 343344 MMDS (Multichannel Multipoint Distribution System), 2526, 53 MMP (Multichassis Multilink PPP), 278280, 347351 configuring, 281282 sample implementation, 282284 verifying configuration, 284285 mobile solutions, 89 modems, 125 56-kbps flex, 14 analog, 126 signal loss, 127 analog dialup services, 1213 limitations of, 14 VPNs, 13 authentication timeouts, 219221 bandwidth, 126 cable modem services, 20 limitations of, 22 standards, 21 cables dirty phone lines as source of slow connection speeds, 223224 shorts, detecting, 223 connection speeds, 126127 increasing, 226 limitations of, 128 digital, 126 disconnections, 221223 fast busy signals, debugging, 226 internal standard PCI modems, 21 malfunctioning, 225 PCM, 13 Shannons Capacity Theorem, 12, 38 slow busy signals, debugging, 227 modes of IPSec operation, 612 modulation, 39 in hybrid networks, 5354 in wireless LANs, 4445 WLANs DSSS, 49 FHSS, 48
852
modulator-demodulators
modulator-demodulators. See modems monitoring Cisco Easy VPN client environment, 720721 network performance, SAA, 117119 M-plane (ISDN), 236 MPLS VPN, 90 MPOE (minimum point of entry), 129 mtrace command, 578 multicast Frame Relay, 440, 482483 group flags, 573 Multichannel Multipoint Distribution System. See MMDS multiple frequency operation (UHF), 47 multiplexing, 414 FDM, 7172, 414 statistical multiplexing, 414 TDM, 74, 414 mutable ICV elds, 608610
N
nailed-up, 81 NAPs (network access points), 86 narrowband, 46 narrowband ISDN (NISDN), 235 NASs (Network Access Servers) dial-in, 191200 dial-out, 200205 T1 circuits, 181187 NAT (Network Address Translation) implementing in remote access VPNs, 639640 ISDN configuration, 267271 multiple client handling, 753 NBMA (nonbroadcast multi-access) model point-to-point Frame Relay, 461 NCPs (network control protocols), 197200, 341352 CCP, 352 MLP, 343344 MMP, 347351
near end, 96 near-end crosstalk (NEXT), 23 negotiating upper-layer protocols, NCPs, 341352 CCP, 352 MLP, 344 MMP, 347351 Netcat utility, 115117 network design DDR, configuring with backup interfaces, 147 with dialer watch, 148 with oating static routes, 148 dial-in PPP dial-in, 143144 text dial-in, 143 dial-out large-scale, 146 PPP dial-out, 145 text dial-out, 144 hub and spoke, 142 ISDN categories of, 258259 conguring switch type, 259260 hub and spoke, 257 MLP, 273277 MMP, 278, 280285 per-user conguration, 272273 SPIDs, conguring, 260262 Network Extension mode, Cisco 3002 HW client, 706 network layer (OSI model), 98 troubleshooting ISDN BRI, 324334 VPNs, 604 Layer 3 tunneling, 605 SAs, 605607 Network Layer Protocol phase (PPP), 137 network monitoring tools, 109 new install issues ISDN, 369371 Frame Relay, 548556 NEXT (near-end crosstalk), 23 NFAS (Non-Facility-Associated Signaling), 16
permanent virtual circuits
853
D channel, verifying correct circuit locations, 227 groups, 393 NI (National ISDN) standards, 233 NNI (network node interface), 439 Non-Facility-Associated Signaling. See NFAS NT1 (network termination type 1), 58, 238 NT2 (network termination type 2) devices, 238 N-way multicast service, Frame Relay, 440 Nyquist sampling theorem, 72 Nyquist's Theorem, 39
P
packet switching, 70 PAP (Password Authentication Protocol), 133 partial-mesh topologies, Frame Relay, 441 passive bus point-to-multipoint architecture (ISDN), 237 passwords authentication, PPP, 340 OTPs, 228 PAT (Port Address Translation) in remote access environments, 639640 ISDN configuration, 266267 PathChar utility. See Pchar pathcode violations of T1 circuits, 186 payload compression, 477 configuring, 480481 Pchar establishing baseline performance, 105109 options, 105106 PCM (pulse code modulation), 13, 39, 73 PDUs (protocol data units), 99 per interface limitations of DLCIs, 466467 perfect scheduling, 57 performance discovering baseline behavior, 105109 Frame Relay, physical layer, 501505, 562 compression, 537543 end-to-end connectivity, 528533 apping lines, 563566 apping links, 526528 RER, 444 throughput, 444 trafc shaping, 534536, 566572 transit delay, 444 monitoring with SAA, 117119 selection criteria for VPN termination equipment, 646648 per-interface compression, 477 periodic retransmissions, packets sent from W2K systems, 401 permanent virtual circuits. See PVCs
O
off net dial-out, 146 ones density, 131, 499 one-way service, Frame Relay multicast, 440 on-net dial-out, 145 operating systems, Windows 2000 DDR issues, resolving, 399408 well-known ports, 403405 operations management of remote access VPNs, 636 optical networks, SONET, 80 OSI model, 98100 data link layer correlated Frame Relay protocol functions, 419420 troubleshooting ISDN BRI, 319324 network layer, 324334 physical layer, 314319 OSPF (Open Shortest Path First) demand circuits, 293 OTPs (one-time passwords), 228 outgoing calls, ISDN, 372376 out-of-band signaling, 78 outsourcing remote acces support, 7 overload. See PAT oversubscription, 436
854
per-virtual circuit compression
per-virtual circuit compression, 477 PFS (perfect forward secrecy), 627 phase modulations, 40 phase-shift keying, 40 photonic WLANs, 45 physical layer Frame Relay clocking problems, 493498 CSU/DSU, testing, 501 loopback testing, 500 performance issues, 501505 ISDN BRI, 314319 T1 circuits alarm states, 184, 186 checking bit errors, 183184 errors, 187 identifying loopback features, 183 linecode violations, 186 pathcode violations, 186 slip seconds, 186 verifying controller status, 181183 PIM SM (Protocol Independent Multicast Sparse Mode), Frame Relay multicast conguration, 482483 ping command, 110114 PMTU (Path MTU) discovery, 610612 point-to-multipoint Frame Relay hub side configuration, 458, 460 spoke side configuration, 460461 point-to-point Frame Relay conguration hub configuration, 462, 464 NBMA model, 461 spoke configuration, 465466 ports, 403 POTS (plain old telephone service) interfaces, ISDN conguration, 306308 PPPoE, 733 discovery stage, 735 negotiations, 736739 session stage, 736 PPP (Point-to-Point Protocol), 134. See also MLP authentication servers, 133
timeouts, troubleshooting, 220221 troubleshooting, 340 Authentication phase, 136, 396398 callback, 303305, 344347 connection termination, 352353 dial-in network design, 143144, 151159 dial-out conguring, 168171 network design, 145 frame fields, 134135 LCP, 335339 22 second issue, 387396 Link Dead phase, 135 Link Establishment phase, 135136 Link Termination phase, 137 NCPs, 341352 negotiation authentication phase, 197 LCP phase, 194196 NCP phase, 197200 Network Layer Protocol phase, 137 protocol field, 335 troubleshooting, 138 PPTP (Point-to-Point Tunneling Protocol), 600601 Predictor data compression, 477 premature disconnect, 445 presentation layer (OSI model), 99 PRI (Primary Rate Interface) circuits, 188 1.544-Mbps interface, 6465 2.048-Mbps interface, 65 Layer 1 status, verifying, 188 Layer 2 status, verifying, 188190 proles (VPN client), creating, 772 projecting PPP link to call master, 278 protected band (RF), 46 Protocol Discriminator eld (Q.931 messages), 248 Protocol eld (PPP frames), 135, 335 protocol layer (Frame Relay), 506 LMI issues, 513526 misconfigured PVCs, 507513 new installs, 549552 provisioning process, enterprise remote access services, 3031, 3334
remote users of Frame Relay, troubleshooting nonpassing trafc in up, up state
855
Frame Relay, 3133 ISDN, 31, 33, 369 xDSL, 3334 pseudo-ternary signaling, 55, 57 PSK (phase-shift keying), 40 PSTN (Public Switched Telephone Network), 37 pulse code modulation. See PCM pulse density, 131 PVCs (permanent virtual circuits), 17, 418 DLCIs, per interface limitations, 466467 end-to-end connectivity, 528533 flapping lines, 563566 misconfiguration issues, 507513 premature disconnect, 445
R
RA to MPLS VPN (Remote Access to Multiprotocol Label Switching Virtual Private Network), 90, 592593 RADIUS, 621623 RARP (Reverse Address Resolution Protocol), 454 rate adoption algorithm, 442 RBS (robbed bit signaling), 78 red alarms, 185 redundancy configuring on VPN 3000 Concentrators, 653 ISDN backup for Frame Relay, configuring, 471473 reimbursements, 7 remote access VPNs, 595 change management, 636 Cisco PIX 501 VPN Client, configuring, 669670 Cisco PIX 506 VPN Client, configuring, 669671 Cisco VPN 3002 HW Client, configuring, 665666 Cisco VPN IOS Client, configuring, 666668 Cisco VPN Unity Client, configuring, 663664 configuration management, 635 design objectives, 634635 operations management, 636 security issues, 636 rewalls, 640641 IPSec, 637638 NAT/PAT, 639640 split tunneling, 640 user authentication infrastructure, 637 termination equipment, 641642 performance criteria, 646648 selecting core devices, 643646 versus site-to-site, 633634 remote control software, 109 Remote Page Accelerator, 28 remote users of Frame Relay, troubleshooting nonpassing trafc in up, up state, 555556
Q
Q.921, 242. See also LAPD LAPD frame format, 242247 Address eld, 244 Control eld, 244245 Data eld, 246 FCS eld, 246 Flag eld, 243 logical link establishment, 246247 Q.922 protocol, 424 Control field, 424425 Information field, 426429 Q.931 message format, 248, 331332, 334 Call Reference field, 249 Information Elements field, 251252 Message Type field, 249250 Protocol Discriminator field, 248 QoS (quality of service) parameters, Frame Relay, 445 QPSK (quaternary phase-shift keying), 44 Q-series protocols, 234 quiet periods (snapshot routing), 291
856
removing echo with digital pads
removing echo with digital pads, 129130 repeaters, 126 RER (residual error rate), 444 resetting Cisco Easy VPN client connections, 717 restrictions of Cisco Easy VPN client, 713714 of Cisco PIX VPN client, 722 of Cisco Unity client, 676679 retrains, 221223 reverse route injection, conguring on VPN 3000 Concentrators, 655 RF (radio frequency), 44 narrowband, 46 SS RF transmissions, 48 DHSS, 49 FHSS, 48 Rijndael algorithm, 618 ring options, troubleshooting mandatory user participation, 354355 router commands AS5200, 207, 209 AS5300, 209214 AS5400, 215 routing ISDN BRI, 399 performance issues, 377 routing protocols, discovering network topology information, 104105 RPA (Remote Page Accelerator), 28 RPC (remote procedure call), 402403 RTT (round-trip time), 745 verifying Frame Relay service, 567569
S
SAA (Service Assurance Agent), 117119 SABME (Set Asynchronous Balanced Mode Extended) messages, 190, 322 sampling, Nyquists sampling theorem, 39 SAPI (service access point identier) data types, 189
SAs (security associations), 605607 configuring on VPN 3000 Concentrators, 659660 satellite systems, 28 BST protocol, 29, 750 DOCSIS 1.1 standard, 54 FITFEEL protocol, 751 IPA, 28 IPSec, 752753 LEO satellites, 30 manipulating TCP stack, 749750 performance, 749 VPNs, 745746 bandwidth, 747 error control coding, 746 TCP efciency, 747748 S-CDMA (synchronous code division multiple access), 742 SCTE (serial clock transmit external) timing, 499 SDSL (single-line DSL), 24 security authentication DH algorithm, 624627 HMAC, 627628 key management, 624627 OTPs, 228 PAP, 133 RADIUS, 621623 resolving issues, 396398 servers, 133 timeouts, 219221 VPN client authentication, 619 VPN user/identity authentication, 620 IPSec AH header format, 614615 connectionless data integrity, 608 ESP header format, 616618 ICMP processing, 611612 ICV calculation, 615 ICV elds, 608610 IP fragmentation, 610 modes, 612 PMTU discovery, 610611
slow connection speeds
857
ISDN, 305 policies, 8 remote access VPNs, 636 encryption, 638 rewalls, 640641 IPSec authentication, 638 IPSec mode, selecting, 637 NAT/PAT, 639640 split tunneling, 640 user authentication infrastructure, 637 selecting CIR aggregate CIR, 436437 asymmetrical CIR, 437 exible CIR, 437 zero CIR, 436 compression type for Frame Relay, 538 core devices in remote access VPNs, 643646 IPSec mode for remote access VPNs, 637 VPN model, 19 serial interfaces debugging, 552 SCTE timing, 499 service architecture (Frame Relay), C-plane, 417418 Service Assurance Agent, 117119 service levels, dening, 79 service providers future of, 89 last mile, 9091 options, 9 service offering, 90 service timestamps command, 313 service-provider dependant VPNs, 19 service-provider independent VPNs, 19 services Frame Relay, 17 benets of, 18 limitations of, 18 standards, 1718 ISDN, 14 benets of, 1516 limitations of, 16
technology offerings, 1011 user- versus corporate-managed, 8 VPNs, 1819 cable modem services, 22 cable modems, 20 limitations of, 19 satellite services, 2830 standards, 21 wireless broadband services, 2527 xDSL services, 2225 Windows 2000, RPC, 402403 session layer (OSI model), 99 SF (Super Frame), 43 SGBP (Stack Group Bidding Protocol), 278 queries, debugging, 351 Shannon, Claude, 12 Shannons Capacity Theorem, 38 shared secrets, PFS, 627 short cable lengths, 183 short command format (Cisco IOS), 102 show cdp neighbors command, 103 show controllers bri0 command, 316 show dialer command, 373374 show interface serial 0 command, 502505 show isdn active command, 372 show isdn status command, 315, 320, 360363 show modem operational status command, 224 signaling (ISDN), D channel, 234 signals amplitude, 40 analog, 37 frequency, 40 site-to-site VPNs, 596 versus remote access VPNs, 633634 size estimates of distance vector routing protocols, 467 of link-state routing protocols, 467468 sliding windows, 443 slip seconds on T1 circuits, 186 slow busy signals, debugging, 227 slow connection speeds increasing, 226 sources of, 223224
858
snapshot routing
snapshot routing, 290, 292 snifng W2K trafc, 402403 SNR (signal-to-noise ratio), affecting factors, 128129 soft skills versus technical skills, 95 software global dialer, 13 compression, 542543 SONET (Synchronous Optical Network), 80 sparse mode (PIM), Frame Relay multicast conguration, 482483 specifying loopback format of T1 circuits, 183 SPID (service prole identier), 253, 308 configuring, 260262 split tunneling, implementing in remote access VPNs, 640 spoke conguration Frame Relay point-to-multipoint connection, 460461 point-to-point Frame Relay connections, 465466 spoong, 290 SS (spread spectrum) RF transmissions DSSS, 49 FHSS, 48 SS7 (Signaling System 7), 7879 STAC data compression, 477 Stack Group Bidding Protocol. See SGBP standards CATV data transmission, 741744 Frame Relay, 415 IAs, 415416 service architecture planes, 417418 starting Cisco VPN Client Log Viewer, 686 Static RP, 483 statistical multiplexing, 414, 437 Status Enquiry message format, Consortium LMIs, 514515 Status message format, Consortium LMIs, 515 STS (Station-to-Station protocol), 626 STS-1, 80 subchannels, 42 supervisory messages, 245
supporting remote access services, 7 defining service levels, 9 in-sourcing versus outsourcing, 7 SVCs (switched virtual circuits), 17, 418 switched virtual circuits. See SVCs switches, 82 ISDN, 252253, 259260 symbols, 50 synchronization, clocking, 55 synchronous data transmission, 71 syntax, IOS-based ping command, 110 synthesized radio technology, 46
T
T1 circuits, 7677 bit errors, checking, 183184 controller status, verifying, 181183 errors, 187 framing ESF signal format, 63 SF signal format, 6263 linecode violations, 186 loopback features, identifying, 183 ones density, 131 pathcode violations, 186 physical layer alarms, 184, 186 slip seconds, 186 T3 framing, M23 signal format, 6364 tandems, 8283 TAs (terminal adapters), 238 Tc (committed interval), 434 T-carriers, 75 E1, 77 T1, 7677 TCP boomerangs, 751 TDM (time-division multiplexing), 74, 414 D channels, 393 TDRs (time domain reectometers), 23 TE1 devices, 238 TE2 devices, 238
Tunnel mode (IPSec)
859
technology offerings, 1011 Frame Relay, 17 benets of, 18 limitations of, 18 standards, 1718 ISDN, 14 benets of, 1516 limitations of, 16 VPNs, 1819 cable modem services, 2022 limitations of, 19 satellite services, 2830 wireless broadband services, 2527 xDSL services, 2225 TEIs (terminal endpoint identiers), 190 Telnet sessions, logging to console, 548 terminal servers, 86 termination equipment, remote access VPNs, 641642 performance criteria, 646648 selecting core devices, 643, 645646 termination sequence (PPP), 352353 testing D channel, 327 remote users router on Frame Relay multicast network, 577 testing network connectivity extended ping command, 111 Netcat utility, 115117 ping command, 110114 tracert command, 114115 text dial-in configuring, 150151 network design, 143 text dial-out configuring, 164168 network design, 144 throughput, Frame Relay, 444 time domain reectometers, 23 time-division multiplexing. See TDM timeouts, modem authentication, 219221 timeslots, line code errors, 130 timestamps, applying, 313314
timing, SCTE, 499 token bucket lters, 483 topologies discovering baseline behavior, 103105 Frame Relay, 441 T-plane (ISDN), 236 tracert command, 114115 tracing Frame Relay multicast networks, 577580 trafc shaping, 483484 ELMI, 487488 Frame Relay, 441443, 534 BECNs, 536 FECNs, 535 apping routes, investigating, 572 high RTT numbers, investigating, 567569 slow performance, investigating, 569572 verifying settings, 566 generic, 484486 map classes, 486487 transit delay, Frame Relay, 444 transmission rates, Shannons Capacity Theorem, 38 transport layer (OSI model), 98 Transport mode (IPSec), implementing in remote access VPNs, 637 transport mode (IPSec), 612 troubleshooting methodologies, 101102 ISDN BRI recommendations, 359 accessing remote users router, 365369 preconguring routers on both ends, 364365 viewing service layers, 360363 layered approach, 96 troubleshooting tools classifying, 110 extended ping command, 111 Netcat utility, 115117 ping command, 110114 replies, 112 SAA, 117119 tracert command, 114115 Tunnel mode (IPSec), 613 implementing in remote access VPNs, 637
860
tunneling, DPD
tunneling, DPD, 803804 two-way Internet connections, 744 two-way multicast service, Frame Relay, 440 type codes (ICMP messages), 112113
U
UHF (ultra-high frequency) multiple frequency operation, 47 narrowband, 46 synthesized radio technology, 46 UNI (user node interface) bearer services, 438 LMI, 449 Annex D, 451 Cisco-Consortium, 451 ITU-T Q.933 Annex A, 453 Unity client Concentrator Event Log, 699701 event classes, 702704 event security levels, 704705 data not passing, causes of, 784 bad ISP connections, 786787 default MTU size, 786 dropped connections, 786 inaccessible internal domain, 787790 NAT, 785 Event Log Viewer, 685 Client Log Viewer, starting, 686 ISAKMP, 688 reviewing captured data, 688699 extranet issues, 801 dead peer detection, 803804 ESP 50, 801 tunnel keepalives, 802 UDP 500 ISAKMP, 801 failed authentication, causes of bad group name, 774775 DNE Miniport, 776777 miscongured rewalls, 777778 MTU setting too high, 779784
MTU setting too low, 784 RADIUS, 775776 inaccessible internal domain, WINS, 788 incompatible GINAs, 705706 PPPoE problems, causes of IOS conguration, 793795 software, 791793 preliminary troubleshooting steps creating proles, 772 verifying client installation, 771 verifying Internet connection, 767770 restrictions, 676679 troubleshooting checklist, 682685 unnumbered messages, 245 unprotected band (RF), 46 U-plane Frame Relay service architecture, 417 ISDN, 236 upper-layer protocols Frame Relay interoperability, 445 encapsulation, 447 fragmentation, 448 multiprotocol support, 445447 NCPs, 341352 upstream PIM neighbor availability, verifying on Frame Relay networks, 574576 user authentication, remote access VPNs, 637 user participation, troubleshooting ring options, 354355 user/identity authentication, 620 user-managed services, 8 UWB (ultra wideband) technology, 47
V
V.21 standard, 12 V.32 standard, 12 V.32b standard, 12 V.90 calls, limitations of, 129 Van Jacobson header compression, 477480 path characterization model, 105
VPNs (Virtual Private Networks)
861
variable length framing, Frame Relay, 415 VCs (virtual circuits), 415 VDSL (Very-high rate DSL), 25 verifying Cisco PIX VPN connectivity, 722732 DHCP server reachability, 227 Frame Relay configuration DLCI settings, 556562 remote user router status, 553 serial interface, 551 service operation, 553555 trafc shaping, 566 incoming connection type, dial-in troubleshooting procedure, 192194 ISDN configuration D channel functionality, 327 Layer 1 status of PRI circuits, 188 Layer 2 status of PRI circuits, 188190 IP address configuration on Windows operating systems, 769770 line provision, 354 MMP configuration, 284285 modem operability, dial-in troubleshooting procedure, 191192 out of order B channels (NFAS), 227 PPP negotiation, dial-in troubleshooting procedure, 194200 VPN client installation, 771 viewing captured Log Viewer results, 688699 ISDN BRI service layers, 360363 virtual circuits, compression, 477 virtual connections, MLP, 343344 virtual interface templates, 272 virtual ports, 474 virtual proles, 273 VoFR (Voice over Frame Relay), 440 voice digitalization, 73 priority over data, 353354 voice privacy, ISDN conguration, 308309 VPN 3000 Concentrator, conguring, 648649 filters and rules, 650651 Group Lock, 662
IKE peer identity validation, 662 proposals, 656, 658659 IPSec SAs, 661 load balancing, 654655 redundancy, 653 reverse route injection, 655 SAs, 659660 VPNs (Virtual Private Networks), 10, 13, 1819 ADSL, 732 PPoE, 733739 authentication client authentication, 619 DH algorithm, 624627 HMAC, 627628 key management, 624627 RADIUS, 621623 user/identity authentication, 620 cable modem services, 20 limitations of, 22 standards, 21 CATV infrastructure data transmission, 740744 heartbeats, 745 two-way Internet connections, 744 Cisco 3002 HW client, 706 Event Log, 708710, 712 initial troubleshooting checklist, 707 Cisco Easy VPN Client, 713 client status, displaying, 716 debugging IPSec key events, 717719 initial troubleshooting checklist, 714716 monitoring, 720721 resetting connection, 717 restrictions, 713714 Cisco PIX VPN connectivity, verifying, 722732 restrictions, 722 Cisco Unity client Concentrator Event Log, 699705 Event Log Viewer, 685699 incompatible GINAs, 705706 restrictions, 676679 troubleshooting checklist, 682685
862
Cisco VPN 3002, connection establishment
Cisco VPN 3002, connection establishment, 795800 data not passing, causes of, 784 bad ISP connections, 786787 default MTU size, 786 dropped connections, 786 inaccessible internal domain, 787790 NAT, 785 enterprise VPNs, 593594 categories of, 595 data link layer, 599603 rewall-based VPNs, 597598 network layer, 604607 remote access VPNs, 595 site-to-site VPNs, 596 extranet issues, 801 dead peer detection, 803804 ESP 50, 801 tunnel keepalives, 802 UDP 500 ISAKMP, 801 failed authentication, causes of bad group name, 774775 DNE Miniport, 776777 miscongured rewalls, 777778 MTU setting too high, 779, 781784 MTU setting too low, 784 RADIUS, 775776 inaccessible internal domain, causes of, 788 LAN-specific issues inability to log in, 760 MTU settings, 754758 NAT, multiple client handling, 753 packet size, 758760 latency, 228 limitations of, 19 PPPoE problems, causes of IOS conguration, 793795 software, 791793 preliminary troubleshooting steps creating proles, 772 verifying client installation, 771 verifying Internet connection, 767770 remote access
change management, 636 conguration management, 635 design objectives, 634635 operations management, 636 security issues, 636641 termination equipment, 641648 satellite services, 28 BST, 29 IPA, 28 LEO satellites, 30 satellite systems, 745746 bandwidth, 747 BST protocol, 750 error control coding, 746 FITFEEL protocol, 751 IPSec, 752753 manipulating TCP stack, 749750 performance, 749 TCP efciency, 747748 site-to-site versus remote access VPNs, 633634 wireless systems, 25, 745746 bandwidth, 747 error control coding, 746 limitations of, 27 LMDS, 2627 MMDS, 2526 TCP efciency, 747748 unlicensed frequencies, 27 xDSL services, 22 ADSL, 24 CDSL, 24 FDIs, 2223 HDSL, 24 IDSL, 24 RADSL, 24 SDSL, 24 TDRs, 23 VDSL, 25
xDSL services
863
W
WAN links PRI circuits Layer 1 status, verifying, 188 Layer 2 status, verifying, 188190 troubleshooting, 188 T1 circuits alarm states, 184, 186 BERT testing, 183184 line code violations, 186 loopback features, 183 pathcode violations, 186 slip seconds, 186 T1 errors, 187 troubleshooting, 18186 verifying controller status, 182 well-known ports, 403405 Whitecamp network protocol, 53 WIC T1 pinouts, 499 wi-, 44 windowing, 443 Windows operating systems verifyingIP address configuration, 769770 Windows 2000 DDR, 399408 ports, 403 RPC, 402403 well-known ports, 403405 wireless broadband services, 25 3G, 9192 limitations of, 27 LMDS, 2627 MMDS, 2526 unlicensed frequencies, 27 wireless cable, 26 wireless VPNs, 745746 bandwidth, 747 error control coding, 746 TCP efficiency, 747748 WISP (wireless ISP), 54
WLANs 802.11a, 5152 802.11e, 53 802.11g, 52 barker sequence, 50 IR radio-channel, 45 line-coding techniques, 4448 LTI systems, 47 modulation, 4445, 48 narrowband technologies, 46 photonic, 45 SS RF transmissions DSSS, 49 FHSS, 48 UHF, multiple frequency operation, 46 UWB technology, 47
X
X.25 protocol, 17 versus Frame Relay, 414415 XAUTH, 623 xDSL services, 22 2B1Q coding, 55, 5859 ADSL, 24 CDSL, 24 coding schemes, 4142 FDIs, 2223 HDSL, 24 IDSL, 24 provisioning enterprise remote access services, 3334 RADSL, 24 SDSL, 24 TDRs, 23 VDSL, 25
864
yellow alarms
Y-Z
yellow alarms, 185 zero CIR, 436 zero-suppression schemes, 6162

CISCO Book

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

CISCO Book

Uploaded by

Copyright:

Available Formats

5259.

book Page i Thursday, October 10, 2002 5:39 PM

Troubleshooting Remote Access Networks

201 W 103rd Street Indianapolis, IN 46290 USA

5259.book Page ii Thursday, October 10, 2002 5:39 PM

Troubleshooting Remote Access Networks

Warning and Disclaimer

5259.book Page iii Thursday, October 10, 2002 5:39 PM

Team Coordinator Cover Designer Composition Indexer

5259.book Page iv Thursday, October 10, 2002 5:39 PM

About the Author

About the Technical Reviewers

5259.book Page v Thursday, October 10, 2002 5:39 PM

5259.book Page vi Thursday, October 10, 2002 5:39 PM

5259.book Page vii Thursday, October 10, 2002 5:39 PM

fm.fm Page viii Monday, October 14, 2002 1:34 PM

5259.book Page ix Thursday, October 10, 2002 5:39 PM

5259.book Page x Thursday, October 10, 2002 5:39 PM

Part V Chapter 19 Chapter 20 Chapter 21 Chapter 22 Appendix A Index 835

5259.book Page xi Thursday, October 10, 2002 5:39 PM

Provisioning of Enterprise Remote Access Services Summary 35 35 37 38

Review Questions Chapter 2

Telecommunication Basics Shannons Capacity Theorem

5259.book Page xii Thursday, October 10, 2002 5:39 PM

Review Questions Chapter 3 The Cloud 69

Carriers, Service Providers, and How Traffic Is Carried FDM 71

Digitalization of the Signal and Pulse Code Modulation TDM 73 75

5259.book Page xiii Thursday, October 10, 2002 5:39 PM

ISPs and ASPs

Review Questions Chapter 4

Review Questions Part II Chapter 5 Dial 123

Dial Technology Background Overview of Modems 125

5259.book Page xiv Thursday, October 10, 2002 5:39 PM

Review Questions Chapter 6

Review Questions Chapter 7

5259.book Page xv Thursday, October 10, 2002 5:39 PM

Troubleshooting Dial-Out Service

Review Questions Chapter 8

Dial Troubleshooting Scenarios

5259.book Page xvi Thursday, October 10, 2002 5:39 PM

ISDN Design Solutions

Review Questions Chapter 11

Cisco ISDN Configuration Solutions

Review Questions Chapter 12

ISDN BRI Troubleshooting

5259.book Page xvii Thursday, October 10, 2002 5:39 PM

Review Questions Chapter 13

Troubleshooting Scenarios for ISDN BRI

5259.book Page xviii Thursday, October 10, 2002 5:39 PM

Review Questions Chapter 15

5259.book Page xix Thursday, October 10, 2002 5:39 PM

Review Questions Chapter 17

Frame Relay Troubleshooting

Beginning the Frame Relay Troubleshooting Process

5259.book Page xx Thursday, October 10, 2002 5:39 PM

Scenario 2: Mismatched DLCI Settings

VPN Technology Background

5259.book Page xxi Thursday, October 10, 2002 5:39 PM

Remote Access VPN Design and Configuration Solutions

Review Questions Chapter 21

Remote Access VPN Troubleshooting

Review Questions Chapter 22

5259.book Page xxii Thursday, October 10, 2002 5:39 PM

Answers to Review Questions