Cisco Frame Relay Solutions Guide

Next Page

Book Cover
Cisco Frame Relay Solutions Guide
By Jonathan Chin
...............................................
Publisher: Cisco Press
Pub Date: March 17, 2004
ISBN: 1-58705-116-8
Pages: 696

Table of Contents | Index
Overview

Implement Frame Relay solutions on Cisco networks with this definitive resource

  • Design the perfect Frame Relay solution, using the detailed explanation of the Frame Relay implementation process

  • Configure Frame Relay on Cisco routers with comprehensive step-by-step instructions

  • Understand each feature of Frame Relay by using configuration examples and explanations

  • Use Cisco oriented case studies with design scenarios to understand real-life examples of each feature's application and relevance

  • Contains valuable tips and hints for troubleshooting Frame Relay connections

Today, with Frame Relay's widespread popularity, major service providers around the world offer Frame Relay as one of their core services, and it has become an important technology for connecting data networks across North America, Europe, and Asia. In short, Frame Relay is a high-speed, high-performance, Layer 2 packet-switched technology designed for communication across WANs. Frame Relay is often described as a streamlined version of the X.25 protocol, and it can be implemented over a variety of other network interfaces, including ISDN. Frame Relay users have found that it provides a number of benefits over alternative technologies:

  • Lower cost of ownership

  • Well-established and widely adopted standards that allow open architecture and plug-and-play service implementation

  • Low overhead combined with high reliability

  • Network scalability, flexibility, and disaster recovery

  • Interworking with other new services and applications, such as ATM

Along with these benefits and the growing popularity of Frame Relay comes the need for information and solutions to design issues, implementation, quality of service, and high availability. To meet this need, Cisco Frame Relay Solutions Guide provides comprehensive coverage of Frame Relay technologies and the Cisco Frame Relay solutions developed in Cisco IOS Software from release 12.0 up to 12.2(T). Both Frame Relay beginners, who need to understand the technology, and advanced readers, who need information on the wide range of Frame Relay features Cisco offers, will benefit from this book. However, Cisco Frame Relay Solutions Guide is a useful design, implementation, and configuration guide for networking professionals of all levels.

This book is part of the Networking Technology Series from Cisco Press, which offers networking professionals valuable information for constructing efficient networks, understanding new technologies, and building successful careers.

Next Page


Table of Contents

Previous Page
Next Page

Book Cover
Cisco Frame Relay Solutions Guide
By Jonathan Chin
...............................................
Publisher: Cisco Press
Pub Date: March 17, 2004
ISBN: 1-58705-116-8
Pages: 696

Table of Contents | Index

Copyright
About the Author
 | About the Technical Reviewers
Acknowledgments
Icons Used in This Book
Command Syntax Conventions
Introduction
 | Goals and Methods
 | Who Should Read This Book?
 | How This Book Is Organized
Part I. Frame Relay Technology
 | Chapter 1. Introduction to Frame Relay
 |  | Frame Relay Defined
 |  | Frame Relay Virtual Circuits
 |  | The Frame Relay Header
 |  | The Standardization of Frame Relay
 |  | The Origins of Frame Relay: X.25
 |  | Frame Relay's Current Role
 |  | The Future of Frame Relay
 |  | Frame Relay Terminology
 |  | Summary
 |  | Review Questions
 |  | Reference
 | Chapter 2. Cisco Frame Relay Devices and Network Implementation
 |  | Understanding Frame Relay Devices and Network Implementation
 |  | Frame Relay Serial Interfaces and Cabling Standards
 |  | The Cisco Family of Router and Switch Platforms for Frame Relay WAN Connectivity
 |  | Frame Relay Access Speeds and CIR
 |  | Introduction to the Cisco Frame Relay Implementation
 |  | Summary
 |  | Review Questions
 | Chapter 3. Planning and Managing Frame Relay Networks
 |  | Network Planning
 |  | Planning the CIR Subscription
 |  | Frame Relay Topology Options
 |  | Performance Management
 |  | Managing Broadcast Traffic
 |  | Providing a Backup to Frame Relay Virtual Circuits
 |  | A Common Issue Encountered in Frame Relay Networks
 |  | Summary
 |  | Review Questions
 | Chapter 4. Cisco Frame Relay Configurations
 |  | Configuring Frame Relay
 |  | Enabling Frame Relay Encapsulation
 |  | Configuring the LMI Type on a Frame Relay Interface
 |  | Configuring Static and Dynamic DLCI to Network Layer Address Mapping
 |  | Configuring Frame Relay Subinterfaces
 |  | Using Frame Relay Point-to-Point Subinterfaces
 |  | Configuring a Cisco Router as a Frame Relay Switch
 |  | Local Significance Approach to DLCI Assignment
 |  | Verifying Frame Relay Connections with IOS show Commands
 |  | Troubleshooting Frame Relay Connections with Cisco IOS debug Commands
 |  | Summary
 |  | Review Questions
 |  | Reference
Part II. Cisco Frame Relay Solutions for Policing and Shaping
 | Chapter 5. Frame Relay Traffic Shaping
 |  | Current Issues
 |  | Solutions to Current Issues
 |  | Frame Relay Traffic Shaping Explained
 |  | How Frame Relay Traffic Shaping Works
 |  | Adaptive Shaping to BECN
 |  | Adaptive Shaping to ForeSight
 |  | Configuring Frame Relay Traffic Shaping
 |  | Creating a Traffic Shaping Map Class
 |  | Associating the Frame Relay Map Class
 |  | Monitoring Frame Relay Traffic Shaping Information
 |  | Configuring Discard Eligibility (DE)
 |  | Configuring Frame Relay Broadcast Queue
 |  | Configuring DLCI Priority Levels
 |  | Differences Between Frame Relay Traffic Shaping and Generic Traffic Shaping
 |  | Summary
 |  | Review Questions
 |  | Reference
 |  | Case Study: Managing Data Traffic
 |  | Case Study: A Small Hub-and-Spoke Network Running Voice and Video Traffic
 | Chapter 6. Cisco Frame Relay Switching Enhancements
 |  | Current Issues
 |  | Solutions to Current Issues
 |  | Configuring Frame Relay Switching Enhancements on a Cisco Router
 |  | Monitoring and Verifying Frame Relay Switching Enhancements on a Cisco Router
 |  | Summary
 |  | Review Questions
 |  | Reference
 |  | Case Study: Frame Relay Switching over ISDN
 | Chapter 7. Cisco Frame Relay End-to-End Keepalive
 |  | Current Issues
 |  | Solutions to Current Issues
 |  | Frame Relay End-to-End Keepalive Feature Defined
 |  | Configuring Frame Relay End-to-End Keepalive
 |  | Monitoring and Verifying Frame Relay End-to-End Keepalive
 |  | Summary
 |  | Review Questions
 |  | Reference
 |  | Case Study: Using LMI and Frame Relay End-to-End Keepalive
Part III. Cisco Frame Relay Solutions for Traffic Management
 | Chapter 8. Frame Relay to ATM Interworking
 |  | ATM Technology
 |  | Interworking Frame Relay with ATM
 |  | Frame Relay Forum Implementation Agreement Document Number FRF.5
 |  | Frame Relay Forum Implementation Agreement Document Number FRF.8.1
 |  | Congestion Indication Support in FRF.8.1
 |  | Supported Cisco Platforms for Frame Relay to ATM Interworking
 |  | Configuring FRF.5 Network Interworking
 |  | Verifying FRF.5 Configuration
 |  | Configuring FRF.8.1 Service Interworking
 |  | Summary
 |  | Review Questions
 |  | References
 | Chapter 9. Adaptive Frame Relay Traffic Shaping for Interface Congestion
 |  | Current Issues
 |  | Solutions for Current Issues
 |  | Configuring Adaptive Frame Relay Traffic Shaping for Interface Congestion
 |  | Verifying Adaptive Frame Relay Traffic Shaping for Interface Congestion
 |  | Summary
 |  | Review Questions
 |  | Reference
 |  | Case Study: Without Adaptive Frame Relay Traffic Shaping for Interface Congestion
 |  | Case Study: With Adaptive Frame Relay Traffic Shaping for Interface Congestion
 | Chapter 10. Point-to-Point Protocol (PPP) over Frame Relay
 |  | Requirements for PPP over Frame Relay
 |  | RFC 1973 and Cisco Implementation of PPP over Frame Relay
 |  | PPP over Frame Relay Frame Format
 |  | Monitoring PPP over Frame Relay
 |  | Summary
 |  | Review Questions
 |  | References
 |  | Case Study: Verifying PPP over Frame Relay
 | Chapter 11. Frame Relay Switched Virtual Circuit (SVC)
 |  | Introduction to Frame Relay SVC
 |  | Current Issues
 |  | Solutions for Current Issues
 |  | Setting Up an SVC Operation
 |  | Cisco Implementation of Frame Relay SVC
 |  | SVC Configuration Tasks
 |  | Monitoring Frame Relay SVC
 |  | Summary
 |  | Review Questions
 |  | References
 |  | Case Study: Frame Relay SVC Network Between Two Remote Offices
 | Chapter 12. X.25 over Frame Relay: Using the Annex G Feature
 |  | Current Issues
 |  | Solutions to Current Issues
 |  | Annex G Feature
 |  | Basic X.25 Configuration Tasks on a Cisco Router
 |  | Summary
 |  | Review Questions
 |  | References
 |  | Case Study: Use of the Annex G Feature
 | Chapter 13. Frame Relay Enhanced Local Management Interface (ELMI)
 |  | Current Issues
 |  | Solutions to Current Issues
 |  | Configuring the Frame Relay ELMI Feature
 |  | Operation of MIB
 |  | Summary
 |  | Review Questions
 |  | References
 | Chapter 14. Multilink Frame Relay (FRF.16)
 |  | Current Issues
 |  | Solutions to Current Issues
 |  | Multilink Frame Relay Setup and Operation
 |  | Cisco Implementation of Multilink Frame Relay
 |  | Configuring Multilink Frame Relay on Cisco Routers
 |  | Monitoring and Troubleshooting Multilink Frame Relay
 |  | Summary
 |  | Review Questions
 |  | References
 | Chapter 15. Compression over Frame Relay
 |  | Current Issues
 |  | Solutions to Current Issues
 |  | How Compression Works
 |  | Technical Overview of Cisco IOS Frame Relay Compression Schemes
 |  | Configuring Frame Relay Proprietary Payload Compression
 |  | Configuring Frame Relay FRF.9 Payload Compression
 |  | Configuring TCP/IP Header Compression over Frame Relay
 |  | Configuring Frame Relay RTP Header Compression
 |  | Express Header Compression for Cisco IOS Release 12.1
 |  | Frame Relay Compression Design Guidelines
 |  | Verifying and Monitoring Frame Relay Compressions on Cisco Routers
 |  | Troubleshooting Frame Relay Compression
 |  | Summary
 |  | Review Questions
 |  | References
 | Chapter 16. Frame Relay Fragmentation
 |  | Current Issues
 |  | Solutions to Current Issues
 |  | Cisco Implementations of Frame Relay Fragmentation
 |  | Monitoring and Troubleshooting Frame Relay Fragmentation
 |  | Summary
 |  | Review Questions
 |  | References
 |  | Case Study: Implementing Fragmentation on a Voice and Data Network
Part IV. Cisco Frame Relay Solutions for Congestion Management
 | Chapter 17. Frame Relay Congestion Management
 |  | The Need for Queuing on Frame Relay Networks
 |  | Hierarchical Queuing Architecture for Frame Relay
 |  | Frame Relay PIPQ
 |  | Configuring Frame Relay PIPQ
 |  | Monitoring and Troubleshooting Frame Relay PIPQ
 |  | Summary
 |  | Review Questions
 |  | References
 | Chapter 18. Frame Relay Class-Based Weighted Fair Queuing (CBWFQ) and Low Latency Queuing (LLQ)
 |  | Overview of the MQC
 |  | CBWFQ
 |  | Configuring CBWFQ for Frame Relay
 |  | Monitoring and Troubleshooting CBWFQ for Frame Relay
 |  | LLQ, or PQ/CBWFQ
 |  | Monitoring and Troubleshooting LLQ for Frame Relay
 |  | Summary
 |  | Review Questions
 |  | References
 | Chapter 19. Frame Relay Queuing and Fragmentation at the Interface
 |  | Overview of Frame Relay Queuing and Fragmentation at the Interface
 |  | Monitoring and Troubleshooting Frame Relay Queuing and Fragmentation at the Interface
 |  | Summary
 |  | Review Questions
 |  | Reference
 | Chapter 20. Link Fragmentation and Interleaving (LFI) for Frame Relay Virtual Circuits
 |  | LFI Using MLP Overview
 |  | Configuring Cisco IOS MLP LFI for Frame Relay on a Cisco Router
 |  | Monitoring and Troubleshooting the Cisco IOS MLP LFI over Frame Relay Feature
 |  | Summary
 |  | Review Questions
 |  | Reference
 |  | Case Study: LFI over Frame Relay Using MLP
Part V. Cisco Frame Relay Solutions for Congestion Avoidance and Signaling
 | Chapter 21. Weighted Random Early Detection (WRED) for Frame Relay
 |  | Overview of Congestion Avoidance Mechanisms
 |  | Configuring WRED for Frame Relay
 |  | Monitoring and Troubleshooting Tail Drop and WRED
 |  | Summary
 |  | Review Questions
 |  | References
 | Chapter 22. Resource Reservation Protocol (RSVP) for Frame Relay
 |  | General Overview of RSVP
 |  | RSVP Support for Frame Relay
 |  | Configuring RSVP Support for Frame Relay
 |  | Monitoring and Troubleshooting RSVP Support for Frame Relay
 |  | Summary
 |  | Review Questions
 |  | Reference
Appendix A. Answers to Review Questions
 | Chapter 1
 | Chapter 2
 | Chapter 3
 | Chapter 4
 | Chapter 5
 | Chapter 6
 | Chapter 7
 | Chapter 8
 | Chapter 9
 | Chapter 10
 | Chapter 11
 | Chapter 12
 | Chapter 13
 | Chapter 14
 | Chapter 15
 | Chapter 16
 | Chapter 17
 | Chapter 18
 | Chapter 19
 | Chapter 20
 | Chapter 21
 | Chapter 22
Index

Previous Page


Copyright

Copyright© 2004 Cisco Systems, Inc.

Published by:
Cisco Press
800 East 96th Street
Indianapolis, IN 46240 USA

All rights reserved. No part of this book may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying, recording, or by any information storage and retrieval system, without written permission from the publisher, except for the inclusion of brief quotations in a review.

Printed in the United States of America 1 2 3 4 5 6 7 8 9 0

First Printing March 2004

Library of Congress Cataloging-in-Publication Number 2002107458

Warning and Disclaimer

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

Trademark Acknowledgments

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

Corporate and Government Sales

Cisco Press offers excellent discounts on this book when ordered in quantityfor bulk purchases or special sales.

For more information please contact: U.S. Corporate and Government Sales 1-800-382-3419 corpsales@pearsontechgroup.com

For sales outside the U.S. please contact: International Sales international@pearsoned.com

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.

Credits

Publisher | John Wait
Editor-in-Chief | John Kane
Executive Editor | Jim Schachterle
Cisco Representative | Anthony Wolfenden
Cisco Press Program Manager | Nannette M. Noble
Acquisitions Editor | Tammi Barnett
Production Manager | Patrick Kanouse
Development Editor | Deborah Doorley
Project Editor | Argosy Publishing
Copy Editor | Ginny Kaczmarek
Technical Editors | Henry Benjamin,
 | Harold Ritter,
 | Eddie Chami,
 | Muneesh Talwart
Team Coordinator | Tammi Barnett
Cover Designer | Louisa Klucznik
Composition | Argosy Publishing
Indexer | Larry Sweazy

Corporate Headquarters
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134-1706
USA
www.cisco.com
Tel: 408 526-4000
800 553-NETS (6387)
Fax: 408 526-4100

European Headquarters
Cisco Systems International BV
Haarlerbergpark
Haarlerbergweg 13-19
1101 CH Amsterdam
The Netherlands
www-europe.cisco.com
Tel: 31 0 20 357 1000
Fax: 31 0 20 357 1100

Americas Headquarters
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134-1706
USA
www.cisco.com
Tel: 408 526-7660
Fax: 408 527-0883

Asia Pacific Headquarters
Cisco Systems, Inc.
Capital Tower
168 Robinson Road
#22-01 to #29-01
Singapore 068912
www.cisco.com
Tel: +65 6317 7777
Fax: +65 6317 7799

Cisco Systems has more than 200 offices in the following countries and regions. Addresses, phone numbers, and fax numbers are listed on the Cisco.com Web site at www.cisco.com/go/offices.

Argentina • Australia • Austria • Belgium • Brazil • Bulgaria • Canada • Chile • China PRC • Colombia • Costa Rica • Croatia • Czech Republic • Denmark • Dubai, UAE • Finland • France • Germany • Greece • Hong Kong SAR • Hungary • India • Indonesia • Ireland • Israel • Italy • Japan • Korea • Luxembourg • Malaysia • Mexico • The Netherlands • New Zealand • Norway • Peru • Philippines • Poland • Portugal Puerto Rico • Romania • Russia • Saudi Arabia • Scotland • Singapore • Slovakia • Slovenia • South Africa • Spain • Sweden • Switzerland • Taiwan • Thailand • Turkey • Ukraine • United Kingdom • United States • Venezuela • Vietnam • Zimbabwe

Copyright © 2003 Cisco Systems, Inc. All rights reserved. CCIP, CCSP, the Cisco Arrow logo, the Cisco Powered Network mark, the Cisco Systems Verified logo, Cisco Unity, Follow Me Browsing, FormShare, iQ Net Readiness Scorecard, Networking Academy, and ScriptShare are trademarks of Cisco Systems, Inc.; Changing the Way We Work, Live, Play, and Learn, The Fastest Way to Increase Your Internet Quotient, and iQuick Study are service marks of Cisco Systems, Inc.; and Aironet, ASIST, BPX, Catalyst, CCDA, CCDP, CCIE, CCNA, CCNP, Cisco, the Cisco Certified Internetwork Expert logo, Cisco IOS, the Cisco IOS logo, Cisco Press, Cisco Systems, Cisco Systems Capital, the Cisco Systems logo, Empowering the Internet Generation, Enterprise/Solver, EtherChannel, EtherSwitch, Fast Step, GigaStack, Internet Quotient, IOS, IP/TV, iQ Expertise, the iQ logo, LightStream, MGX, MICA, the Networkers logo, Network Registrar, Packet, PIX, Post-Routing, Pre-Routing, RateMUX, Registrar, SlideCast, SMARTnet, StrataView Plus, Stratm, SwitchProbe, TeleRouter, TransPath, and VCO are registered trademarks of Cisco Systems, Inc. and/or its affiliates in the U.S. and certain other countries.

All other trademarks mentioned in this document or Web site are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (0303R)

Printed in the USA

Dedications

To my lovely wife, Bang Tyng, for all her understanding and support. And to Snowy, our adorable Maltese, for all the joy she has brought into our life.


About the Author

Jonathan Chin, CCIE No. 11105, is a development test engineer in the Packet Test group under the Internet Technologies Division (ITD) within Cisco Systems. Based in Singapore, his responsibilities include development and regression testing for advanced Cisco Frame Relay, ATM, and X.25 features in Cisco IOS Software releases. Currently, Jonathan is actively involved with new feature test projects in Layer 2 Tunneling Protocol (L2TPv3) and Any Transport over MPLS (AToM) technologies. Jonathan also holds CCNP, CCNA, and Wireless LAN Design certifications from Cisco and has earned his bachelor of applied science degree in computer engineering at NTU Singapore.


About the Technical Reviewers

Harold Ritter, CCIE No. 4168 (R&S and SP), is a network consulting engineer with Cisco Advanced Services Team for Service Provider. He is responsible for helping Cisco top-tier service provider customers to design, implement, and troubleshoot routing protocols and MPLS solutions in their environment. He has been a network engineer for more than 10 years.

Henry Benjamin, CCIE No. 4695, has more than 10 years experience with Cisco networks. Henry recently worked for Cisco in the internal IT department helping to design and implement networks throughout Australia and Asia. Henry was a key member of the CCIE global team, where he was responsible for writing new laboratory examinations and questions for the coveted CCIE examinations. Henry is a Cisco Press author, triple CCIE, and has written the titles CCNP Practical Studies and CCIE Security Exam Certification Guide.


Acknowledgments

This book would not have been possible at all if not for the hard work of these important people.

First, I would like to thank the entire Cisco Press team for making this book possible. John Kane, Amy Lewis, Deborah Doorley, Chris Cleveland, and Jim Schachterle are absolutely incredible people, and I truly believe they are the finest publishing team in the business. John Kane started the development for this project and has always offered me his help whenever I needed it. Although Amy Lewis has left the Cisco Press team, she gave me her guidance, advice, and all the help I needed to stay on the right track. I would like to personally thank Amy for the wonderful job she did when she was the acquisitions editor of this project. Deborah Doorley, my development editor, did an excellent job in the development phase to ensure that I met my deadlines and schedules without cutting any corners in my work. Deb has offered me innovative ideas and suggestions on how to improve the content of the book. Chris Cleveland gave me valuable assistance during the review and the production phase. Jim Schachterle has been absolutely professional in guiding me through this project. It was a joy to work with Jim. I would like to thank Patrick Kanouse and San Dee Phillips for their excellent job during the final stage of editing this book.

Then, I would like to express my deepest gratitude to a handful of folks special to me at Packet Test. I am most grateful to Leonard Wu. Leonard mentored and guided me through my first few challenging months at Cisco when I needed to pick up many new things quickly from scratch. I would like to thank Brian Luong, Rick King, and Walter Griffeth, my managers at Packet Test, for their vote of confidence in me and for being so supportive.

A big "thank you" goes out to Horacio Zambrana and Alice Riedmiller. Both Horacio and Alice are technical experts in their own rights, and they gave me their tremendous support and advice when I was writing this book.

Special thanks and acknowledgment go out to the Frame Relay Development Team from the IOS WAN group at Cisco. Robert Verkroost, Chifei Wei Cheng, George Wilkie, Greg Fowler, and Alan Robertson represent the industry's premier group of WAN experts in the Frame Relay technology. These people are very much responsible for the Frame Relay features described in this book. I am especially grateful to George for the valuable help and advice he has given to me all these years.

Last but definitely not least, I would like to thank all technical reviewers who have contributed to this book by ensuring its technical accuracy and completeness. I would like to thank Henry Benjamin especially. Henry is always generous in offering me his valuable opinions and suggestions to improve the book. Henry, thank you for making this book so much better!


Icons Used in This Book

Previous Page
Next Page


Command Syntax Conventions

The conventions used to present command syntax in this book are the same conventions used in the IOS Command Reference. The Command Reference describes these conventions as follows:

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

  • Italics indicate arguments for which you supply actual values.

  • Vertical bars (|) separate alternative, mutually exclusive elements.

  • Square brackets [ ] indicate optional elements.

  • Braces { } indicate a required choice.

  • Braces within brackets [{ }] indicate a required choice within an optional element.


Introduction

Frame Relay has come a long way and for the last decade, Frame Relay has become increasingly important in terms of data networking by providing a cost-effective alternative for high-speed bandwidth. Today, Frame Relay services are ubiquitous in many parts of the world, and Cisco is an industry leader in the data networking segment providing Frame Relay solutions on Cisco product-based networks. The feature-rich Cisco IOS Software supports a host of Frame Relay features, which are based on industry or proprietary standards. This book aims to provide readers with knowledge of Frame Relay and how to implement Frame Relay services on Cisco product-based networks.


Goals and Methods

The primary goal of this book is to provide readers with complete knowledge on Frame Relay technology and Frame Relay solutions in the Cisco IOS Software. For beginners, the book makes you much more knowledgeable about the Frame Relay technology, and it teaches you how to configure basic Frame Relay services on a Cisco router. For advanced readers, the information provided by the book helps to advance your knowledge of the Frame Relay technology.

Throughout this book, case studies, scenarios, and configuration examples are given to provide readers with a practical aspect on configuring the Frame Relay technology on the Cisco IOS Software. The key methodology used in the book is to introduce readers to a new Frame Relay feature in every chapter. Each chapter begins the discussion by introducing readers to the most common issues and problems encountered by Frame Relay customers and how the Frame Relay feature under discussion helps to resolve the identified issues and problems. Subsequently, readers will be shown the configuration tasks involved in setting up the Frame Relay feature on Cisco devices. Along the way, detailed configuration examples will be supplied to allow readers to observe how the Frame Relay feature works. Finally, the Cisco IOS show and debug commands relevant to the Frame Relay feature will be explained. To summarize, the book presents information to the readers by using the following methods:

  • Provide complete information of a new Frame Relay feature in each chapter

  • Identify the most common issues and problems surrounding Frame Relay customers

  • Explain how the Frame Relay feature discussed can resolve the identified issues and problems

  • Demonstrate the configuration tasks required to set up the Frame Relay feature on Cisco devices

  • Provide practical configuration examples to explain the configuration tasks involved in setting up a Frame Relay feature

  • Demonstrate the Cisco IOS show and debug commands relevant to monitoring and maintaining the Frame Relay feature discussed


Who Should Read This Book?

The audience for this book is anyone who needs a full understanding of the Frame Relay technology on Cisco product-based networks. This book aims to provide readers with comprehensive and up-to-date information on the latest Frame Relay features and solutions offered by the Cisco IOS Software. Network designers, administrators, or engineers who need to implement, design, or maintain Frame Relay technology on a day-to-day basis will find this book a valuable resource.

If you are a "beginner" who has some basic networking knowledge and an interest in the Frame Relay technology, you will find the information presented on basic Frame Relay concepts in this book useful.

If you are an intermediate-level networking professional who has experience with routing and switching, this book helps you to advance your knowledge on Wide Area Networking with Frame Relay technology.

If you are a highly experienced networking expert, this book presents you with a structured review of the new Frame Relay solutions and features introduced in the recent Cisco IOS Software releases.

Frame Relay is a common component of the CCNA, CCNP, and CCIE certification exams. The CCIE is the most prestigious and difficult to achieve certification. This book helps you to prepare for the exam and increases your chances of passing.


How This Book Is Organized

Although this book could be read cover-to-cover, it is designed to be flexible and allow you to easily move between chapters and sections of chapters to cover just the material that you need more work with. This book is organized into five separate parts. Each part addresses a group of Frame Relay features and solutions with functionalities in common. If you do intend to read them all, the order in the book is an excellent sequence to use.

Part I addresses the basic Frame Relay technology. For beginners, it is recommended to begin reading with the chapters in Part I. Chapters 1 and 2 provide readers with an introduction of Frame Relay technology and an overview of Cisco Frame Relay devices. Chapters 3 and 4 offer suggestions to readers on Frame Relay network planning and how to configure basic Frame Relay commands on Cisco devices. The chapters Part I covers are as follows:

Chapter 1, "Introduction to Frame Relay" This chapter provides beginners with a basic knowledge of the Frame Relay technology and reinforces concepts of the Frame Relay technology for advanced readers.

Chapter 2, "Cisco Frame Relay Devices and Network Implementation" This chapter discusses the common physical network devices, interfaces, and cabling used in a Frame Relay network.

Chapter 3, "Planning and Managing Frame Relay Networks" This chapter describes the common issues involved during Frame Relay network planning and management and offers suggestions on the best approaches.

Chapter 4, "Cisco Frame Relay Configuration" This chapter shows readers how to configure basic Frame Relay commands on Cisco devices.

Part II of the book looks at the Cisco Frame Relay Solutions for implementing traffic policing and shaping. Frame Relay Traffic Policing and Shaping features allow the Frame Relay users to handle the oversubscription issues commonly encountered on Frame Relay networks. Part II covers the following chapters:

Chapter 5, "Frame Relay Traffic Shaping" This chapter describes the Frame Relay Traffic Shaping feature and how it can be used to perform rate enforcement of oversubscribing traffic.

Chapter 6, "Cisco Frame Relay Switching Enhancements" This chapter discusses the Frame Relay Switching feature which allows a traditional Cisco router to be set up as a dedicated Frame Relay switch with full switching capabilities.

Chapter 7, "Cisco Frame Relay End-to-End Keepalive" This chapter covers the Cisco Frame Relay End-to-End Keepalive feature for managing the true end-to-end status of a Frame Relay Virtual Circuit.

Part III of this book covers the Cisco Frame Relay Solutions for Traffic Management. The chapters presented in Part III describe a host of Cisco Frame Relay features for diverse usages. Part III covers the following chapters:

Chapter 8, "Frame Relay to ATM Interworking" This chapter explains the Frame Relay to ATM Interworking feature involving FRF.5 and FRF.8. The Frame Relay to ATM Interworking feature allows disparate ATM and Frame Relay protocol to interoperate with each other.

Chapter 9, "Adaptive Frame Relay Traffic Shaping for Interface Congestion" This chapter discusses the Adaptive Frame Relay Traffic Shaping for Interface Congestion feature. During sustained periods of congestion, this feature allows a Frame Relay router to efficiently perform packet dropping at the Virtual Circuit level rather than at the interface level.

Chapter 10, "Point-to-Point Protocol (PPP) over Frame Relay" This chapter explains the PPP and discusses how PPP can be transported over Frame Relay and its associated benefits.

Chapter 11, "Frame Relay Switched Virtual Circuit" This chapter explains how SVC operates and compares Frame Relay SVC with PVC.

Chapter 12, "X.25 over Frame Relay: Using the Annex G Feature" This chapter covers the X.25 over Frame Relay feature, commonly known as Annex G. Annex G provides means to help existing X.25 customers to migrate to the newer and faster Frame Relay technology.

Chapter 13, "Cisco Frame Relay Enhanced Local Management Interface (ELMI)" This chapter discusses the Cisco-implemented Frame Relay ELMI protocol and how Frame Relay ELMI allows Frame Relay customers to perform QoS autosense and Address Registration for network management.

Chapter 14, "Multilink Frame Relay (FRF.16) This chapter covers the Multilink Frame Relay feature, based on Frame Relay Forum's FRF.16. Multilink Frame Relay allows Frame Relay customers to aggregate individual parallel Frame Relay interfaces into a single bundle interface.

Chapter 15, "Compression over Frame Relay" This chapter explains the use of compression on Frame Relay networks and how compression can be used to attain higher throughput over a slow Frame Relay link.

Chapter 16, "Frame Relay Fragmentation" This chapter discusses the Cisco implementation of Frame Relay Fragmentation in the Cisco IOS Software. FRF.12, FRF.11 Annex C, and Cisco proprietary Fragmentation are discussed.

Part IV of the book covers the Cisco Frame Relay Solutions for Congestion Management. The chapters in Part IV describe the advanced Frame Relay queuing techniques and features for optimizing Frame Relay transport over slow bandwidth links. Part IV covers the following chapters:

Chapter 17, "Frame Relay Congestion Management" This chapter introduces readers to the advanced concepts in Frame Relay queuing and discusses the Cisco Frame Relay PIPQ feature in depth.

Chapter 18, "Frame Relay Class-Based Weighted Fair Queuing (CBWFQ) and Low Latency Queuing (LLQ)" This chapter covers two important advanced Frame Relay queuing techniques suitable for supporting integrated data and voice networks.

Chapter 19, "Frame Relay Queuing and Fragmentation at the Interface" This chapter discusses the Frame Relay Queuing and Fragmentation at the Interface feature, which provides a scalable method to allow Frame Relay users to implement LLQ and FRF.12 at the Frame Relay interface level.

Chapter 20, "Link Fragmentation and Interleaving (LFI) for Frame Relay Virtual Circuits" This chapter covers the implementation of the LFI feature for Frame Relay VCs and explains how LFI can be effectively used to maximize the transport of voice and data frames over a low-speed Frame Relay link.

Part V of the book covers the Cisco Frame Relay solutions for congetion avoidance and signaling. The Frame Relay features discussed are Weighted Random Early Detection (WRED) and Resource Reservation Protocol (RSVP). The chapters in Part V include the following:

Chapter 21, "Weighted Random Early Detection (WRED) for Frame Relay" This chapter covers the use of the WRED feature on Frame Relay network and explains how WRED can be used to manage congestion with TCP traffic.

Chapter 22, "Resource Reservation Protocol (RSVP) for Frame Relay" This chapter discusses the RSVP for Frame Relay feature, which provides a call admission control mechanism via signalling to allow a reserved bandwidth path to be set up for real-time delay-sensitive traffic.


Part I. Frame Relay Technology

Previous Page
Next Page

Part I: Frame Relay Technology

Chapter 1 Introduction to Frame Relay

Chapter 2 Cisco Frame Relay Devices and Network Implementation

Chapter 3 Planning and Managing Frame Relay Networks

Chapter 4 Cisco Frame Relay Configurations


Chapter 1. Introduction to Frame Relay

Frame Relay, a significant technical innovation developed in the 1980s that rapidly grew in the 1990s, has become an immensely popular WAN protocol today. Presently, public and private Frame Relay networks are deployed in almost every corner of the networked world. Almost every major service provider now offers Frame Relay as an efficient and cost-effective alternative to the traditional expensive leased-line circuits.

Frame Relay is an efficient and yet relatively simple protocol. Through the years, Cisco Systems and other vendors developed numerous features to complement Frame Relay. Many of these advancements are RFC standards and Frame Relay Implementation Agreements accredited by the Frame Relay Forum. The enhancements have made Frame Relay cost-effective, sophisticated, and high-performing. For these reasons, Frame Relay has become an immensely popular WAN protocol for both enterprises and service providers.

The topics and questions this chapter addresses include the following:

  • Definition of Frame Relay

  • Discussion of Frame Relay basics and usage

  • Comparison between the Frame Relay protocol and the X.25 protocol

  • Introduction to common Frame Relay terminology

After completing this chapter, readers will be able to appreciate the basic functions and operation of the Frame Relay technology. Readers will understand the benefits Frame Relay offers over its predecessor WAN technology, X.25. In addition, readers will be acquainted with the common abbreviations and terms used in the Frame Relay technology.


Frame Relay Defined

Frame Relay is a packet-switched technology. It is a high-speed WAN protocol designed primarily for interconnecting geographically dispersed LANs or WANs through a shared network. Frame Relay uses statistical multiplexing, which allows multiple users to access a Frame Relay virtual circuit and port from a single location. Compared with time-division multiplexing (TDM) systems, Frame Relay allocates bandwidth efficiently based on user demand. This reduces the waste incurred in TDM systems where bandwidth in allocated time slots is unused. In addition, Frame Relay saves costs by allowing many devices to share a common network infrastructure and because new virtual circuits take a shorter time to provision.

Levels of Operation

Frame Relay operates at the data-link layer of the OSI model and can be used to transport a variety of routed protocols. Routed protocol data packets are encapsulated within Frame Relay packets generally referred to as frames. Figure 1-1 shows how Frame Relay relates to the familiar OSI model at the data-link layer.

Figure 1-1. The OSI Model Relative to Frame Relay Encapsulation

When Frame Relay is used to transport IP, the IP packets are encapsulated in frames before they are sent into the Frame Relay network. Inside the Frame Relay network, the frames are switched from the source to the destination through a series of virtual circuits in the WAN. At each node, the switching decisions made for each frame traversed are based on a form of addressing scheme inside each Frame Relay header. When the frames eventually reach their destination, the Frame Relay headers are stripped off and the IP payload is passed on to the upper layers for processing. When end users overwhelm the network with traffic and result in congestion in the Frame Relay network, some frames can be dropped, but Frame Relay does not make any effort to retransmit the lost frames. Frame Relay uses a cyclic redundancy check (CRC) in the headers to detect corrupted frames. These corrupted frames are discarded, and Frame Relay does not request any retransmission or notify the upper layers of the errors. The error correction functions are performed by upper-layer protocols such as TCP, which is designed with the appropriate intelligence to detect packet loss and to request retransmission using flow and error control.

Figure 1-2 shows an example of a Frame Relay network with multiple nodes in the WAN.

Figure 1-2. Example of a Simple Frame Relay Network

Using this simple approach, Frame Relay has very few processing overhead compared with a protocol such as X.25. With this simple elegance, Frame Relay transfers data very quickly at a high throughput. To maximize its effectiveness, Frame Relay depends on the availability of clean and reliable transmission links, because it does not have a built-in flow and error control mechanism to recover from physical layer errors. Frame Relay relies entirely on intelligent upper-layer protocols such as TCP to retransmit lost frames and recover from errors. Using Frame Relay on unreliable transmission links with a high error rate can lead to disastrous results, because retransmission has to be processed at the upper layers. Fortunately, with the widespread of digital transmission facilities, the error correction capabilities in X.25 are no longer necessary in Frame Relay.


Frame Relay Virtual Circuits

Frame Relay relays or forwards frames from the source to the destination through a Frame Relay network on virtual path connections. These virtual paths can be either permanent virtual circuits (PVCs) or switched virtual circuits (SVCs). A PVC, as its name implies, is a permanent virtual connection. It is usually set up by the carriers when they program their Frame Relay switches. Depending on agreements with the carriers, a customer's or a user's PVC is usually configured to carry traffic up to a certain rate, called the committed information rate (CIR). The CIR is the rate at which a Frame Relay network or the carrier agrees to transfer information under normal conditions, averaged over a minimum increment of time. CIR is measured in bits per second.

Each PVC connection at the user's end is identified with a 10-bit address in the Frame Relay header known as the data link connection identifier (DLCI). The DLCI is usually mapped to a network layer destination or a subnet address. Then the data that needs to be transported over the Frame Relay network to its remote destination is encapsulated with a Frame Relay header. Each Frame Relay header is inserted with the DLCI value mapped to the remote destination's corresponding network layer address. The frames are sent into the Frame Relay network based on the initial DLCI value. The frames are then forwarded to their destination by the carriers' switches through the Frame Relay network. Along the way, the frames can be switched onto other PVCs on the way to their destination. The Frame Relay switches can change the DLCI values as the frames are switched from one PVC to another. As such, the DLCI value of the frames that arrive at the remote destination might not necessarily be the same as when the frames entered the Frame Relay network. Hence, the value of DLCI is of local significance only. In Figure 1-3, you can observe that DLCI 200 is used for a PVC on both ends of the connection. However, on the local end or port, a DLCI value cannot be used to reference more than one PVC connection to the Frame Relay network.

Figure 1-3. The DLCI Has Only Local Significance

An SVC is a temporary virtual path connection that is set up only when the end user needs to send data. An SVC involves the procedure of call setup and call disconnect. After an SVC is set up, it is active only for the duration of the data transfer. When no data is available or the connection is idle, either end user can tear down the SVC. When the traffic pattern is inconsistent, SVC represents added flexibility for Frame Relay users.


The Frame Relay Header

The standard Frame Relay header consists of two octets. Figure 1-4 illustrates the standard Frame Relay header.

Figure 1-4. Standard Frame Relay Header

The DLCI is a 10-bit address in the Frame Relay header, whose possible value ranges from 0 to 1023. The DLCI makes up the largest portion of the Frame Relay header and it occupies six bits in the first octet and another four bits in the second octet of the header. The DLCI is a locally significant field and it is used to reference a logical virtual circuit in the Frame Relay network which carries data to a particular destination.

Explicit Congestion Notification Bits

The forward explicit congestion notification (FECN) and the backward explicit congestion notification (BECN) bits in the second octet are used for congestion management in a Frame Relay network. When the Frame Relay network becomes congested, the carrier's Frame Relay switches can be programmed to set these bits to indicate congestion. The receiver of the frames observes the FECN bit set in the Frame Relay header. Depending on the application and its capability to participate in congestion management, the upper layers can be aware of congestion in the Frame Relay network and can take appropriate action to throttle down traffic sent into the network. Similarly, the Frame Relay switches can set the BECN bit for frames traveling in the reverse direction to notify the sender of a congestion condition. The sender can step down the rate of data being sent into the Frame Relay network until the BECN bit is no longer observed in the frame headers that it receives. Figure 1-5 illustrates this concept.

Figure 1-5. Example of FECN and BECN Bits Used in a Congested Frame Relay Network

Discard Eligibility Bit

The Discard Eligibility (DE) bit in the Frame Relay header is also part of congestion management. It is set by the Frame Relay switches when the current traffic rate on a PVC has exceeded its allowed CIR rate. When the customer or user sends data at a rate higher than its allowed CIR, the carriers' Frame Relay switches set the DE bit in the headers to indicate these frames are eligible for discard. As shown in Figure 1-5, when the Frame Relay switches on a congested network can no longer cope with the heavy traffic, they drop all frames marked with the DE bit set first. Frame Relay depends on upper-layer protocols at the remote ends, such as TCP, to detect lost frames and perform error recovery.


The Standardization of Frame Relay

The move to standardizing Frame Relay started with initial proposals submitted in 1984 to the International Telecommunication Union Telecommunication Standardization Sector (ITU-T), formerly the Consultative Committee for International Telegraph and Telephone (CCITT), ( http://www.itu.ch). However, things did not move quickly until 1990, when a consortium formed by the "Gang of Four"Cisco Systems, Digital Equipment Corporation (DEC), Northern Telecom, and StrataComdeveloped an extension to the Frame Relay protocol with enhancement features. These enhancements, known as the Local Management Interface (LMI), provide additional capabilities for Frame Relay in a complex internetworking environment. The LMI enhancement features are as follows:

  • Global addressing This gives Frame Relay DLCI global instead of local significance.

  • Multicasting This allows a single frame to be delivered to multiple receivers in the Frame Relay network.

  • Virtual Circuit Status Messages These provide keepalives and status communication mechanisms to allow Frame Relay devices to detect new PVCs or to periodically report the status of its connections.

LMI

The LMI is a standardized suite of protocols that Frame Relay uses to exchange messages and information on the state of a connection. Using the LMI signaling mechanism, both ends of a Frame Relay connection can communicate with each other to determine the status of the PVC, the DLCI value defined for the connection, and whether the interface is active. More recently, functionalities such as congestion management, PVC auto-discovery, multicasting, and address resolution have been added.

LMI exchanges status information on reserved DLCI values 0 and 1023 using special management frames. Three different LMI types are supported on Cisco devices. The Cisco LMI type uses DLCI 1023, whereas both ANSI and ITU LMI types are communicated to DLCI 0. Figure 1-6 illustrates the LMI frame format.

Figure 1-6. The LMI Frame Format

[View full size image]

The following listing describes all sections of Figure 1-6:

  • Flags Delimits the start and end of the LMI frame

  • LMI DLCI Differentiates the frame as an LMI frame instead of a normal Frame Relay frame

  • Unnumbered Information Indicator Sets the poll/final bit to zero

  • Protocol Discriminator Contains a value indicating that this is an LMI frame

  • Call Reference Always contains zero; not used for any purpose

  • Message Type Labels the frame as follows:

    - Status-inquiry message Allows a user device to inquire about the status of network

    - Status message Responds to status-inquiry messages; includes keepalives and PVC status messages

  • Information Element (IE) contains a variable number of individual information elements; consist of the following:

    - IE Identifier Uniquely identifies the IE

    - IE Length Indicates the length of the IE

    - Data Consists of one or more bytes containing encapsulated upper-layer data

  • Frame Check Sequence (FCS) Ensures the integrity of the transmitted frame


The Origins of Frame Relay: X.25

Frame Relay has its roots in the X.25 protocol, a robust packet-switched WAN protocol widely deployed in the early 1970s to connect geographically dispersed LANs and WANs. The X.25 protocol works well on noisy transmission mediums, which observe a high rate of errors and packet drops. X.25's windowing, flow, and error control features enable the retransmission and recovery of packets lost because of errors or congestion. As such, the upper layers are relieved of their role of performing error detection and correction. X.25 was very important in the early 1970s because the world, for the most part, was using unreliable public data network circuits for data transfer. X.25 still provides much needed reliability for data transmission over these unreliable and erroneous links.

Figure 1-7 illustrates a simple X.25 network. A basic X.25 network comprises the data terminal equipment (DTE), the data circuit-terminating equipment (DCE), and the X.25 switch. Examples of DTE devices include terminals, file servers, and computers. DCE devices are modems or routers with internal modem interfaces. The DCE connects to a X.25 network to communicate between the DTE devices and the X.25 switches. In Figure 1-7, a router (DTE) is connected to an external modem (DCE), which in turn communicates with an X.25 switch.

Figure 1-7. An Example of a Simple X.25 WAN

Unlike Frame Relay, which is entirely a data-link layer protocol, X.25 works at the first three layers of the OSI model. The Packet Layer Protocol (PLP) is the network layer protocol of the X.25 protocol suite. X.25 involves session establishment, data transfer, and session termination. During data transfer, X.25 performs flow control with windowing and also detects transmission errors and the loss of packets. X.25 ensures that the lost packets are correctly retransmitted by the end stations.

Compared with the Frame Relay protocol, the X.25 protocol involves a larger amount of overheads. Because the quality of digital transmission facility has improved dramatically over the years, there are fewer issues with transmission errors and packet drops. Furthermore, with the advent of TCP/IP and its overwhelming popularity, the robust flow and error control features in X.25 are now generating excessive overheads and are becoming increasingly unnecessary on modern networks. X.25 is considered slow by today's standards.


Frame Relay's Current Role

The world saw tremendous growth of the Internet in the 1990s. As a result, the demand for higher transmission speed and more bandwidth has soared. Today's fast and powerful computer processors run bandwidth-hungry applications that communicate, process, and transfer huge quantities of information, which include data, voice, and video. The older protocols are slow and do not scale well to suit this new trend of traffic. Frame Relay was developed to solve this problem.

Before Frame Relay, companies used mainly expensive leased circuits to connect their remote offices. In the past, if a company wished to connect two remote offices to its central site and provide connectivity between all three sites, it would need to order and install three physical leased-line circuits from its provider. A fully meshed network between all three sites would have to be built, and each location had to maintain two separate physical leased-line connections to its remote sites. When using traditional leased-line circuits in an organization with nnumber of sites, the number of physical point-to-point connections required for a fully meshed network is in the order of n(n1)/2. Figure 1-8 considers an example of this scenario.

Figure 1-8. A Fully Meshed Network with Leased-Line Circuits

In the small organization in Figure 1-8, the end users at Remote Site A need to access the file server located at Remote Site B daily, but only during a certain period of the day. During the busiest time of the day, the average size of the files transferred to and from the file server at Site B is only between 512 KB and 1 MB. At that time, the traffic between the central office and the users at remote sites consists mostly of e-mail and frequent database access and queries. In this scenario, the bandwidth of the dedicated connections between all three sites is mostly unused during part of the day, or the lines are underutilized. A Frame Relay solution is more suited for this topological requirement, the type of traffic, and the traffic pattern.

Figure 1-9 illustrates the alternative solution using Frame Relay with a star topology. All three sites are now connected to a shared Frame Relay network. Instead of building dedicated and expensive physical leased-line circuits, the organization can lease logical PVCs from the Frame Relay provider to connect all three locations. Using Frame Relay, each location has to maintain only a Frame Relay access device and a single physical access line connected to the Frame Relay network (the single physical access line can be a T1 or an E1 circuit). Logical PVCs are provisioned between all three sites, and each site has a direct logical connection to every other location. Furthermore, depending on each location's traffic usage, the minimum required bandwidth for each logical PVC can be subscribed. The CIR can be increased later in small increments if business needs arise.

Figure 1-9. A Scalable Solution Using Frame Relay

In another example, a company with 10 remote sites would require a total of 45 physical leased-line connections to provide a fully meshed network. On the other hand, the same fully meshed requirement can be met by deploying a Frame Relay network with 45 logical PVC connections over 10 physical access lines.

Dedicated leased-line circuits between remote sites are not only expensive to build and maintain but also take a longer period of time to order and implement. For example, if a sudden business need to connect two remote sites arises, building new leased lines can become a roadblock. However, if the two remote sites are already connected to an existing Frame Relay network, logical PVCs can be provisioned between them rapidly and easily. In this way, Frame Relay is much more flexible to meet a customer's requirements compared with the traditional leased-line circuits.

The Frame Relay Forum

The Frame Relay Forum ( http://www.frforum.com) is the main moving force behind the development of the Frame Relay technology and convergence of the Frame Relay standards. It is a worldwide association of Frame Relay vendors, carriers, manufacturers, and users.

NOTE

In April 2003, the Frame Relay Forum has merged with the MPLS Forum to become the MPLS and Frame Relay Alliance ( http://www.mplsforum.org).

Frame Relay Implementation Agreements are formally approved standards on how Frame Relay should be implemented to ensure operability and maximum cooperation between the manufacturers and vendors.


The Future of Frame Relay

The phenomenal success of the Internet has made users' demand for more bandwidth ever increasing. Today's data networks support a variety of traffic with different characteristics and requirements for bandwidth. Among these are voice and video. Voice over IP and video on demand are now common applications on the Internet. Voice and video traffic are highly susceptible to latency and jitters. Applications that are more tolerant to time delay, such as FTP and e-mail, are still commonly used. Organizations face the challenge of obtaining more bandwidth to suit their business needs while preventing operating costs from rocketing sky high. Companies have to perform some form of queuing and prioritization of their traffic so that one category of traffic does not overwhelm the network and starve the others of necessary bandwidth.

Cisco has contributed toward the advancement of Frame Relay by enabling routers to perform intelligent congestion control and management of traffic. In the same vein, fragmentation, compression, and quality of service features are other major enhancements to Frame Relay.


Frame Relay Terminology

Table 1-1 summarizes the common Frame Relay terminology you will continue to see throughout this book.

Table 1-1. Common Frame Relay Terminology

Term

Definition

Description

CIR

Committed Information Rate

Rate in bps at which the network commits to transfer user data under normal conditions, averaged over a minimum time interval, Tc.

EIR

Excess Information Rate

The maximum rate in bps in excess of the insured CIR at which the network attempts to transfer user data under normal conditions, averaged over a minimum time interval, Tc.

Bc

Committed Burst

The maximum amount of data in bits that the network commits to transfer, under normal conditions, during a Tc interval.

Be

Excess Burst

The maximum amount of data in bits in excess of the Bc that the network attempts to transfer, under normal conditions, during a Tc interval.

Tc

Committed Rate Measurement Interval

Tc is computed as Tc = Bc/CIR.

DLCI

Data Link Connection Identifier

A unique 10-bit number assigned to a PVC end point in a Frame Relay network to identify a PVC connection.

LMI

Local Management Interface

A suite of maintenance protocols for Frame Relay.

PVC

Permanent Virtual Circuit

A logical connection that is permanently established.

SVC

Switched Virtual Circuit

A logical connection that is established only on demand.

VC

Virtual Circuit

A logical connection established between two end points in a network.

DCE

Data Circuit-Terminating Equipment

DCE devices provide a clocking signal used to synchronize data transmission between DCE and DTE devices.

DTE

Data Terminal Equipment

DTE devices use clocking provided by DCE devices.


Summary

This chapter presented an overview of Frame Relay technology. Frame Relay is a popular Layer 2 packet-switched protocol designed to carry user traffic efficiently on high-speed digital circuits. Compared with Frame Relay, the legacy X.25 protocol has higher overheads and many drawbacks. Many vendors are developing new features to add to the benefits of Frame Relay.

This chapter showed that the standard Frame Relay header is uncomplicated, although essential functionalities, such as addressing, congestion control, and notification, as well as FCS, are supported.

This chapter discussed how the standardization of Frame Relay by major industry players resulted in the development of the LMI management features. The LMI features help to simplify the management of Frame Relay virtual circuit connections.

The cost-effectiveness of Frame Relay was also illustrated in this chapter. The benefits of building a fully meshed network with logical Frame Relay PVCs, versus the traditional leased-line circuits, were highlighted.

This chapter introduced the Frame Relay Forum, a worldwide association of Frame Relay vendors, carriers, manufacturers, and users. New Frame Relay implementations agreements and standards are developed by the Frame Relay Forum to ensure maximum operability and cooperation between vendors. The last part of the chapter defined and explained the most commonly used Frame Relay terminologies. The next chapter presents an overview of the Cisco implementation of Frame Relay and Cisco Frame Relay devices.


Review Questions

1: | What is Frame Relay?
2: | What is a virtual circuit?
3: | What are the differences between a PVC and an SVC?
4: | What is the CIR?


Reference

The Frame Relay Forum: http://www.frforum.com


Chapter 2. Cisco Frame Relay Devices and Network Implementation

Network designers and implementers often find themselves with the compelling task of selecting the most appropriate network devices for WAN connectivity. The selection criteria usually involve a number of factors, such as bandwidth requirements, equipment cost, and scalability options. The first section of this chapter will consider the typical networking devices, serial interfaces, and the common cabling standards used in a general Frame Relay network. Then the chapter will take a look at Cisco's wide range of router product lines and wide-area switches that offer a complete end-to-end solution to customers. Later in the chapter, Cisco's implementation of the Frame Relay technology will be discussed.

The topics and questions that this chapter addresses include the following:

  • Physical network devices used in a Frame Relay network and the definition of DTE and DCE devices

  • Cisco serial interfaces for supporting a Frame Relay network and the most popular industry serial cabling standards

  • The most popular Cisco router platforms used in Frame Relay environments

  • Introduction to Cisco's implementation of Frame Relay, which includes the LMIs and Frame Relay encapsulations supported

  • Introduction to static and dynamic Inverse ARP DLCI to network address mapping

After completing this chapter, readers will be able to recognize the common devices, interfaces, and cabling used in a Frame Relay network. You will also be able to identify the most suitable Cisco router product or wide-area switches for a Frame Relay network. Finally, you will have a basic understanding of Cisco's implementation of Frame Relay.


Understanding Frame Relay Devices and Network Implementation

In general, the physical network devices in a Frame Relay network belong to two broad categories:

  • Data terminal equipment (DTE)

  • Data circuit-terminating equipment (DCE)

A DTE device is typically the end device of a network. It is usually classified as customer premises equipment (CPE) if it is physically located at the customer's site. A router can be owned by a customer or leased directly from the Frame Relay network carrier. It can be defined as CPE, which functions as a DTE device. Other examples of DTE devices include terminals, computers, or servers.

A DCE device supplies clocking signals and provides synchronization functions to a connected DTE device. Some DCE devices provide switching functions and services to transmit frames through a Frame Relay network. A Frame Relay switch is an example of such a DCE device. A Cisco router can be configured as a Frame Relay switch. Table 2-1 categorizes the general DTE and DCE devices.

Table 2-1. Examples of DTE and DCE Devices

DTE Devices

DCE Devices

Personal computers

CSU/DSU

Routers (can also be DCEs)

Hub

Servers

Modem

Terminals

Multiplexors

Switches

Figure 2-1 illustrates the relationship between DTE and DCE devices in a Frame Relay network.

Figure 2-1. DTE and DCE Relationship in a Frame Relay Network

A channel services unit/data services unit (CSU/DSU) is a DCE device often found in a Frame Relay network. In the United States and many other countries, a CSU/DSU device provides an interface to the telephone company or to the carrier offering Frame Relay services. A CSU/DSU device provides clocking and synchronization functions to a connected Cisco router. In this arrangement, the CSU/DSU is the DCE device and the Cisco router acts as the DTE device. Typically, the Cisco router is connected to the CSU/DSU device on a synchronous serial interface, and in turn, the CSU/DSU is directly attached to a Frame Relay switch in the carrier's network. The Frame Relay access link between the CSU/DSU and the Frame Relay switch can be a 64 kbps leased line or a T1 circuit connected on coaxial cables. It can also use any other industry standard; it is largely dependent on the carrier's implementation.

Note that in Figure 2-1, the Cisco router is connected directly to the Frame Relay switch without connecting to an external CSU/DSU device. This is possible because Cisco offers cost-effective WAN interface cards with an integrated CSU/DSU. Such integrated interface cards provide internal clocking and signaling so the router does not need an external CSU/DSU. Figures 2-2 and 2-3 illustrate a common example whereby a Cisco router is connected to an external CSU/DSU on a synchronous serial interface. The CSU/DSU then connects directly to the Frame Relay switch in the carrier's network on a T1 link.

Figure 2-2. Frame Relay Connection with a CSU/DSU

Figure 2-3. Connecting a Serial Interface to a CSU/DSU

NOTE

You can identify whether a Cisco router is acting as a DTE or a DCE device to a connected network by examining the serial cable attached to its synchronous serial interface or by the show controllers serialcommand. If a DTE male serial cable is connected to an interface, the Cisco router acts as a DTE device to the network connected on that serial interface. Likewise, if a DCE female serial cable is connected to a serial interface, the interface acts as DCE device that supplies clocking signals to a connected DTE. An interesting point to note is that a Cisco router can act as a DCE on its DTE interface connected to a Frame Relay network by enabling frame-relay switchingglobally and configuring frame-relay intf-type dceon the interface.


Frame Relay Serial Interfaces and Cabling Standards

A synchronous serial interface is usually used to connect a Cisco router to a Frame Relay network. Cisco routers support a wide range of synchronous serial interface cards that conform to present industry communication standards. Refer to the Cisco's product guide for an up-to-date and complete range of supported serial synchronous interfaces.

On a Frame Relay network, the most commonly used industry communication standards are provided by the Electronic Industries Alliance (EIA) (http://www.eia.org) and the Telecommunications Industry Association (TIA) (http://www.tiaonline.org). Today, the EIA is a national trade organization that comprises more than 80% of the electronics industry and includes major U.S. manufacturers. The TIA represents the communication sector of the EIA. Last but not least, the International Telecommunication Union (ITU-T) (http://www.itu.int/ITU-T/) is responsible for the development of the popular X.21 and V.35 industry communication standards. The ITU-T is an international organization where governments and private sectors coordinate global telecommunication networks and services. The full titles of the mentioned popular industry communication standards currently used in most Frame Relay environments are provided in the following list:

  • TIA/EIA232 Interface between Data Terminal Equipment (DTE) and Data Circuit-terminating Equipment (DCE) employing serial binary data interchange.

  • TIA/EIA 449 37-Position and 9-Position interface for DTE and DCE.

  • TIA530 High Speed 25-Position interface for DTE and DCE, including Alternative 26-Position Connector.

  • ITU-T V.35 Data transmission at 48 kbits/s using 60-108 Khz group band circuits.

  • ITU-T X.21 Interface between DTE and DCE for synchronous operation on public data networks.

NOTE

To obtain the commercial versions of the industry communication standards discussed in this section, readers can go to the TIA public website at: http://www.tiaonline.org/standards/search_n_order.cfm. Similarly, the ITU-T standards can be obtained from ITU-T public website at: http://www.itu.int/publications/main_publ/itut.html.

TIA/EIA-232

TIA/EIA-232 was formerly known as RS-232. TIA/EIA-232 uses 25 pins on the interface. It is a common physical layer interface standard developed by EIA and TIA that supports unbalanced circuits at signal speeds of up to 64 kbps. Figure 2-4 illustrates the TIA/EIA-232 cable assembly.

Figure 2-4. TIA/EIA-232 Cabling Standards

TIA/EIA-449

TIA/EIA-449 was formerly known as RS-449. TIA/EIA-449 uses 37 pins on the interface. It is another popular physical layer interface standard developed by EIA and TIA that supports faster signal speeds of up to 2 Mbps and also longer cable runs. Figure 2-5 shows the TIA/EIA-449 cable assembly.

Figure 2-5. TIA/EIA-449 Cabling Standards

TIA-530

The TIA-530 standards support balanced circuits at higher speed and greater distance compared with the TIA/EIA-440 standards. TIA-530 has 25 pins on the interface and uses a DB-25 connector, both similar to TIA/EIA-232. TIA-530 supports a maximum transmission speed of 2 Mbps, and a faster speed at 4 Mbps can be achieved over shorter distances. Figure 2-6 shows the cable assembly of TIA-530.

Figure 2-6. TIA-530 Cabling Standards

NOTE

In a balanced circuit, all connectors have the same impedance with respect to ground.

ITU-T V.35

V.35 is an ITU-T standard describing a synchronous physical layer protocol used for communications between a network access device and a packet network. V.35 uses 34 pins on the interface and is most commonly used in the United States and in Europe. V.35 is recommended for speeds up to 48 kbps. Figure 2-7 shows the ITU-T V.35 cable assembly.

Figure 2-7. V.35 Cabling Standards

ITU-T X.21

X.21 uses 15 pins on the interface. It is an ITU-T standard for serial communications over synchronous digital lines commonly used in Europe and Japan. Figure 2-8 illustrates the ITU-T X.21 cable assembly.

Figure 2-8. X.21 Cabling Standards

Previous Page
Next Page


The Cisco Family of Router and Switch Platforms for Frame Relay WAN Connectivity

In 1990, Cisco Systems released its first product to support Frame Relay technology. Presently, the feature-rich Cisco IOS software supports Frame Relay on almost every family of the router product line. Cisco has a very wide range of router products to meet different users' requirements. Each Cisco router family considered in Figure 2-9 has better performance, higher memory capacities, higher port densities, and faster interface speeds as you move up the chart. Each of these families is described in greater detail in the sections that follow.

Figure 2-9. Cisco Router Product Families

Cisco 1600/1700 and 2600 Series Routers

The Cisco 1600/1700 and 2600 series routers are modular platforms that support low-speed WAN Interface Cards and built-in 10/100 Ethernet connections for home and small office users. The 2500 series routers are fixed configuration routers, but some models do support WAN connectivity. It is not possible to add or change existing modules or interfaces on a 2500 series router. Presently, the very popular 2500 series has been largely replaced by the newer 2600 and 3700 series routers. Basically, the 1600/1700/2500/2600 series routers are for homes and small offices and can support a range of synchronous serial interfaces to provide connectivity to a Frame Relay network. In addition, the c1700 and c2600 series routers support voice interface cards (VIC) for voice applications.

Cisco 3600/3700/4000 and AS5000 Series Routers

The Cisco 3600/4000 and AS5000 series routers are modular routers that run on more powerful and faster Reduced Instruction Set Computer (RISC) processors. These platforms have greater memory capacity for higher performance than their home/small office counterparts. Similar to the c2500 series, the c4000 series router has reached its end-of-sales. The c3600 and AS5000 series support higher port densities; these platforms are ideal for branch office connectivity. The c3600 series also supports voice modules for voice applications.

The new Cisco 3700 series routers provide port density to branch offices in a compact form factor. The c3700 series offers high levels of application and service integration at a lower cost.

Cisco 7200/7500, 10000, and 12000 GSR Series Routers

The Cisco 7200/7500 series and 12000 GSR series routers are powerful, high-performance routers designed for central office connectivity. These platforms are commonly used when service providers need high port densities and fast interface processing speeds. The 10000 Series Internet routers offer aggregation services at the network edge and are designed for 99.999 percent high availability (HA). The 12000 GSR series Internet routers are the first in a product class of gigabit switch routers which offers high-speed OC-192 Packet over Sonet (POS) line cards at full 10 Gbps (Gigabits per second) line rate.

Cisco Wide-Area Switches

Cisco offers a range of carrier-class wide-area switches. These switches provide an end-to-end network solution that is tightly integrated with Cisco router and access products for enterprises and service provider customers. The Cisco BPX, IGX, and MGX series multiservice switches allow customers to deploy a scalable network to cost-effectively deliver Frame Relay, voice/video, or Asynchronous Transfer Mode (ATM) broadband services with end-to-end high quality of service. BPX, IGX, and MGX topics are covered extensively in the Cisco Press title: Cisco WAN Switching Professional Reference by Tracy Thorpe (ISBN: 1587050552, May 2002).


Frame Relay Access Speeds and CIR

The maximum possible transmission speed on an access link largely depends on the Frame Relay network carrier's implementation and the type of transmission facility it uses and supports. Cisco devices can support Frame Relay at DS-3 access speeds of 45 Mbps. In most countries, Frame Relay network carriers or service providers offer Frame Relay services with a base CIR to their customers. In the context of a typical small-scale organization, a Frame Relay connection service with a CIR of between 128 kbps to 1.544 Mbps (T1) can normally allow an organization to support a standard network traffic load for common applications such as Telnet, e-mail, FTP, and HTTP.

When oversubscription occurs, small increments of 4 kbps to 64 kbps can usually be added to the subscribed CIR. In this scenario, selecting a modular access router from the small office category to connect to the service provider is a reasonably good choice. Investing in a more powerful branch office router with a faster interface card can cater to future growth and expansion in the long run. In general, the router selection criterion for WAN connectivity is normally a scalable solution that can meet bandwidth requirements while keeping costs under control.


Introduction to the Cisco Frame Relay Implementation

Cisco's Frame Relay implementation supports the basic Frame Relay protocol and conforms with the local management interface (LMI) specifications originally developed by the consortium of Cisco Systems, StrataCom, Northern Telecom, and Digital Equipment Corporation (DEC). This consortium of the four companies is popularly known as the "Gang of Four." One of the main objectives of the collaboration by the Gang of Four was to enhance the interoperability of future Frame Relay products and cooperation among different vendors. The developed set of LMI enhancements helps to reduce the complexity of managing and supporting large internetworks.

One of the LMI enhancements Cisco supports is LMI status message exchange. LMI status message exchange allows a DTE device to communicate and synchronize with a DCE device in a Frame Relay network. The Cisco IOS supports three different LMI types: Cisco, ANSI Annex D, and Q.933-A Annex A. The Cisco LMI is defined jointly by Cisco and the Gang of Four. ANSI Annex D is defined by the ANSI TI.617 standards. ANSI Annex D is commonly used in many Frame Relay networks. Q.933-A Annex A is accredited by ITU-T. All three LMI types exchange status messages on globally reserved DLCIs. Both ANSI Annex D and Q.933-A Annex A LMI types use DLCI 0 for message exchange, whereas the Cisco LMI type listens to status messages on DLCI 1023. Both DLCI 0 and DLCI 1023 are globally reserved DLCIs and may not be reused for addressing other virtual circuits in a Frame Relay network.

In a Frame Relay network, LMI messages are exchanged between the Frame Relay switch and its connected DTE device, usually a router. Each of the supported LMI types has a different implementation and is thus incompatible with the others. For this reason, the LMI types configured on both ends of the Frame Relay access link between a DCE and a DTE device must be identical. Figure 2-10 further illustrates this concept. Table 2-2 shows the supported LMI type and the DLCI in use.

Figure 2-10. LMI Type Between Any DTE and DCE Pair Must Be Identical

Table 2-2. Cisco-Supported LMI Type and the DLCI in Use

Supported LMI Type

DLCI

Developing Organization

Cisco

1023

Gang of Four

ANSI Annex D

0

ANSI TI.617

Q933A Annex A

0

ITU-T (CCITT)

As of Cisco IOS Software Release 11.2, IOS supports the LMI Autosense feature. This feature allows the Cisco router to automatically detect the LMI type supported by the connected Frame Relay switch. When an LMI type is not explicitly configured on a Cisco router, LMI autosense is activated. When LMI autosense is running, the router sends out full status request messages for each of the supported LMI typesANSI, Q.933-A, and Cisco, in that orderon DLCI 0 or DLCI 1023. Eventually, the router receives a status reply message from the Frame Relay switch and detects the LMI type used by the switch. The router automatically configures itself to select the LMI type supported by the switch. When an LMI type is explicitly configured on the router, the LMI Autosense feature is overridden and the router uses the configured LMI type instead.

Global Addressing Versus Local Addressing

The LMI global addressing extension allows the Frame Relay DLCI to have a global significance rather than a local significance. The idea of global significance assigns an unique DLCI address to each Frame Relay DTE in the network, much the same way that IP addresses or MAC addresses are used to uniquely identify a device on the Internet or a LAN. To best describe the concept of global significance in a Frame Relay network, refer to the example in Figure 2-11.

Figure 2-11. Frame Relay Network with Local Addressing

In Figure 2-11, a hub-and-spoke topology connects four remote sites to a central office. Four PVCs are provisioned at the central office to allow it to connect to each of its remote sites. In this Frame Relay network, the four PVCs at the central office are statistically multiplexed onto a single physical access link connected to the Frame Relay switch. In this example, the central office router uses DLCI 2, 3, 4, and 5 to distinguish each PVC connection to its remote sites 2, 3, 4, and 5, respectively. Similarly, each remote site router uses the same DLCI on its end of the PVC to the central office. This DLCI addressing scheme works because Frame Relay allows local significance, and the same DLCI can be reused at both ends of a PVC. However, if more than one PVC exists at a local end, a different DLCI must be used to reference and distinguish between them. In this example, the router at site 2 uses DLCI 2 to send traffic to the central office router. Likewise, the central router uses the same DLCI 2 to send traffic back to the router at site 2, but it uses DLCI 3 to reach the users at site 3. Now consider Figure 2-12 where the same network is revisited, but this time using a global addressing scheme.

Figure 2-12. Frame Relay Network with Global Addressing

Using global addressing, each Frame Relay DTE is uniquely addressed in a Frame Relay network, the same way that an end station is addressed uniquely with its MAC address on a LAN. This allows all Frame Relay DTEs to send traffic to a remote destination using a globally unique DLCI value assigned to that destination. For example, all the remote sites now use DLCI 1 to reach the central office because the central office is identified with the globally unique DLCI 1. In other words, DLCI 1 leads to the central office. Similarly, the central router recognizes that DLCI 2 leads to remote site 2, DLCI 3 leads to remote site 3, and so on. Note that a DLCI address is not reused anywhere in the Frame Relay network, and each Frame Relay DTE has a uniquely defined DLCI address that distinguishes it from its peer DTEs.

Global addressing allows each Frame Relay DTE to be identified as an unique end station in the Frame Relay network. It is worth mentioning that there is a restriction to using global addressing in any Frame Relay network. For global addressing to work, the total number of Frame Relay DTEs in the network must not exceed the allowed range of DLCI values in the header. In order to apply the global addressing scheme, each Frame Relay DTE in the network has to be assigned a unique DLCI address. This leads to the question of how many DLCIs carrying users' data can be assigned in a Frame Relay network. The DLCI is a 10-bit address, which gives us about 1024 DLCIs. However, there are some DLCIs that are reserved for sending LMI messages and multicasting. As such, when using Cisco LMI, the range of allowed DLCIs for users' data is 16 to 1007. The ANSI Annex D and ITU Q.933-A support a range from 16 to 992.

The other issue is with the number of DLCIs that can be configured on a physical interface in the Cisco router. The LMI protocol specifies that all PVC status reports have to fit into a packet. How many of these can be squeezed into a packet depends on the maximum transmission unit (MTU) of the physical interface. The formula for calculating the maximum number of DLCI per physical interface is (MTU 20)/5, where MTU is in bytes. The default MTU size of an interface on a Cisco router is 1500 bytes; the interface can have a maximum of 296 DLCIs.

Frame Relay Encapsulation

The standard Frame Relay header and trailer defined by Q.922-A do not have a facility to allow multiprotocol to be transported over Frame Relay. All protocols are encapsulated inside the basic Frame Relay frame, but there is no field in the basic header that allows Frame Relay DTEs to identify the protocol carried within and correctly process the packet.

There are two solutions to this problem: Cisco proprietary encapsulation and RFC 1490. Cisco supports both implementations. Both solutions allow multiprotocol to be transported over Frame Relay. In both methods, an additional Protocol Type or Protocol ID field is inserted inside the frame behind the basic Q.922-A headers to identify the transported protocol.

Consider Figure 2-13 for the Cisco and RFC 1490 encapsulated frames.

Figure 2-13. Cisco and RFC 1940 Encapsulations

The first solution, using Cisco encapsulation developed by Cisco and three other vendors, defines an additional header inside the basic Q.922-A Frame Relay headers. The additional header has a 2-byte Protocol Type ID field to identify the protocol carried inside the frame. The Cisco encapsulation is the default encapsulation on all Cisco routers.

The second encapsulation option supported is defined in RFC 1490 "Multiprotocol over Frame Relay," which includes routed and bridged frame options. RFC 1490 can be found at http://www.faqs.org/rfcs/rfc1490.html. An NLPID field in the Frame Relay header identifies the different network layer protocol carried inside the Frame Relay frame. For example, a NLPID field with a value of 0xCC indicates an IP packet carried by the Frame Relay frame. A NLPID field with a value of 0x00 means an invalid packet is in the Frame Relay frame.

The Frame Relay encapsulation type used by the peer Frame Relay DTE devices at both ends of a Frame Relay virtual circuit must be identical. This is because Frame Relay frames travel end-to-end over the Frame Relay virtual circuit from the near-end Frame Relay DTE device to the far-end Frame Relay DTE device. A Frame Relay router is an example of a Frame Relay DTE device. The Cisco Frame Relay encapsulation is the default Frame Relay encaspsulation used on an interface and Cisco Frame Relay encapsulation is normally used in an all-Cisco environment. In a mixed environment which supports non-Cisco vendors' equipment, the IETF Frame Relay encapsulation can be used to provide interoperability between the non-Cisco Frame Relay DTE device and the Cisco Frame Relay DTE device. Figure 2-14 reinforces this concept.

Figure 2-14. Encapsulation Must Be Identical End-to-End

The Frame Relay LMI type, unlike Frame Relay encapsulation, has to be identical between a Frame Relay DTE device and its directly connected Frame Relay DCE device, which is commonly a Frame Relay switch. The Frame Relay switch does not bother itself with the Frame Relay encapsulation method carried in the frames forwarded by its connected Frame Relay DTE routers. The Frame Relay switch must be able to communicate with the connected Frame Relay DTE router using a compatible LMI type understood by both DTE and DCE devices.

Frame Relay Multicasting

The Frame Relay LMI extensions support the multicasting feature. In a Frame Relay network, the multicast groups are designated by a series of four reserved DLCI values (1019 to 1022). When a Frame Relay DTE sends data on one of these reserved DLCIs, the frames are replicated by the Frame Relay switches supporting multicasting and are subsequently sent to all exit points in the designated set. The receivers of the multicast frames have to be configured to listen on these DLCIs.

The multicasting LMI extension defines additional LMI messages for notifying user devices of the addition, presence, and deletion of new or existing multicast groups. In large networks that deploy dynamic routing protocols over Frame Relay, it is more efficient to exchange routing information between only the specific routers configured to run the dynamic routing protocols. The routing updates are sent using frames on the multicast DLCIs.

Frame Relay Inverse Address Resolution Protocol

The Cisco router supports the dynamic resolution of next hop protocol address to local DLCI mappings. Frame Relay Inverse Address Resolution Protocol (Inverse ARP) is enabled by default in the IOS for all protocols enabled on the physical interface.

Frame Relay Inverse ARP requires LMI capability to construct an address-to-DLCI mapping table on the router. Inverse ARP does not work when LMI is disabled.

The Cisco IOS also supports the use of static address mapping. Static mapping is used when the remote router does not support Inverse ARP. When static address mapping is used, dynamic Inverse ARP is automatically disabled.


Summary

This chapter introduced the physical network devices commonly found and used in a Frame Relay network. A DTE is an end user device in a network that connects to a DCE device. A router is an example of a DTE device. In contrast, a DCE is a network device that provides clocking signals to a connected DTE device. CSU/DSU is an example of a DCE device.

Also discussed in this chapter were serial interfaces and the commonly used industry cabling standards. The chapter illustrated the most popular Cisco router platforms. Then it discussed Cisco's implementations of Frame Relay, including the LMI implementations and Frame Relay encapsulation types supported on Cisco devices. Finally, the basics of Frame Relay address to IP address mapping using static or dynamic ARP methods were introduced. The next chapter will discuss the general considerations involved in planning and managing Frame Relay networks.


Review Questions

1: | What are the main differences between DTE and DCE devices in a Frame Relay network?
2: | List the most common industry cabling standards used for connecting serial interfaces to a Frame Relay network.
3: | What is global addressing?
4: | Name the Frame Relay encapsulations supported by the Cisco IOS.
5: | What are the main functionalities of Frame Relay multicasting and Inverse ARP?


Chapter 3. Planning and Managing Frame Relay Networks

During the implementation phase of an enterprise-owned private Frame Relay network or a carrier-provided public Frame Relay network, network planning is an important component of the framework in order to build a successful network. Proper network planning can reduce the probability of encountering problems later in the production phase, such as bandwidth oversubscription or network congestion. Well-planned networks have the ability to provide better quality of service to mission-critical applications. During network planning, multiple factors are involved that are of considerable concern to network designers. In general, a well-planned Frame Relay internetwork incorporates basic yet sound design elements that combine the best mixture of network performance, cost management and network scalability.

This chapter focuses on a discussion of issues involved during Frame Relay network design and planning. This chapter offers general guidelines and suggestions for formulating a good Frame Relay network design that balances performance, cost, and scalability. Then the chapter considers how broadcast traffic and congestion can affect overall network performance. Some available solutions that can be used as a backup to Frame Relay will also be examined. Another topic is how Cisco uses the concept of subinterfaces to overcome common issues, such as split horizon.

The topics and questions that this chapter addresses include the following:

  • Important considerations of network planning

  • The different levels of CIR subscription and how to effectively manage the tariffs

  • Common Frame Relay topologies and how to build an effective, manageable, and scalable network

  • Performance management and how to improve network performance

  • The impact of broadcast traffic on the network

  • Provisioning backup to the primary Frame Relay virtual circuit with parallel redundant virtual circuits or ISDN dial on demand routing (DDR)

  • The split horizon issue and how to overcome it by using subinterfaces on a Cisco router

After completing this chapter, readers will be able to understand the importance and benefits of effective network planning. Given a set of network requirements, readers will be able to create an effective network design and plan that balances performance, cost, and scalability.


Network Planning

Network planning is an important phase of any network implementation project because good network planning can ensure your network is able to transport your critical traffic reliably. Whether purchasing a Frame Relay service from a service provider or setting up a private enterprise Frame Relay network, a network planner has to consider many important factors. During the network planning stage, network designers or architects engage in activities to identify and gather requirements from their main users. General factors such as user bandwidth requirements, the type of traffic carried by your network, and the traffic transmission pattern determine the kind of transmission link necessary for your organization.

Security is also an important factor to consider to protect your network against access or denial of service attacks. Security issues, however, will not be discussed in this book. The information presented in this section serves as a general guideline for Frame Relay network planning.

Knowledge of Users' Requirements

A good understanding of the users' bandwidth requirements is an important criterion for building a successful Frame Relay network. With knowledge of your users' network traffic, the minimum bandwidth requirements of each major application can be carefully planned and provisioned. When bandwidth capacity planning is executed properly, it can help to avoid problems later on, such as network congestion, network latency, and jitters. Well-planned bandwidth provisioning schemes allow networks to provide assurance to users that their traffic always receives an acceptable level of service.

To deliver a high quality of service to users, network designers usually need to possess sound knowledge of each major application in order to obtain a realistic estimation of the expected bandwidth consumption. Typically, mission-critical traffic is identified for higher priority handling by the network. As such, it is given special preference as opposed to less critical traffic. Common examples of mission-critical traffic include Enterprise Resource Planning (ERP), voice, and video. Figure 3-1 provides an example of possible types of applications within an organization.

Figure 3-1. Knowledge of Applications and Bandwidth Requirements

Knowledge of the Protocol Mix

Knowledge of the protocol mix on the network is important during network planning. Some applications and protocols generate a massive amount of overhead in the network. This has to be taken into careful consideration to ensure that traffic with excessive overhead does not take up all the available bandwidth. For instance, the Routing Information Protocol (RIP) generates periodic broadcasts by sending its entire routing table every 30 seconds to its neighbors. If RIP is configured to run over a Frame Relay network, the periodic broadcast traffic must be taken into consideration to ensure that other traffic has sufficient bandwidth available to it.

Figure 3-2 shows an example of a possible protocol mix making up the different traffic types on a network.

Figure 3-2. Possible Protocol Mix on a Network

A common protocol mix on a network includes the following:

  • HTTP

  • Multicast

  • Routing protocol updates

  • Interactive Telnet/SSH

  • FTP transfers

  • SMTP

  • Real-time voice and video

Knowledge of the Traffic Pattern

Understanding the traffic pattern on the network is another important factor that network planners should take into consideration. Today, modern data networks typically carry traffic that is "bursty" in nature. Applications such as FTP can generate a large volume of traffic on the network during data transfers. As such, sudden bursts of large data transfers can take up a substantial amount of the available bandwidth on the network. This can cause network latency for other applications. It can eventually result in delay and jitters for real-time applications such as voice conferencing software and video-on-demand applications. The nature of such real-time applications is to be extremely susceptible to latency and jitters. When congestion sets in for a long period of time, mission-critical traffic can be held up in the transmission queues by less-critical traffic. Ultimately, this causes real-time applications to time out and reduces the perceived quality of service of the network. Figure 3-3 illustrates how sudden bursts of a large volume of data packets can hold up real-time mission-critical traffic that is more susceptible to latency and jitters.

Figure 3-3. Real-Time Traffic Versus Bursty Data Traffic

To deal with this issue, Cisco IOS supports several traffic prioritization, fragmentation, and queuing mechanisms. These mechanisms can effectively improve the overall performance of a congested network without incurring additional cost by buying more bandwidth.

Provisioning BandwidthCapacity Planning

To provide an acceptable level of service for real-time traffic, such as voice and video, on the network, Cisco uses a 75 percent rule for network planning. The 75 percent rule assumes that the total bandwidth required for all applications should not exceed 75 percent of the actual bandwidth available on the link. To determine the total bandwidth requirements, the minimum bandwidth requirements of each major application is summed together. This sum represents an estimation of the aggregate traffic load on the actual network. Ideally, it should not exceed 75 percent of the bandwidth available on the link. The remaining 25 percent of the available bandwidth should be reserved for overhead traffic such as routing updates, session-level keepalives, and other application traffic that is not so easily measured and quantified.

Using this information, network planners can better determine the number of permanent virtual circuits (PVCs) or the level of committed information rate (CIR) subscription required to sustain the bandwidth requirements and provide an acceptable level of service to users. Consider Figure 3-4, which shows an example of the 75 percent rule during network planning.

Figure 3-4. Example of the 75 Percent Rule

Frame Relay Subscription

The following discussion on Frame Relay CIR subscription provides additional details for the following Frame Relay terms that were introduced in Chapter 1, "Introduction to Frame Relay."

The link access speed of the Frame Relay access link is the actual clock speed of the local loop to the Frame Relay network. The clock can be signaled by the CSU/DSU or by the connected Frame Relay switch. This is the maximum rate at which the Frame Relay device can send traffic into the Frame Relay network.

CIR

CIR is the rate, in bits per second, at which the carrier agrees to transfer information under normal conditions, averaged over an increment of time known as the Tc. The CIR is usually configured on the provider's Frame Relay switch, on a per-PVC basis. The CIR value typically ranges from 0 to the actual access speed of the Frame Relay access link. As we shall see, service providers can offer different options for CIR subscription.

CIR is calculated by the following formula:

CIR = Bc / Tc

Committed Burst (Bc)

The committed burst (Bc) is defined as the maximum number of bits that the Frame Relay network will transfer during a committed rate measurement interval (Tc).

As such, the Bc is also a multiple of CIR by the Tc interval. The higher the Bc-to-CIR ratio, the longer the Frame Relay network can handle a sustained burst of traffic on the PVC.

The relationship between Bc, CIR, and Tc is expressed by the following formula:

Bc = CIR x Tc

Excess Burst (Be)

The excess burst (Be) is defined as the maximum number of bits above the Bc that the Frame Relay network will attempt to transfer. The data transferred beyond the CIR is typically delivered with the "best effort" and is dropped when the Frame Relay network becomes heavily congested and can no longer handle the load. Note that the Be cannot go beyond the access rate on the Frame Relay link.


Planning the CIR Subscription

Several possible options are available during the planning of the CIR rate subscription. Each service provider offers slightly different services with varying SLAs. Typically, customers seek to balance between cost and performance when provisioning Frame Relay services for their organizations. Consideration must also be given to ensuring that sufficient bandwidth is made available to handle the traffic load on the network. As part of the SLA, some providers allow customers to burst beyond their level of subscription during normal load conditions. However, continual oversubscription of the Frame Relay service can lead to eventual network congestion, resulting in poor performance and adverse overall effects on the organization. Network planners have to consider the business's needs when provisioning bandwidth for an organization. It is usually a question of balancing between oversubscription and undersubscription. The most common subscription options offered by Frame Relay service providers are described in the following sections.

Zero CIR (0 CIR)

Many Frame Relay carriers and service providers provide a "0 CIR" service. Typically, this is the Frame Relay service with the most attractive pricing. With 0 CIR, the rate of frames sent into the service provider's Frame Relay network is always beyond the CIR range. All frames entering the Frame Relay network are above the Bc and are all susceptible to frame drops. The Frame Relay service provider adopts a best effort delivery for all users' traffic with a 0 CIR subscription. Some service providers do provide an SLA to ensure that customers receive an acceptable level of service to prevent all of their frames from dropping. The service provider's switch typically drops frames only when there is a substantial amount of congestion in the network.

Moderated CIR

In the moderated CIR scenario, the service provider provides Frame Relay access with a guaranteed CIR rate that is lower than the physical access speed but potentially greater than 0 CIR. For example, the physical access link might be a T1 circuit with a maximum access speed of 1.544 Mbps. However, the guaranteed CIR is moderated to a fraction of the maximum physical access speed at 512 kbps. Therefore, only traffic transferred within the rate of 512 kbps is guaranteed transfer by the service provider. Traffic transmitted at above the moderated CIR is susceptible to drop when the network encounters congestion.

The concept of a moderated, average CIR can be better explained using an example. Consider Figure 3-5, which shows a scenario where the local loop or the physical access link at each remote site supports a maximum access rate of 256 kbps. A moderated CIR service allocates a CIR subscription rate lower than the actual access link speed but greater than 0 CIR. Each remote site uses a 50 percent moderation, or "half-CIR" option, of 128 kbps.

Figure 3-5. Subscribing to Moderated CIR

All four branch office sites connect to the central office via individual Frame Relay virtual circuits. Each site is capable of transferring at a moderated CIR rate of 128 kbps. The aggregate CIR of all virtual circuits carried into the central site is 4 x 128 kbps. The central site has a physical access link speed of 1.544 Mbps, and it requires a moderated CIR of at least 512 kbps (fractional T1) to ensure that it can handle the aggregate traffic load from all remote sites.

Subscribing to moderated CIR might not protect your network from oversubscription and congestion. The downside of this design is that when the branch office sites burst beyond their CIR of 128 kbps, oversubscription occurs and congestion can build up at the switch interface side to the central site router. Similarly, if the central site bursts downstream beyond its subscribed CIR, congestion can occur at the branch office sides of the Frame Relay network. With this level of CIR subscription, the Frame Relay network allows the network to burst beyond 128 kbps, but everything beyond the CIR is delivered with a "best effort." During sustained periods of oversubscription, the Frame Relay network becomes heavily congested and drops all frames when it can no longer handle them.

This solution is viable only if the network planners have a complete knowledge of the bandwidth requirements, the traffic patterns, and the protocol mix on the network. Taking this example further, adopting a CIR rate of 128 kbps at the branch office sites assumes the bandwidth requirements of core mission-critical applications do not normally exceed 128 kbps. The less-critical traffic is given "best effort" delivery service during oversubscription and has to be tolerant to dropped frames when the Frame Relay network becomes congested. Error recovery should be performed by upper-layer protocols, and dropped frames should be retransmitted.

The moderate CIR model allows an organization to match cost and performance to its business needs. However, during network implementation, network planners should monitor and observe whether the level of CIR subscription is capable of handling the traffic load. If the subscription level is not viable and oversubscription occurs for long sustained periods, adding additional bandwidth to the existing CIR might be required. In addition, network planners can consider deploying queuing and prioritization mechanisms to give mission-critical traffic a higher priority at the ingress point into the Frame Relay network.

Maximum CIR

Subscribing to the actual physical access link speed gives the highest level of CIR subscription. This is arguably the safest level of CIR subscription and has the highest level of performance when it comes to bandwidth availability. However, this model comes with the highest cost compared with the earlier options that have been discussed.

Using Figure 3-5 again as our example, a maximum level of CIR subscription allocates a CIR rate of 256 kbps at the branch office sites. The central site subscribes to the full CIR rate of 1.544 Mbps at T1 speed. The committed burst also allows for sustained periods of burst. The downside of this model is that it is a high-cost solution.


Frame Relay Topology Options

After establishing the users' bandwidth requirements and the level of CIR subscription, network designers have to work on the approach for handling interconnections among sites within the same administrative region or area. In designing any regional WAN, whether it is based on packet-switching services or point-to-point interconnections, there are three basic design approaches.

Star Topology

The star topology, also known as hub-and-spoke topology, is the most common topology in use today. In a star topology, typically a central or hub site is connected to several remote or spoke sites. This topology is the most cost-effective because redundant links between the remote sites are reduced to a minimum. Connectivity between the remote sites is via the central site. However, this arrangement poses the risk of a single point of failure in the network. When the central site goes down, connectivity between the operational remote sites is broken. Figure 3-6 shows an example of the star topology.

Figure 3-6. Star Topology

The advantages of a star approach are simplified management and minimized tariff costs. However, the disadvantages are significant. First, the core router represents a single point of failure. Second, the core router limits overall performance for access to backbone resources, because it is a single pipe through which all traffic intended for the backbone (or for the other regional routers) must pass. Third, this topology is not scalable.

Fully Meshed Topology

A fully meshed topology allows the maximum redundancy in the network. In a fully meshed network, each node has a direct connection to every other node. As a result, when a direct link between two nodes goes down, connectivity between the two nodes can be ensured with redundant paths via other nodes. However, fully meshed topologies are the most expensive. To create a fully meshed topology with n number of nodes, n(n 1)/2 links are required. Figure 3-7 shows an example of a fully meshed topology.

Figure 3-7. Fully Meshed Topology

The key rationale for creating a fully meshed environment is to provide a high level of redundancy. Although a fully meshed topology facilitates support of all network protocols, it is not tenable in large packet-switched internetworks. Key issues are the large number of virtual circuits required (one for every connection between routers), problems associated with the large number of packet/broadcast replications required, and the configuration complexity for routers in the absence of multicast support in nonbroadcast environments.

By combining fully meshed and star approaches into a partially meshed environment, you can improve fault tolerance without encountering the performance and management problems associated with a fully meshed approach. The next section discusses the partially meshed approach.

Partially Meshed Topology

In contrast with a fully meshed topology, a partially meshed topology does not support direct accessibility between every node on a network. There is no distinctive rule that defines the characteristics of a partially meshed topology. To reduce cost, not every node on the partially meshed network has a direct connection to every other node. The star topology fits the description of a partially meshed topology. Figure 3-8 presents an example of a partially meshed topology.

Figure 3-8. Partially Meshed Topology

There are many forms of partially meshed topologies. In general, partially meshed approaches are considered to provide the best balance for regional topologies in terms of the number of virtual circuits, redundancy, and performance.


Performance Management

The performance of the network is an imperative consideration for a network planner during network planning. Network congestion, bottlenecks, jitters, and latency are examples of commonly encountered problems that can reduce the overall reliability and performance of your network. Network managers have to protect the mission-critical traffic against these issues. For example, on networks where bandwidth is a scarce resource, network managers can implement Quality of Service (QoS) solutions to efficiently manage the network. This section suggests some practices that network planners can consider to manage the network performance.

Classifying Mission-Critical Traffic

On a Frame Relay network where different types of traffic are transmitted on the same access link, mission-critical traffic shares the common subscribed bandwidth with other types of traffic. Often, mission-critical traffic can be held up and delayed by less-important traffic in the transmission queues, eventually causing unacceptable latency and jitters to these applications. A solution to this problem is to classify mission-critical traffic for special handling by the network.

Traffic classification is an important component of network planning whereby different types of traffic on the network are labeled and categorized. Typically, mission-critical traffic is marked and prioritized for preference handling by network equipment. Common examples of mission-critical applications include ERP software and data-warehousing applications. Real-time applications such as voice and video also fall into this category.

Consider a couple of examples of traffic classification. One startup company offering voice and video over IP services on the Internet might prioritize voice and video packets as high-priority traffic. In another example, a regional bank would classify its ATM transactions as the highest-priority traffic over all other traffic on its network. The rules for identifying mission-critical traffic differ widely. There is no strict guideline for classifying mission-critical traffic. Each organization must make its own judgment of what is critical and what is not. The simplest rule is to know your traffic.

To improve the network performance for handling mission-critical traffic, Cisco supports QoS features that can be deployed on Cisco routers to allow users' traffic to be prioritized for transmission into the Frame Relay network. Typically, a percentage of the available bandwidth is allocated to mission-critical traffic.

Low Latency Queuing (LLQ) is an example of a Cisco IOS feature that allows priority handling for an identified class of traffic. Alternatively, the performance of the network can be improved by provisioning additional bandwidth or by adding more PVCs for handling high-priority traffic exclusively. However, buying more bandwidth or PVCs adds to the cost factor.

Managing Congestion

Congestion is a very common problem seen on Frame Relay networks. If congestion is not managed and controlled, it can adversely affect the overall performance of the network. A severely congested Frame Relay network observes frequent frame drops and users' application timeouts. Early signs of a congested network are Backward Explicit Congestion Notification (BECN) and Forward Explicit Congestion Notification (FECN) flagged bits in the received frame headers. Some users' applications have the proper intelligence to respond to these frames and throttle down the traffic when BECN and FECN bits are seen.

Traffic Shaping

Frame Relay traffic shaping is a useful feature for rate-limiting the traffic and controlling congestion in a Frame Relay network. On a Frame Relay network where there is a high-speed connection at the central site and low-speed connections at the branch office sites, Frame Relay traffic shaping can be strategically deployed at the central office router and branch offices routers' egress points into the Frame Relay network. Frame Relay traffic shaping helps to manage oversubscription of the CIR and to prevent network congestion in the Frame Relay network. Frame Relay traffic shaping can allow the router to control the rate of transmission based on CIR or other defined values on a per-virtual-circuit basis. On a traffic-shaped virtual circuit, if the guaranteed CIR rate is 64 kbps and the access rate is 128 kbps, it is possible to burst above the CIR rate when there is no congestion and then throttle down the transmission rate back to the guaranteed rate when there is congestion. This helps to reduce the probability of frames getting dropped by stepping down the transmission rate of frames entering a congested Frame Relay network.

Queuing

The Cisco IOS software offers many queuing features that support Frame Relay services. This section provides an overview of some general queuing techniques, such as priority queuing and custom queuing. In general, queuing can be used to manage network performance by controlling the traffic flow entering a congested Frame Relay network. Advanced queuing topics will be addressed and discussed in depth in Part IV of this book.

Priority Queuing

Priority queuing utilizes strict prioritization in selecting the traffic for transmission. Traffic can be classified based on various possible criteria and queued on one of four output queues: high, medium, normal, or low priority. The traffic classified as the highest priority traffic is given all the available bandwidth for transmission. Then the next lower priority traffic gets its turn for transmission when there is no traffic with a higher priority waiting. Priority queuing is commonly used for classifying mission-critical traffic with the highest priority so that it receives the highest preference handling before other traffic. Priority queuing is most useful on low-speed serial links. On networks where time-sensitive applications are common, priority queuing improves the network performance for interactive traffic. Figure 3-9 shows an example of priority queuing.

Figure 3-9. Priority Queuing

Custom Queuing

As opposed to priority queuing, custom queuing allows network administrators to manage the total available bandwidth on the network fairly for use by each type of traffic. Because of the nature of its design, priority queuing has an inherent problem where packets classified to the lower priority queues may never get service at all if there is always traffic active in the higher priority queues. Custom queuing allows network administrators to overcome the rigid queuing system in priority queuing. With custom queuing, the administrator allocates a percentage of the total available bandwidth for all types of traffic. In this way, the low-priority traffic gets a fair share of the total available bandwidth. Any remaining bandwidth that is not assigned is usually allocated to a "default" queue. Traffic not classified as belonging to any of the custom queues is sent to the default queue. The router polls each allocated custom queue in a round-robin fashion for transmission. If one of the defined custom queues is empty during its turn, the empty queue's bandwidth is made available for the other traffic types. In custom queuing, up to 16 custom queues can be defined.

Consider the example in Figure 3-10. Using custom queuing, the network administrator has allocated 40 percent of the total available bandwidth to all UDP traffic. Both TCP and IPX traffic are each allocated 20 percent of the total available bandwidth. The remaining 20 percent of the total available bandwidth is assigned to the default custom queue. Traffic that does not belong to TCP, UDP, or IPX types is given at least 20 percent share of the total available bandwidth reserved for the default queue. Then, the size of each configured custom queue can be determined by the user.

Figure 3-10. Custom Queuing

[View full size image]

Frame Relay Compression

Data compression can be used to decrease the size of a frame. As a result of the reduced size of the frame, the throughput across the virtual circuit is increased. The compressed headers result in smaller packets that lessen congestion on the network. Using compression can help to alleviate the congestion problem on slower access links.

Several compression algorithms are available. Compression algorithms reproduce the original bit streams exactly without any loss or degradation. The Cisco IOS supports the STAC(LZS) compression algorithm, which has a good compression ratio. The higher the compression ratio, the more a frame can be compressed. Take note that compression needs many CPU cycles on a router.

Both software-based and hardware-based compression options exist. Hardware-based compression solutions are similar to software-based compression solutions, but hardware-based compression increases the overall performance by offloading the intensive compression computations from the router's CPU. This allows CPU resources to be used for other functionality that is enabled on the router. However, hardware-based compression solutions require additional dedicated compression modules or cards to be installed on the routers. Therefore, hardware-based compression solutions are usually more costly than software-based compression solutions.

Cisco serial interfaces using Frame Relay encapsulations support the LZS algorithm. The Frame Relay FRF.9 implementation agreement for compression is accredited by the Frame Relay Forum and uses the LZS compression algorithm.

The FRF.9 implementation agreement defines data compression over Frame Relay using the Data Compression Protocol (DCP). The compression mechanisms can be implemented on both switched virtual circuits (SVCs) and PVCs.

The compressed payload is transported through the Frame Relay network and decompressed at its termination point. Thus, FRF.9 is point-to-point.


Managing Broadcast Traffic

A major concern of Frame Relay network planners is the significant amount of bandwidth consumed by broadcast traffic. For example, routing protocol updates are a source of broadcast traffic commonly seen on a network. Typically, broadcast traffic is generated periodically and places a consistent amount of traffic on the network. Network planners should ensure that broadcast traffic does not starve mission-critical data traffic of its minimum required bandwidth.

Broadcast traffic comes from many different sources. Dynamic routing protocols such as RIP and IGRP send out periodic routing updates. Routed protocols such as IPX can also generate a substantial amount of broadcast traffic. Bridging traffic can similarly create a large amount of broadcast traffic on the network.

Consider Table 3-1, where the different types and the relative level of broadcasts are listed.

Table 3-1. Broadcast Traffic Levels of Protocols

Network Protocol

Routing Protocol

Level of Broadcast

IP

RIP

IGRP

OSPF

IS-IS

EIGRP

BGP

EGP

High

High

Low

Low

Low

None

None

IPX

RIP

EIGRP

SAP

High

Low

High

AppleTalk

RTMP

EIGRP

High

Low

Bridging

Transparent

Remote SRB

DLSW

High

High

Low (DLSW peer-on-demand)

Consider the following example to illustrate how broadcast traffic can consume a significant amount of bandwidth on a Frame Relay circuit. A distance vector routing protocol such as IP Routing Information Protocol Version 1 (RIPv1) can place a massive amount of broadcast traffic on a network. A router running the RIP dynamic routing protocol sends out routing updates to its RIP-speaking neighbors at every 30-second interval. Each RIP routing update packet can carry RIP route information for up to 25 destinations.

The basic information for the RIP protocol is shown below:

  • Size of each RIP routing entry = 20 bytes

  • Size of each RIP header information = 36 bytes

  • RIP route update interval = 30 seconds

Using the above information for RIP, an example illustrates how broadcast traffic generated by RIP route updates can potentially use up a significant amount of bandwidth on a Frame Relay network. The scenario in this example involves a single hub location connected to 50 spoke sites.

Suppose each spoke location supports 20 subnets and the hub router's IP route table contains route entries for a total of 1000 RIP destinations (50 spokes x 20 subnets). Because stated earlier, the size of a RIP routing entry is 20 bytes. Therefore, 1000 routing entries require approximately 20,000 bytes (20 bytes x 1000 entries) of information. Because each RIP route update packet contains route entries for a maximum of 25 destinations, 40 RIP update packets (1000/25) are required to process the route entries for all 1000 spoke locations. In addition to kbps the 20 bytes of route entry data, each RIP packet has a 36-byte header. Thus, the total amount of packet header information is 1440 bytes (36 bytes x 40 RIP update packets). The total amount of information transmitted every 30-second interval is 21,440 bytes (20,000 payload + 1,440 header).

Each spoke site aggregates a virtual circuit into the central site. A total of 50 virtual circuits are multiplexed at the central site, and 50 corresponding DLCIs are mapped to each spoke location. There are 1,072,000 bytes (21,440 bytes x 50 DLCIs) transmitted at the central site at every 30-second interval. This works out to a regular transmission rate of approximately 285 kbps (1,072,000 bytes / 30 seconds x 8 bits/bytes). As such, 285 kbps of the total bandwidth are used up by RIP routing updates alone. If the hub site has a CIR of 512 kbps, as shown in Figure 3-5, approximately 55.6 percent of the bandwidth is used up for exchanging routing updates alone, leaving 44.4 percent of the available bandwidth for the mission-critical data.

This example shows that using a protocol such as RIP can create a bottleneck in the network by generating a massive amount of broadcast overhead. Broadcast traffic and overhead have to be carefully considered during network planning and bandwidth provisioning.


Providing a Backup to Frame Relay Virtual Circuits

Using secondary connections to back up the main Frame Relay virtual circuits allows organizations to continue their business operations by ensuring network connectivity in the event of failures to the primary connections. Provisioning a secondary backup connection to the primary Frame Relay virtual circuit can prevent a single point of failure in the network.

Some Frame Relay carriers offer network redundancy services by provisioning a secondary virtual circuit as a backup to the primary virtual circuit. This secondary virtual circuit is also sometimes known as a "shadow" virtual circuit. Under this arrangement, the secondary virtual circuit runs parallel to the main virtual circuit but remains inactive when it is in standby mode. When the primary virtual circuit fails, the network transfers over to the secondary connection. The secondary backup virtual circuit is usually allocated a 0 CIR because the secondary connection is completely unused under normal conditions.

Figure 3-11 shows an example of how to use a secondary virtual circuit to provide a backup to the primary virtual circuit.

Figure 3-11. Using a Redundant Virtual Circuit to Provide Backup

Integrated Services Digital Network (ISDN) can be an attractive solution for providing a backup to the primary Frame Relay connection. Using ISDN as backup to the Frame Relay virtual circuit is a cost-effective implementation because service providers typically bill ISDN services based on usage. Figure 3-12 shows an example of a Frame Relay network employing a backup secondary connection using ISDN. During normal operations, all traffic passes on the primary Frame Relay virtual circuit. The ISDN backup connection becomes activated should the primary Frame Relay virtual circuit fail. There are many ways to implement ISDN backup on a Cisco router, including using floating static routes and configuring backup commands.

Figure 3-12. Using ISDN Dial Backup to Frame Relay

Previous Page
Next Page


A Common Issue Encountered in Frame Relay Networks

This section looks at a common issue encountered during the implementation of Frame Relay networks. The discussion covers the problems introduced by split horizon on Frame Relay networks and how Cisco uses subinterfaces to resolve this problem.

Split Horizon

The split horizon rule states that a router should not advertise a route out of an interface where the route was learned. For example, when RIP is the designated routing protocol on the network, the split horizon rule means that when the router sends a RIP update out a particular network interface, it should never include routing information acquired for that network over that same interface. Sending out a route update on an interface where the same update was learned can potentially cause routing loops in a network, creating a problem commonly known as the "count to infinity."

Split horizon helps to prevent instabilities in the network by suppressing the propagation of bad routing information. Poison reverse is another technique used to prevent route instabilities in a dynamic routing protocol. With poison reverse, the router advertises a route update as unreachable on an interface where the same route update was learned. Figure 3-13 shows an example of split horizon.

Figure 3-13. Split Horizon Rule

In this example, three routers are configured with RIP routing protocols. The Hawk router sends route 10.1.1.0/24 to the Vulture router. By the split horizon rule, the Vulture router should never advertise route 10.1.1.0/24 back on the interface where the route was learned. In this case, it is not allowed to advertise route 10.1.1.0/24 back to Hawk.

Split horizon is useful in preventing routing loops, but it can cause problems on hub-and-spoke Frame Relay networks. On the hub router, multiple Frame Relay virtual circuits are usually multiplexed and terminated onto one physical interface. Figure 3-14 shows an example of this.

Figure 3-14. Multiple Virtual Circuits Multiplexed onto One Physical Interface

Under these conditions, the router is completely unaware that multiple virtual connections exist on the same physical interface. As such, the split horizon rule applies, and routes learned on one virtual circuit are never advertised to other virtual circuits on the same physical interface, even though they are transmitted on different virtual circuits.

Figure 3-15 shows an example of a Frame Relay network faced with the split horizon problem. In this example, Vulture is a hub router connected to two branch office routers: Raven and Hawk. To conserve IP address space, all three locations are configured to use the 172.16.1.0/29 subnet address. This Frame Relay network is termed as nonbroadcast multiaccess (NBMA) because all locations are configured as nodes on the same IP subnet in a way similar to an Ethernet LAN segment. However, an NBMA Frame Relay network does not support the broadcast capability of a traditional Ethernet LAN.

Figure 3-15. The Split Horizon Problem on a Frame Relay Network

The three routers are now configured to exchange route information via a distance vector routing protocol such as RIP. Raven and Hawk routers can exchange routing updates directly with Vulture router and vice-versa. However, because of the split horizon issue at Vulture, Vulture is unable to forward routing information learned from Raven to Hawk or from Hawk to Raven. Although Vulture is logically connected to the two remote locations on separate virtual circuits, both virtual circuits are logically multiplexed on the same physical interface. The split horizon rule simply forbids Vulture from sending route information out of an interface if the same route information was learned from the same physical interface.

A workaround to this problem is to have a fully meshed topology by adding a virtual circuit directly between Hawk and Raven routers. In this way, Hawk and Raven routers can exchange route information directly with each other. However, a fully meshed topology increases the operating costs of the network. An alternative solution is to add a separate physical interface on Vulture router so that each remote connection is terminated at the hub location on different hardware. This is not viable because of the added hardware cost. Moreover, this solution would require a different IP subnet address to be used for each virtual connection. Another solution would be to use advanced dynamic link-state routing protocols, which understand the NBMA nature of the Frame Relay network. However, advanced link-state routing protocols, such as Open Shortest Path First (OSPF), place greater demands on the CPU and memory resources of the routers.

In the next section, a more scalable solution using logical software interfaces will be introduced.

On Cisco routers, split horizon is disabled by default for Frame Relay so that routing updates can come in and out of the same interface. However, on partially meshed Frame Relay networks, some protocols, such as IPX, AppleTalk, and transparent bridging, require split horizon in order to work properly.

Using Subinterfaces on Cisco Routers

Cisco routers support the configuration of logical subinterfaces on a physical interface. Configuring subinterfaces allows a single physical interface to be treated as multiple virtual interfaces. This allows the split horizon issues to be overcome. Packets received on one subinterface can be forwarded out another subinterface, even though they are all configured on the same physical interface.

Two different implementations of subinterface types are supported by Cisco routers: point-to-point and multipoint subinterfaces. A subinterface is a logical software interface managed internally by the router. Note that a subinterface uses up memory on the router. The number of subinterfaces that can be configured largely depends on the amount of memory on the router.

Point-to-Point Subinterfaces

Point-to-point subinterfaces allow the physical Frame Relay interface to be partitioned into a number of virtual point-to-point subnetworks. Each point-to-point subnetwork can be assigned its own network number. To the routed protocol, each subinterface appears as if it is located on a separate interface. Routing updates received from one logical point-to-point subinterface can be forwarded out to another logical point-to-point subinterface that is configured under the same physical interface without violating the rule of split horizon. On partially meshed Frame Relay networks, a point-to-point subinterface solves the problem introduced by split horizon. Figure 3-16 shows an example of using point-to-point subinterfaces to overcome split horizon on a partially meshed Frame Relay network.

Figure 3-16. Point-to-Point Subinterfaces on a Partially Meshed Frame Relay Network

Multipoint Subinterfaces

The second implementation of Frame Relay subinterfaces is the multipoint subinterface. A multipoint subinterface is similar to the physical interface. On Cisco routers, all serial interfaces are multipoint interfaces by default, and multipoint subinterfaces behave exactly like physical interfaces. Both physical and multipoint subinterfaces are subjected to the rule of split horizon. Compared with point-to-point subinterfaces where each point-to-point connection represents a different subnet, multipoint subinterfaces keep all remote sites on a single network. All nodes connected to a multipoint subinterface belong to the same subnet.

One major difference between point-to-point subinterface and multipoint subinterface is that on a point-to-point subinterface, only one DLCI can be assigned to the subinterface. On a multipoint subinterface, multiple DLCIs can be assigned.

Consider an example of multipoint subinterfaces in Figure 3-17. In this example, the Vulture router has a multipoint subinterface configured under its physical interface. Three virtual circuits are terminated at the multipoint subinterface from three different remote locations. As such, the multipoint interface has three DLCIs assigned to uniquely identify the virtual connection belonging to each location. All nodes are placed on the same subnet address. If point-to-point subinterfaces were used, each point-to-point connection would require a separate network layer address.

Figure 3-17. Multipoint Subinterface

On Cisco devices, split horizon is enabled or disabled by default, depending on the interface type. Table 3-2 summarizes the default split horizon behavior on Cisco Frame Relay interfaces.

Table 3-2. Default Behavior of Split Horizon on Cisco Frame Relay Interfaces

Frame Relay Interface Type

Default Behavior of Split Horizon

Physical

Disabled

Point-to-point subinterface

Enabled

Multipoint subinterface

Enabled


Summary

This chapter focused on the important considerations of Frame Relay network planning. Network performance, recurring cost, and future scalability of the network topology are some of the key issues network planners should consider during the network planning and implementation phase. This chapter discussed the different levels of CIR services commonly offered by major service providers. Different Frame Relay topologies were considered, including the advantages and disadvantages associated with each type of topology. This chapter also briefly discussed Frame Relay network performance management. Different methods of improving network performance were introduced, such as controlling network congestion, controlling broadcast traffic, and using advanced queuing mechanisms to prioritize mission-critical traffic. Finally, this chapter presented the concept of Frame Relay subinterfaces supported on the Cisco router and how to effectively overcome the issues created by the split horizon rule. The next chapter will examine the basic configurations of Frame Relay on the Cisco IOS.


Review Questions

1: | What are the three key factors that affect network planning?
2: | What are the different network topologies, and which is the most commonly seen for Frame Relay networks?
3: | What are the types of traffic that are usually given the highest preference for handling and transmission?
4: | What are the available options for backing up a Frame Relay virtual circuit?
5: | What is split horizon? How can split horizon be overcome on a partially meshed Frame Relay NBMA network?


Chapter 4. Cisco Frame Relay Configurations

This chapter covers the basic Cisco IOS configuration commands for configuring Frame Relay on a Cisco router. After completion of this chapter, readers will be able to configure basic Frame Relay operations on Cisco routers in a router-based Frame Relay network. Along with the discussion of Cisco IOS Frame Relay configuration commands, the available Cisco IOS show commands for monitoring Frame Relay will be highlighted and explained. The use of diagnostic Cisco IOS debug commands for troubleshooting common Frame Relay problems and issues on the Frame Relay network will also be discussed.

The topics and questions that this chapter addresses include the following:

  • Enabling Frame Relay encapsulation

  • Configuring LMI type on a Frame Relay interface

  • Configuring static and dynamic DLCI to network layer address mapping

  • Configuring Frame Relay subinterfaces

  • Configuring point-to-point subinterfaces

  • Configuring multipoint subinterfaces

  • Configuring a Cisco router as a Frame Relay switch

  • Configuring Frame Relay switching using a local significance approach to DLCI assignment

  • Configuring Frame Relay switching using a global significance approach to DLCI assignment

  • Verifying Frame Relay connections with Cisco IOS show commands

  • Troubleshooting Frame Relay connections with IOS debug commands

After completing this chapter, readers will be able to perform the basic Frame Relay configuration commands with the Cisco IOS software. Readers will be able to configure a basic Frame Relay network involving Cisco equipment and to perform basic monitoring and troubleshooting using relevant Cisco IOS show and debug commands.


Configuring Frame Relay

Frame Relay is configured on the Cisco router via the text-based Cisco IOS Command Line Interface (CLI). This section looks at the configuration commands required to configure basic Frame Relay operation on a Cisco router.

A basic setup involving the hardware configurations depicted in Figure 4-1 is used for this discussion and for illustration purposes. In the later part of this chapter, additional hardware will be required to explain more complex configuration tasks. In the setup used in this chapter, the Cisco routers are configured as Frame Relay access devices, or data terminal equipment (DTE), connected directly to a dedicated Frame Relay switch, or data circuit-terminating equipment (DCE). Note that Cisco routers can be configured to operate similarly as a Frame Relay switch as well. The configuration tasks will be fully explained in a later section.

Figure 4-1. Frame Relay Hardware Configuration

NOTE

Different Cisco IOS software versions or releases may display slightly different outputs. To maintain consistency of the Cisco IOS Software Version, IOS 12.2(1) release is loaded on all routers used in the configuration examples of this chapter.

Example 4-1 displays the show output of the show version command on R1.

Example 4-1. IOS Version Loaded on the Lab Routers
R1#show version
Cisco Internetwork Operating System Software
IOS (tm) 7200 Software (C7200-JS-M), Version 12.2(1), RELEASE SOFTWARE (fc2)
Copyright (c) 1986-2001 by cisco Systems, Inc.
Compiled Thu 26-Apr-01 22:10 by cmong
Image text-base: 0x60008960, data-base: 0x616B0000


Enabling Frame Relay Encapsulation

On a Cisco router, Frame Relay can be configured only on the supported interfaces; it's most commonly supported on synchronous serial interfaces. A single Cisco IOS command is all that is required to enable Frame Relay on the serial interface. The encapsulation frame-relay interface configuration command, as follows, is used to enable Frame Relay encapsulation and to allow Frame Relay processing on the supported interface.

R1(config)#interface serial4/2

R1(config-if)#encapsulation frame-relay [ietf]

To enable Frame Relay on a serial interface, follow the configuration steps listed below beginning in the global configuration mode:

Step 1. | Go into the interface configuration mode of the interface on which you want to enable Frame Relay.
Step 2. | (optional) Configure Frame Relay encapsulation to use either Cisco or IETF encapsulations. If the encapsulation type is not specified, by default Cisco encapsulation is used.

The no form of the encapsulation frame-relay command removes the Frame Relay encapsulation on the interface, as shown in Example 4-2. On a serial interface, the no encapsulation frame-relay command causes the interface to revert to the default High-Level Data Link Control (HDLC) encapsulation. Moreover, all preexisting Frame Relay configurations on the serial interface are automatically removed.

Example 4-2. Unconfiguring Frame Relay Encapsulation
R1#config terminal
Enter configuration commands, one per line.  End with CNTL/Z.
R1(config)#interface serial4/2
R1(config-if)#no encapsulation frame-relay

NOTE

Readers should note that Frame Relay can be configured only on certain supported interfaces, which presently include synchronous serial interfaces, High Speed Serial Interfaces (HSSI), and packets over SONET (POS) interfaces on the Cisco 12000 Series Gigabit Switch Router. It is not possible to configure Frame Relay on specialized interfaces such as Ethernet or ATM. An error message is returned by the CLI every time a user attempts to configure Frame Relay on nonsupported interfaces, as demonstrated in Example 4-3. In this chapter, the term Frame Relay interface refers to a Frame Relay-enabled interface, which can belong to any of the supported interfaces mentioned.

Example 4-3. Error Message Shown When Attempting to Configure Frame Relay Encapsulation on Nonserial Interfaces
R1#config terminal
Enter configuration commands, one per line.  End with CNTL/Z.
R1(config)#interface Ethernet1/0
R1(config-if)#encapsulation frame-relay
                                ^
_% Invalid input detected at '^' marker.

Cisco supports two different Frame Relay encapsulation types. The default Frame Relay encapsulation enabled on supported interfaces is the Cisco encapsulation. Cisco also supports the IETF Frame Relay encapsulation type, which is in conformance with RFC 1490 and RFC 2427. RFC 2427 supercedes RFC 1490. Both RFC specifications define standards allowing multiple routed protocols to be carried over Frame Relay. Readers can refer to http://www.faqs.org/rfcs/rfc2427.html and http://www.faqs.org/rfcs/rfc1490.html for references on both RFCs.

In general, the IETF Frame Relay encapsulation should be used when connecting a Cisco router to non-Cisco equipment across a Frame Relay network. The IETF Frame Relay encapsulation allows interoperability between equipment from multiple vendors. Example 4-4 describes the steps for enabling Frame Relay on a serial interface using the IETF encapsulation. The keyword ietf specifies IETF Frame Relay encapsulation to be used on the serial interface. If the encapsulation frame-relay command is entered without specifying the optional ietf keyword, the router defaults to using the Cisco encapsulation type on that interface.

Example 4-4. Configuring Frame Relay IETF Encapsulation at the Interface Level
R1#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
R1(config)#interface serial 4/2
R1(config-if)#encapsulation frame-relay ?
  ietf  Use RFC1490/RFC2427 encapsulation
  <cr>
R1(config-if)#encapsulation frame-relay ietf

NOTE

Both Cisco and IETF encapsulations for Frame Relay can be configured on a per-virtual-circuit (VC) basis. This gives greater flexibility when configuring Frame Relay in a multivendor environment. A user can specify the Frame Relay encapsulation types to be used on different virtual circuits configured under the same physical interface.

Example 4-5. Configuring Frame Relay Cisco and IETF Encapsulation at the DLCI Level
R1#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
R1(config)#interface serial 4/2
R1(config-if)#encapsulation frame-relay
R1(config-if)#frame-relay map ip 172.16.1.1 102 broadcast ietf
R1(config-if)#frame-relay map ip 192.168.1.1 103 broadcast cisco

After enabling Frame Relay encapsulation on the interface, it might be necessary to perform a no shutdown command at the interface level to bring up the interface if it was previously in the shutdown mode. Verify the status of the Frame Relay interface with the show interface type slot/port privileged EXEC mode command. When the Frame Relay interface is operational, the interface is in the Interface is up, line protocol is up state. Both configuration changes and the associated command output are illustrated in Example 4-6.

Example 4-6. Bringing Up the Interface and Displaying the Configured Frame Relay Encapsulation
R1#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
R1(config)#inter serial4/2
R1(config-if)#no shutdown
R1(config-if)#
02:46:09: %LINK-3-UPDOWN: Interface Serial4/2, changed state to up
02:46:10: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial4/2, changed state to up
R1#sh
02:46:10: %SYS-5-CONFIG_I: Configured from console by conso
R1#show interface serial 4/2
Serial4/2 is up, line protocol is up
  Hardware is M4T
  Internet address is 172.16.1.1/24
  MTU 1500 bytes, BW 2048 Kbit, DLY 20000 usec,
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation FRAME-RELAY, crc 16, loopback not set
  Keepalive set (10 sec)
  LMI enq sent  76, LMI stat recvd 78, LMI upd recvd 0, DTE LMI up
  LMI enq recvd 0, LMI stat sent  0, LMI upd sent  0
  LMI DLCI 1023  LMI type is CISCO  frame relay DTE
  FR SVC disabled, LAPF state down
  Broadcast queue 0/64, broadcasts sent/dropped 9/0, interface broadcasts 0
  Last input 00:00:09, output 00:00:09, output hang never
  Last clearing of "show interface" counters 00:14:03
  Input queue: 0/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/1/256 (active/max active/max total)
     Reserved Conversations 0/0 (allocated/max allocated)
     Available Bandwidth 1536 kilobits/sec
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
79 packets input, 1163 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
     101 packets output, 1525 bytes, 0 underruns
     0 output errors, 0 collisions, 4 interface resets
     0 output buffer failures, 0 output buffers swapped out
     4 carrier transitions     DCD=up  DSR=up  DTR=up  RTS=up CTS=up

As shown in Example 4-6, the output of the show interface command also reveals the Frame Relay encapsulation type configured on that interface. Encapsulation FRAME-RELAY in the output indicates that Cisco Frame Relay encapsulation type is enabled. Encapsulation FRAME-RELAY IETF shows that IETF Frame Relay encapsulation type is in use.


Configuring the LMI Type on a Frame Relay Interface

Cisco supports three different Local Management Interface (LMI) types for Frame Relay: Cisco, ANSI Annex D, and Q933-A Annex A. Beginning with Cisco IOS Software Release 11.2, the LMI autosense feature allows a Frame Relay interface to autodetect the LMI type supported by the directly connected Frame Relay switch. Based on the LMI status messages it receives from the Frame Relay switch, the router automatically configures its Frame Relay interface with the supported LMI type acknowledged by the Frame Relay switch.

No extra configuration command is required on a Cisco router to activate the LMI autosense feature. With Cisco IOS Release 11.2 or later, LMI autosense is activated by default when an LMI type is not explicitly configured on the interface. After the no shutdown interface configuration command is used to activate the Frame Relay interface, the interface starts polling the Frame Relay switch for the supported LMI type by sending out LMI status requests for all three supported LMI typesANSI, Q933-A, and Ciscoin quick succession.

In the debug output shown in Example 4-7, the debug frame-relay lmi command is used on a Cisco router to display the LMI exchanges between the router and the connected Frame Relay switch. The router sends out LMI status enquiries to the Frame Relay switch in an attempt to determine an LMI type supported by the switch. This is indicated by the observation of StEnq in the debugs. A status enquiry message is sent out for each LMI type in the following sequence: ANSI, Q933-A, and Cisco. The status reply message returned by the switch carries information on the supported LMI type, as well as the status of active permanent virtual circuits (PVCs). A successful exchange of LMI status messages with the Frame Relay switch increments the LMI sequence counter on the router.

After the router learns the LMI type supported by the Frame Relay switch, it installs the supported LMI type on its Frame Relay interface.

Example 4-7. Frame Relay Interface on Router R1 Sends Out LMI Status Requests to the Switch When Activated
[View full width]
R1#debug frame-relay lmi
02:51:41: %LINK-3-UPDOWN: Interface Serial4/2, changed state to up
*Jul  5 00:20:53.535: Serial4/2(out): StEnq, myseq 1, yourseen 0, DTE up
*Jul  5 00:20:53.535: datagramstart = 0x7000214, datagramsize = 14
*Jul  5 00:20:53.535: FR encap = 0x00010308
*Jul  5 00:20:53.535: 00 75 95 01 01 00 03 02 01 00
*Jul  5 00:20:53.535:
*Jul  5 00:20:53.535: Serial4/2(out): StEnq, myseq 1, yourseen 0, DTE up
*Jul  5 00:20:53.535: datagramstart = 0x70000D4, datagramsize = 13
*Jul  5 00:20:53.535: FR encap = 0x00010308
*Jul  5 00:20:53.535: 00 75 51 01 00 53 02 01 00
*Jul  5 00:20:53.535:
*Jul  5 00:20:53.535: Serial4/2(out): StEnq, myseq 1, yourseen 0, DTE up
*Jul  5 00:20:53.535: datagramstart = 0x7000214, datagramsize = 13
*Jul  5 00:20:53.535: FR encap = 0xFCF10309
*Jul  5 00:20:53.535: 00 75 01 01 00 03 02 01 00
*Jul  5 00:20:53.535:
*Jul  5 00:20:53.547: Serial4/2(in): Status, myseq 1
*Jul  5 00:20:53.547: RT IE 1, length 1, type 0
*Jul  5 00:20:53.547: KA IE 3, length 2, yourseq 1 , myseq 1
*Jul  5 00:20:53.547: PVC IE 0x7 , length 0x6 , dlci 100, status 0x0 , bw 0
*Jul  5 00:21:03.535: Serial4/2(out): StEnq, myseq 2, yourseen 1, DTE up
*Jul  5 00:21:03.535: datagramstart = 0x7000214, datagramsize = 13
*Jul  5 00:21:03.535: FR encap = 0xFCF10309
*Jul  5 00:21:03.535: 00 75 01 01 01 03 02 02 01
*Jul  5 00:21:03.535:
*Jul  5 00:21:03.539: Serial4/2(in): Status, myseq 2
*Jul  5 00:21:03.539: RT IE 1, length 1, type 0
*Jul  5 00:21:03.539: KA IE 3, length 2, yourseq 2 , myseq 2
*Jul  5 00:21:03.539: PVC IE 0x7 , length 0x6 , dlci 100, status 0x2 , bw 0
*Jul  5 00:21:03.543: Serial4/2(o): dlci 100(0x1841), pkt encaps 0x0300 0x8000 0x0000
   0x806 (ARP), datagramsize 34
*Jul  5 00:21:03.543: FR: Sending INARP Request on interface Serial4/2 dlci 100 for link 7(IP)

After the router has determined the supported LMI type to use via the LMI autosense feature, the show frame-relay lmi privileged EXEC mode command can be used to verify the LMI type used. Example 4-8 shows an output of the show frame-relay lmi command.

Example 4-8. Sample Output of show frame-relay lmi Command
R1#show frame-relay lmi

LMI Statistics for interface Serial4/2 (Frame Relay DTE) LMI TYPE = CISCO
  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
  Num Status Enq. Sent 144              Num Status msgs Rcvd 145
  Num Update Status Rcvd 0              Num Status Timeouts 0

LMI autosense on the interface can be turned off by explicitly configuring an LMI type with the frame-relay lmi-type lmi-type interface configuration command. Disabling LMI autosense permits the user to specifically configure either the ANSI Annex D, the ITU Q933-A, or the Cisco LMI type to be used on an interface.

NOTE

Unlike Frame Relay encapsulation, LMI type cannot be configured on a per-DLCI basis. It has to be configured at the interface level.

When manually configuring the LMI type on the Frame Relay interface, the selected LMI type on the router must match the LMI type supported by the connected Frame Relay switch. If there is a mismatch of the LMI type running on the Cisco router and its connected Frame Relay switch, the router will not be able to discover any assigned Frame Relay PVCs or maintain LMI status with the switch.

Furthermore, individual Frame Relay PVCs configured under the same physical interface or subinterfaces cannot be set up to use a different LMI type. LMI type is configured only at the interface level. However, it is possible to allow individual Frame Relay PVCs under the same physical interface to use different Frame Relay encapsulations. The frame-relay map command allows the selected DLCI to use either Cisco or IETF Frame Relay encapsulation. The Frame Relay encapsulation type configured on the near-end Frame Relay device must match the Frame Relay encapsulation type configured on the far-end Frame Relay device. Table 4-1 summarizes the key points on the consistency of LMI and Frame Relay encapsulation types.

Table 4-1. Matching Frame Relay Encapsulation and LMI Type

Must Match Between

Configurable on Per-Interface Basis?

Configurable on Per-DLCI Basis?

Frame Relay Encapsulation Type

End-to-end Frame Relay devices

Yes

Yes

Frame Relay LMI Type

Frame Relay device and connected Frame Relay switch

Yes

No

Example 4-9 shows a configuration example of the frame-relay lmi-type interface configuration command, which is used to explicitly configure an LMI type on a Frame Relay interface. Three LMI options are available: ansi, Cisco, and q933a. They represent the ANSI Annex D, Cisco, and ITU Q933-A (Annex A) LMI types, respectively. The no form of the frame-relay lmi-type command removes the explicit LMI type configured on the interface. Take note that after the explicit LMI type configuration is removed from an interface, the LMI autosense feature is used again for LMI type discovery on that interface. In an all-Cisco environment, the recommended LMI type to use is Cisco LMI.

Example 4-9. Configuring the LMI Type on the Interface
R1(config)#interface serial4/2
R1(config-if)#frame-relay lmi-type ?
  cisco
  ansi
  q933a

R1(config-if)#frame-relay lmi-type q933a
R1(config-if)#no shutdown

After router R1 is set up to use Q933-A LMI type on its serial interface 4/2 in Example 4-9, the next example, in Example 4-10, shows that R1 no longer sends out all three LMI status enquiry messages to poll for a supported LMI type on that interface. Instead, R1 starts exchanging status enquiry messages directly with the Frame Relay switch using the selected Q933-A LMI. In the debug output in Example 4-10, R1 sends out a lone status enquiry message to the Frame Relay switch as noted by the single StEng message. The Frame Relay switch acknowledges the enquiry with a status update message.

Example 4-10. Router Begins LMI Status Exchanges Directly with the Explicitly Configured LMI Type
R1#debug frame-relay lmi
*Jul  5 01:08:28.279: Serial4/2(out): StEnq, myseq 1, yourseen 0, DTE up
*Jul  5 01:08:28.279: datagramstart = 0x70000D4, datagramsize = 13
*Jul  5 01:08:28.279: FR encap = 0x00010308
*Jul  5 01:08:28.279: 00 75 51 01 00 53 02 01 00
*Jul  5 01:08:28.279:
*Jul  5 01:08:28.283: Serial4/2(in): Status, myseq 1
*Jul  5 01:08:28.283: RT IE 51, length 1, type 0
*Jul  5 01:08:28.283: KA IE 53, length 2, yourseq 1 , myseq 1
*Jul  5 01:08:28.283: PVC IE 0x57, length 0x3 , dlci 102, status 0x2
*Jul  5 01:08:38.279: Serial4/2(out): StEnq, myseq 2, yourseen 1, DTE up
*Jul  5 01:08:38.279: datagramstart = 0x70000D4, datagramsize = 13
*Jul  5 01:08:38.279: FR encap = 0x00010308
*Jul  5 01:08:38.279: 00 75 51 01 01 53 02 02 01
*Jul  5 01:08:38.279:
*Jul  5 01:08:38.283: Serial4/2(in): Status, myseq 2
*Jul  5 01:08:38.283: RT IE 51, length 1, type 1
*Jul  5 01:08:38.283: KA IE 53, length 2, yourseq 2 , myseq 2

When manually setting up the LMI type, it is necessary to configure the keepalive interval on the Frame Relay interface to prevent LMI status exchanges between the router and the Frame Relay switch from timing out. The LMI status exchange messages are used for the purpose of communication between the router and the switch to determine the status of the PVC connection. For example, a large mismatch in the keepalive interval on the router and the switch can cause the switch to declare the router dead.

By default, the keepalive time interval is 10 seconds on Cisco serial interfaces. The keepalive interval can be changed with the keepalive interface configuration command. Refer to Example 4-11 for an example of configuring the keepalive on the interface.

Example 4-11. Configuring the Keepalive on the Interface
Enter configuration commands, one per line.  End with CNTL/Z.
R1(config)#interface serial4/2
R1(config-if)#keepalive 30

To keep the LMI status exchanges between the router and the switch in synchronization, the keepalive interval configured at the router has to be equal to or lower than the corresponding keepalive interval configured on the switch interface. Failure to do so can result in a mismatch of sequence numbers in the status exchange messages, interface flapping, or even dropped connections. Then, when connecting to a public Frame Relay network and the LMI autosense feature is not supported, explicit configuration of the LMI type on the router interface is required.

Consider the following example to illustrate this issue. After the Frame Relay PVC connection becomes active, the keepalive interval of the Frame Relay router R1's interface is readjusted to a value three times higher than the default 10-second interval used by the Frame Relay switch's interfaces. Hence, keepalive 30 is used to increase the keepalive of router R1's interface to 30 seconds, while the keepalive value on the switch interface remains at the default 10 seconds. As a result of the configuration change, the Frame Relay switch interface continues to expect LMI status messages from router R1 at 10-second intervals but it hears an LMI status message from R1 only after every 30 seconds. This keepalive mismatch causes a timeout on the switch, and the Frame Relay switch declares the PVC connection to the router R1 as inactive. This can be observed in the output of the show frame-relay route command depicted in Example 4-12. On the router, it is not possible to reach its remote destination on the inactive Frame Relay PVC.

Example 4-12. Frame Relay Connection Status on the Frame Relay Switch with Mismatch Keepalive Intervals Between the Switch and R1
SW#show frame-relay route
Input Intf      Input Dlci      Output Intf     Output Dlci     Status
Serial1/0       102             Serial1/1       201             active
Serial1/1       201             Serial1/0       102             inactive

On the Frame Relay switch, the hardware interface connected to R1 transitions to the line protocol is down state because of the keepalive mismatch. The output of the show interface command executed on the Frame Relay switch in Example 4-13 reflects this.

Example 4-13. Mismatch Keepalive on R1 Causes an Interface Flap on the Frame Relay Switch
SW#show interface serial1/0
Serial1/0 is up, line protocol is down
  Hardware is cxBus Serial
  MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec,
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation FRAME-RELAY, crc 16, loopback not set
  Keepalive set (10 sec)
  Restart-Delay is 0 secs
  LMI enq sent  0, LMI stat recvd 0, LMI upd recvd 0
  LMI enq recvd 65, LMI stat sent  65, LMI upd sent  0, DCE LMI down
  LMI DLCI 1023  LMI type is CISCO  frame relay DCE
  Broadcast queue 0/64, broadcasts sent/dropped 0/0, interface broadcasts 0
  Last input 00:00:00, output 00:00:00, output hang never
  Last clearing of "show interface" counters 00:17:56
  Input queue: 0/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/1/256 (active/max active/max total)
     Reserved Conversations 0/0 (allocated/max allocated)
     Available Bandwidth 1158 kilobits/sec
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
     73 packets input, 1426 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
     71 packets output, 1503 bytes, 0 underruns
     0 output errors, 0 collisions, 1 interface resets
     0 output buffer failures, 0 output buffers swapped out
     1 carrier transitions
     RTS up, CTS up, DTR up, DCD up, DSR up

In Example 4-14, a standard ping is performed at Router R1, targeted to the destination address 172.16.1.2 at Router R2. As expected, with the Frame Relay PVC in the inactive state, all the packets sent out on DLCI 100 are dropped. The cause of this problem is the mismatch of the keepalive intervals for exchanging LMI updates between the router and the Frame Relay switch interface. This problem can be identified with the use of show and debug commands for Frame Relay verifying LMI, which will be introduced and explained subsequently in this chapter.

Example 4-14. Frame Relay Router's Connectivity to Remote Destination Is Lost After Keepalive Mismatch
R1#show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
       i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
       * - candidate default, U - per-user static route, o - ODR
       P - periodic downloaded static route

Gateway of last resort is not set

     172.16.0.0/24 is subnetted, 1 subnets
C       172.16.1.0 is directly connected, Serial4/2
R1#ping 172.16.1.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.1.2, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)

After the keepalive interval at Router R1's serial interface 4/2 is restored to 10 seconds to match the Frame Relay switch's settings, the LMI status messages are exchanged properly between R1 and the Frame Relay switch. The LMI status on R1 goes to the UP state and the PVC connection is in the active state again on the switch. Router R1 is able to ping router R2's address at 172.16.1.2, as shown in Example 4-15.

Example 4-15. Connectivity Is Restored After Correcting the Keepalive Interval Mismatch
R1#show interface serial 4/2
Serial4/2 is up, line protocol is up
  Hardware is M4T
  Internet address is 172.16.1.1/24
  MTU 1500 bytes, BW 2048 Kbit, DLY 20000 usec,
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation FRAME-RELAY, crc 16, loopback not set
  Keepalive set (10 sec)
  LMI enq sent  94, LMI stat recvd 91, 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 CCITT  frame relay DTE
  FR SVC disabled, LAPF state down
  Broadcast queue 0/64, broadcasts sent/dropped 1/0, interface broadcasts 0
  Last input 00:00:06, output 00:00:06, output hang never
  Last clearing of "show interface" counters 00:27:06
  Input queue: 0/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/1/256 (active/max active/max total)
     Reserved Conversations 0/0 (allocated/max allocated)
     Available Bandwidth 1536 kilobits/sec
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
     108 packets input, 2901 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
     128 packets output, 4276 bytes, 0 underruns
     0 output errors, 0 collisions, 1 interface resets
     0 output buffer failures, 0 output buffers swapped out
1 carrier transitions     DCD=up  DSR=up  DTR=up  RTS=up CTS=up
R1#ping 172.16.1.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.1.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 56/57/60 ms

The discussion in this section demonstrates that a successful LMI status exchange between a Frame Relay DTE device (router) and a Frame Relay DCE device (Frame Relay switch) is required for communication and maintenance of the Frame Relay PVC status. A router cannot communicate with a Frame Relay network via a Frame Relay PVC in the inactive state. However, in order for the router to really send information to a remote destination network address, it needs to know which DLCI to use. This is accomplished by mapping a remote destination network address to a local DLCI address and is explained in the next section.


Configuring Static and Dynamic DLCI to Network Layer Address Mapping

Before a Frame Relay router or access server can transmit frames on its outgoing virtual circuit to a remote destination, it needs a vital piece of information. The router needs to understand the relationship between the specified next hop protocol address of the remote destination and the specific DLCI of a local outgoing virtual circuit. In other words, before a Cisco router is able to transmit data to a remote destination over Frame Relay, it needs to know which DLCI to use. Cisco routers support all network layer protocols over Frame Relay, such as IP, IPX, and AppleTalk. This address-to-DLCI mapping can be accomplished either by static or dynamic mapping. Dynamic and static mapping of the next hop protocol address to a specific local DLCI value is explained in this section.

Dynamic Mapping

Dynamic address mapping relies on the Frame Relay Inverse Address Resolution Protocol (Inverse ARP), defined by RFC 1293, to resolve a next hop network protocol address to a local DLCI value. The Frame Relay router sends out Inverse ARP requests on its Frame Relay PVC to discover the protocol address of the remote device connected to the Frame Relay network. The responses to the Inverse ARP requests are used to populate an address-to-DLCI mapping table on the Frame Relay router or access server. The router builds and maintains this address-to-DLCI mapping table, which contains all resolved Inverse ARP requests, including both dynamic and static mapping entries.

When data needs to be transmitted to a remote destination address, the router performs a lookup on its routing table to determine whether a route to that destination address exists and the next hop address or directly connected interface to use in order to reach that destination. Subsequently, the router consults its address-to-DLCI mapping table for the local DLCI that corresponds to the next hop address. Finally, the router places the frames targeted to the remote destination on its identified outgoing local DLCI.

On Cisco routers, dynamic Inverse ARP is enabled by default for all network layer protocols enabled on the physical interface. Packets are not sent out for network layer protocols that are not enabled on the physical interface. For example, no dynamic Inverse ARP resolution is performed for IPX if ipx routing is not enabled globally and there is no active IPX address assigned to the interface. Because dynamic Inverse ARP is enabled by default, no additional Cisco IOS command is required to enable it on an interface.

Example 4-16 shows the output of the show frame-relay map privileged EXEC mode command. The address-to-DLCI mapping table displays useful information. The output of the command shows that the next hop address 172.16.1.2 is dynamically mapped to the local DLCI 102, broadcast is enabled on the interface, and the interface's status is currently active.

NOTE

After enabling Frame Relay on the interface, the Cisco router does not perform Inverse ARP until IP routing is enabled on the router. By default, IP routing is enabled on a Cisco router. If IP routing has been turned off, enable IP routing with the ip routing command in the global configuration mode. After IP routing is enabled, the router performs Inverse ARP and begins populating the address-to-DLCI mapping table with resolved entries.

Example 4-16. Example of Dynamic Mapping
R1#show frame-relay map
Serial4/2 (up): ip 172.16.1.2 dlci 102(0x64,0x1840), dynamic,
              broadcast,, status defined, active

Inverse ARP can be disabled explicitly for a specific protocol and DLCI pair on the interface. Inverse ARP should be disabled for a specific protocol when it is known that the protocol is not supported on the remote end of the connection. Inverse ARP is disabled using the no form of the frame-relay inverse-arp interface configuration command. Example 4-17 shows how the no frame-relay inverse-arp configuration command is performed to disable dynamic Inverse ARP on the serial interface 4/2 on Router R1.

Example 4-17. Disabling Inverse ARP on an Interface
R1(config)#interface serial4/2
R1(config-if)#no frame-relay inverse-arp ?
  <cr>
  apollo     Apollo Domain
  appletalk  AppleTalk
  bridge     Bridging
  decnet     DECnet
  interval   Set inarp time interval on an interface
  ip         IP
  ipx        Novell IPX
  pppoe      PPP over Ethernet
  qllc       qllc protocol
  vines      Banyan VINES
  xns        Xerox Network Services
R1(config-if)#no frame-relay inverse-arp ip ?
  <16-1007>  Set DLCI for inverse ARP

R1(config-if)#no frame-relay inverse-arp ip 102

To enable Frame Relay Inverse ARP on a specified interface or subinterface if Inverse ARP has been previously disabled, use the frame-relay inverse-arp interface configuration command on the specified interface.

Suppose that the conditions of the network change, resulting in reassignment of DLCI or protocol layer addresses. The clear frame-relay inarp privileged EXEC mode command can be used to clear the address-to-DLCI mapping table of obsolete entries. This clear command flushes the dynamic mapping entries in the table and forces the router to resend dynamic Inverse ARP requests to its neighbors. The clear frame-relay inarp command clears all dynamic Inverse ARP entries on the router. Optionally, the granular clear frame-relay inarp interface command can be used to clear a group of dynamic mapping entries based on the interface number. The clear frame-relay inarp interface type/num dlci dlci_number clears the dynamic mapping entries associated with a specific DLCI.

Cisco routers also allow users to populate the Frame Relay map table with manually defined Inverse ARP entries. User-created Inverse ARP mapping is also known as static mapping. Static mapping is explained in the next section.

NOTE

The clear frame-relay inarp command flushes dynamic Inverse ARP mappings. It does not, however, flush static mapping entries in the table manually created by the user.

Static Mapping

With static mapping, the user can choose to override dynamic Inverse ARP mapping by supplying a manual static mapping for the next hop protocol address to a local DLCI. A static map works similarly to dynamic Inverse ARP by associating a specified next hop protocol address to a local Frame Relay DLCI.

For example, static address mapping should be used in situations when the router at the other side of the Frame Relay network does not support dynamic Inverse ARP for a specific network protocol. To provide accessibility, a static mapping is required to complete the remote network layer address to local DLCI resolution.

On a hub-and-spoke Frame Relay network, static address mapping should also be used on the spoke routers to provide spoke-to-spoke reachability. Because the spoke routers do not have direct connectivity with each other, dynamic Inverse ARP would not work between them. Dynamic Inverse ARP relies on the presence of a direct point-to-point connection between two ends. In this case, dynamic Inverse ARP only works between hub and spoke, and the spokes require static mapping to provide reachability to each other.

NOTE

When static mapping is configured on an interface for a protocol and a specific DLCI, the router automatically disables dynamic Inverse ARP for the protocol and the specific DLCI on the interface.

The frame-relay map protocol protocol-address dlci [broadcast] [ietf | cisco] configuration command in the interface or multipoint subinterface configuration mode is used to supply a static mapping of the specified next hop protocol address to a specified local DLCI.

Physical interface:

Router(config-if)#frame-relay map protocol protocol-address dlci [broadcast] [ietf | cisco]

Multipoint subinterface:

Router(config-subif)#frame-relay map protocol protocol-address dlci [broadcast] [ietf | cisco]

The no form of the frame-relay map command removes the static mapping for the specific next hop protocol address and the specific local DLCI. Table 4-2 lists the supported protocols and the corresponding keywords for protocol in the frame-relay map command.

Table 4-2. Supported Protocols and Keywords for frame-relay map Command

Supported Protocols for frame-relay map Command

Keyword for protocol

IP

ip

DECnet

decent

AppleTalk

appletalk

XNS

xns

Novell IPX

ipx

VINES

vines

ISO CLNS

clns

NOTE

A Frame Relay point-to-point subinterface is connected to an end-to-end virtual circuit provisioned between two locations. Therefore, a point-to-point subinterface can only accept one DLCI and the next hop protocol address is automatically linked to the sole outgoing local DLCI. Hence, the frame-relay map command is applicable only to multipoint subinterfaces and physical interfaces (physical interfaces are multipoint interfaces by default).

To configure a static mapping of the next hop protocol address to a specified DLCI on a physical interface or a multipoint subinterface, follow the configuration steps listed below:

Step 1. | Go into the interface or subinterface configuration mode of the interface on which you want to configuring static mapping.
Step 2. | Configure the Frame Relay static mapping for the specified next hop protocol address and the specified local DLCI.
Step 3. | (optional) Enter the broadcast keyword to allow the specified DLCI to forward broadcast and multicast packets. This can reduce the complexity of running dynamic routing protocols such as OSPF (which uses multicast updates) over Frame Relay.
Step 4. | (optional) Use the cisco or ietf keyword to specify the Frame Relay encapsulation to be used on the specified DLCI. Frame Relay encapsulation can be configured on a per-DLCI basis.

Example 4-18 shows a sample configuration of static mapping configured on the physical serial interface 3/0 of Router R2.

Example 4-18. Configuring Static Mapping
R2#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
R2(config)#interface serial3/0
R2(config-if)#frame-relay map ip 172.16.1.1 201 broadcast cisco

R2#show running-config
<output omitted>

interface Serial3/0
 ip address 172.16.1.2 255.255.255.0
 encapsulation frame-relay
frame-relay map ip 172.16.1.1 201 broadcast cisco

<output omitted>

R2#show frame-relay map
Serial3/0 (up): ip 172.16.1.1 dlci 201(0xC8,0x3080), static,
              broadcast,
              CISCO, status defined, active

Referring to Example 4-18, the contents of the show output on router R2 indicate that the static address mapping is performed on interface serial 3/0 and the Frame Relay encapsulation used on the DLCI 200 is CISCO. As seen in the configuration steps, static mapping of the address using the frame-relay map command allows users to select the type of Frame Relay encapsulation used on a per-VC basis.

It was mentioned in an earlier section that static mapping using the frame-relay map command is important on partially meshed networks. The partially meshed Frame Relay network shown in Figure 4-2 is used to demonstrate when static mapping is required. In Figure 4-2, the spoke routers, R1 and R2, are using dynamic Inverse ARP between themselves and the hub router R3. Static mapping is used between a spoke router and its remote spoke router.

Figure 4-2. Using Static Mappings on a Partially Meshed Network

For example, the spoke router R1 uses static mapping to reach router R2 at 172.16.1.2 because there is no direct connectivity between them on the partially meshed network to use dynamic Inverse ARP. Because R1 and R3 are directly connected by a VC, they can rely on dynamic mapping to resolve the next hop protocol address via dynamic Inverse ARP. The same applies between router R2 and hub router R3. On router R1 and R2, static mapping needs to be used to instruct R1 to reach R2 via its local DLCI 103 and for R2 to reach R1 via its local DLCI 203.

The configuration file and the show frame-relay map command output of router R2 are shown in Example 4-19. After the static and dynamic mappings are resolved in the show frame-relay map table, R2 has complete connectivity to both the hub router and the remote spoke router. The configurations and the show frame-relay map output of router R1 will be similar to that of router R2.

Example 4-19. Static and Dynamic Mapping Under the Same Interface
R2#show running-config
Building configuration...
<output omitted>

interface Serial3/0
 ip address 172.16.1.2 255.255.255.0
 encapsulation frame-relay
 frame-relay map ip 172.16.1.1 203 broadcast

<output omitted>

R2#show frame-relay map
Serial3/0 (up): ip 172.16.1.3 dlci 203(0x64,0x1840), dynamic,
              broadcast,, status defined, active
Serial3/0 (up): ip 172.16.1.1 dlci 203(0x64,0x1840), static,
              broadcast,
CISCO, status defined, active

R2#ping 172.16.1.3

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.1.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 56/57/60 ms
R2#ping 172.16.1.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 112/114/120 ms
R2#

Although using a combination of both static mapping and dynamic Inverse ARP on a spoke router resolves the spoke-to-spoke reachability problem inherent in a hub-and-spoke Frame Relay network, another issue is presented. Recall that when static mapping is enabled for a particular network layer protocol on a specific DLCI, dynamic Inverse ARP for that network layer protocol on the same DLCI is automatically disabled on the interface. On router R2 in Figure 4-2, both static mapping and dynamic Inverse ARP are configured for IP on DLCI 200. This works fine if static mapping is added after dynamic Inverse ARP resolution has been completed. However, when router R2 is rebooted with the saved configurations, dynamic Inverse ARP will be turned off on interface serial3/0. In this case, router R2 will no longer be able to reach the hub router R3. A workable solution to this issue is to use static mapping instead for all remote destinations.


Configuring Frame Relay Subinterfaces

On partially meshed Frame Relay networks, the problem of split horizon can be overcome by using Frame Relay subinterfaces. Frame Relay provides a mechanism to allow a physical interface to be partitioned into multiple virtual interfaces. In a similar way, using subinterfaces allows a partially meshed network to be divided into a number of smaller, fully meshed point-to-point networks. Generally, each point-to-point subnetwork is assigned a unique network address. This allows packets received on one physical interface to be sent out from the same physical interface, albeit forwarded on VCs in different subinterfaces.

There are two types of subinterfaces supported by Cisco routers: point-to-point and multipoint subinterfaces. Each of these types will be described in the next sections.

Point-to-Point Subinterfaces

In general, to configure a subinterface on a Frame Relay interface, follow the configuration commands listed below beginning in global configuration mode:

Step 1. | Go to the interface configuration mode of the interface on which you want to create Frame Relay subinterfaces and enable Frame Relay encapsulation.
Step 2. | Configure and create a point-to-point or multipoint subinterface.

Example 4-20 shows an example of the configuration steps required to create a point-to-point subinterface. Example 4-21 shows an example of the configuration steps required to create a multipoint subinterface. Both configuration commands are performed on the hub router R3 in Figure 4-2.

Example 4-20. Creating Point-to-Point Subinterfaces on a Physical Interface
R3#configure terminal
00:41:34: %SYS-5-CONFIG_I: Configured from console by console
Enter configuration commands, one per line.  End with CNTL/Z.
R3(config)#interface serial3/1
R3(config-if)#encapsulation frame-relay
R3(config-if)#interface serial3/1.1 point-to-point
R3(config-subif)#

Example 4-21. Creating Multipoint Subinterfaces on a Physical Interface
R3(config)#
00:43:57: %SYS-5-CONFIG_I: Configured from console by console
R3(config)#interface serial3/1
R3(config-if)#encapsulation frame-relay
R3(config-if)#interface serial3/1.2 multipoint
R3(config-subif)#

NOTE

Once you create a specific type of subinterface, you cannot change it without reloading the router. For example, you cannot create a multipoint subinterface serial0.2 and then change it to point-to-point. To change it, you need to either reload the router or create another subinterface. This is the way the Frame Relay code works in Cisco IOS software.

An example is used to illustrate how multiple subinterfaces can be created under the same physical interface. A fourth router, R4, is added to Figure 4-2. The resultant topology is shown in Figure 4-3.

Figure 4-3. Frame Relay Network Using Subinterfaces

At the hub router R3, two subinterfaces are created on the physical serial interface 3/1. One multipoint subinterface is created, and an IP address for the 172.16.1.0/29 subnet is assigned. Under the same physical serial interface 3/1, another point-to-point subinterface can be created for the point-to-point connection to spoke router R4 for the IP subnet 192.168.1.0/30. Example 4-22 shows the configuration files of all four routers shown in Figure 4-3.

Example 4-22. Configuration Files of Routers in Figure 4-3
R1#show running-config
Building configuration...
!
hostname R1
!
<output omitted>
!
interface Serial4/2
 ip address 172.16.1.1 255.255.255.248
 encapsulation frame-relay
 frame-relay map ip 172.16.1.2 103 broadcast

R2#show running-config
Building configuration...
!
hostname R2
!
<output omitted>
!
interface Serial3/0
 ip address 172.16.1.2 255.255.255.248
 encapsulation frame-relay
frame-relay map ip 172.16.1.1 203 broadcast
!
<output omitted>

R3#show running-config
Building configuration...
!
hostname R3
!
<output omitted>
!
interface Serial3/1
 no ip address
 encapsulation frame-relay
!
interface Serial3/1.304 point-to-point
 ip address 192.168.1.1 255.255.255.252
 frame-relay interface-dlci 304
!
interface Serial3/1.301 multipoint
 ip address 172.16.1.3 255.255.255.248
 frame-relay interface-dlci 301
 frame-relay interface-dlci 302

R4#show running-config
Building configuration...
!
hostname R4
!
<output omitted>
!
interface Serial1/2
 no ip address
 encapsulation frame-relay
!
interface Serial1/2.403 point-to-point
 ip address 192.168.1.2 255.255.255.252
 frame-relay interface-dlci 403
!


Using Frame Relay Point-to-Point Subinterfaces

On Frame Relay networks, a single VC is always provisioned for a point-to-point connection. The same VC originates at a local end and then terminates at the remote end. A subnet address is usually assigned to each point-to-point connection. Therefore, only one DLCI can be configured per point-to-point subinterface. In this example, the local referenced DLCI of the VC at hub router R3 and spoke router R4 are 304 and 403, respectively. The subnet address 192.168.1.0/30 is allocated to this point-to-point network. Typically, a 30-bit subnet mask is used for point-to-point connection to preserve address space.

On point-to-point subinterfaces, the destination is identified and configured with the frame-relay interface-dlci command beginning in interface configuration mode. When configured on a point-to-point subinterface, the command associates the selected point-to-point subinterface with a DLCI. The command also allows users to select the type of Frame Relay encapsulation to be used on the specific VC. The command can be executed without specifying the Frame Relay encapsulation type to be used. By default, the Cisco Frame Relay encapsulation type will be used. Example 4-23 shows the configuration command and the corresponding output of the show frame-relay map.

Example 4-23. Example of frame-relay interface-dlci Command and the Output of show frame-relay map
R4(config)#interface s1/2.403 point-to-point
R4(config-subif)#frame-relay interface-dlci ?
  <16-1007>  Define a switched or locally terminated DLCI

R4(config-subif)#frame-relay interface-dlci 403 ?
  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
<cr>
R4#show frame-relay map
Serial1/2.403 (up): point-to-point dlci, dlci 403(0xC9,0x3090), broadcast
          status defined, active
R4#

As shown in the show frame-relay map output in Example 4-23, the DLCI configured on point-to-point subinterface serial1/0.403 is 403. Note that the created subinterface number mirrors the DLCI of the referenced VC. Generally, when creating a Frame Relay subinterface, it is good practice to assign a Frame Relay subinterface number that mirrors the DLCI value of the Frame Relay PVC assigned to that subinterface.

On point-to-point subinterfaces, you do not need to use the frame-relay map command to perform static address mapping, because it is always assumed that the end point of the point-to-point connection automatically resides on the same subnet as the start point. It is also not required to enable or disable Inverse ARP, because there is only a single remote destination on a point-to-point PVC and discovery is not necessary.

Using Frame Relay Multipoint Subinterfaces

On a Cisco router, by default, physical interfaces are multipoint interfaces. Frame Relay multipoint subinterfaces created on Cisco routers behave very much like the physical interfaces.

When a multipoint subinterface is created under a physical interface, it is necessary to specifically assign DLCIs to the multipoint subinterface. By default, the Cisco IOS software allocates all unassigned DLCIs advertised by the Frame Relay switch to the physical interface on the router. On a multipoint subinterface, the frame-relay interface-dlci dlci command or the frame-relay map protocol protocol-address dlci [broadcast] command in the subinterface configuration mode can be used to associate the multipoint subinterface with specific DLCIs. The frame-relay interface-dlci dlci command performs dynamic address mapping using Inverse ARP to map the next-hop protocol address to the local DLCI on the router. For instance, in the configuration examples in Example 4-22, DLCIs 301, 302, and 304 are automatically associated with the physical interface serial 3/1 on the hub router R3. The frame-relay interface-dlci 301 and frame-relay interface-dlci 302 commands are configured on multipoint subinterface s3/1.301 to specifically assign both DLCIs to the multipoint subinterface. The same command is used to associate DLCI 304 with point-to-point subinterface s3/1.304. Unlike point-to-point subinterfaces, the frame-relay interface-dlci command can be configured multiple times to associate more than one DLCI to a multipoint subinterface.

Similarly, the frame-relay map protocol protocol-address dlci [broadcast] command can be used to specifically assign DLCIs to the multipoint subinterfaces. The optional broadcast keyword in the frame-relay map command is required if broadcast and multicast traffic are to be sent over the specified dlci. Without the broadcast option, dynamic routing protocols such as EIGRP, OSPF and RIPv2 would not be able to advertise multicast route updates over the specified dlci. In comparison with the frame-relay interface-dlci command, the frame-relay map command performs static addressing mapping and it disables Inverse ARP on the specified dlci. In addition, the frame-relay map command is supported on the physical interface and the frame-relay map command should be used when the far end Frame Relay device does not support Inverse ARP.

NOTE

When a multipoint subinterface is created on a physical interface, the DLCIs of virtual circuits are always assigned to the physical interface until they are specifically assigned to the subinterfaces using the frame-relay interface-dlci dlci command or the frame-relay map protocol protocol-address dlci [broadcast] command.

On multipoint subinterfaces, either dynamic or static mapping can be used, depending on the network configurations.

In the hub-and-spoke network exemplified in Figure 4-3, the hub router R3 uses dynamic mapping via inverse ARP to map the next hop protocol addresses 172.16.1.1/29 and 172.16.1.2/29 of routers R1 and R2 to DLCI 301 and 302, respectively. On the spoke router R1, dynamic Inverse ARP mapping is used to map the next hop protocol address 172.16.1.3/29 at router R3 to local DLCI 301. However, because the spoke routers R1 and R2 do not have direct connectivity with each other on the partially meshed network, static mapping must be used between them. For each additional spoke router added to the 172.16.1.0/29 subnet on the hub-and-spoke network in Figure 4-3, an additional frame-relay map command must be supplied on each spoke router to statically map the next hop protocol address to the local DLCI.

The following example verifies the configurations of the routers in the hub-and-spoke network depicted in Figure 4-3. Example 4-24 shows the output of the show frame-relay map command on the hub router R3 and the results of several connectivity checks via the ping command.

Example 4-24. Verifying the Network in Figure 4-3
R3#show frame-relay map
Serial3/1.301 (up): ip 172.16.1.1 dlci 301(0x67,0x1870), dynamic,
              broadcast,, status defined, active
Serial3/1.302 (up): ip 172.16.1.2 dlci 302(0x68,0x1880), dynamic,
              broadcast,, status defined, active
Serial3/1.304 (up): point-to-point dlci, dlci 304(0x66,0x1860), broadcast
          status defined, active
R3#
R3#ping 172.16.1.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 56/57/60 ms
R3#ping 172.16.1.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.1.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 56/56/60 ms
R3#ping 192.168.1.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 56/57/60 ms
R3#

R1#show frame-relay map
Serial4/2 (up): ip 172.16.1.2 dlci 103(0x191,0x6410), static,
              broadcast,
              CISCO, status defined, active
Serial4/2 (up): ip 172.16.1.3 dlci 103(0x191,0x6410), dynamic,
broadcast,, status defined, active
R1#ping 172.16.1.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.1.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 112/115/120 ms
R1#ping 172.16.1.3

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.1.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 56/59/64 ms

R2#show frame-relay map
Serial3/0 (up): ip 172.16.1.1 dlci 203(0x12D,0x48D0), static,
              broadcast,
              CISCO, status defined, active
Serial3/0 (up): ip 172.16.1.3 dlci 203(0x12D,0x48D0), dynamic,
broadcast,, status defined, active
R2#ping 172.16.1.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 112/115/124 ms
R2#ping 172.16.1.3

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.1.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 56/57/60 ms
R2#

R4#show frame-relay map
Serial1/2.403 (up): point-to-point dlci, dlci 403(0xC9,0x3090), broadcast
          status defined, active
R4#ping 192.168.1.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 56/57/60 ms
R4#


Configuring a Cisco Router as a Frame Relay Switch

Cisco routers can be configured as dedicated Frame Relay switches that act as DCE devices. On a Cisco router configured as a Frame Relay switch, frames from a Frame Relay PVC arriving on an incoming interface are switched to a Frame Relay PVC on outgoing interface During this process, the incoming DLCI in the arriving frames is replaced by an outgoing DLCI. Frame Relay switching is performed completely in Layer 2, and the Frame Relay switch pays no attention to Layer 3 information contained within the frames. The paths taken by the switched frames are completely based on the Frame Relay route table constructed.

We use a simple example depicted in Figure 4-4 with two Frame Relay access routers and a Cisco router configured as a Frame Relay switch.

Figure 4-4. Frame Relay Switching Using a Cisco Router

The simple Frame Relay network in Figure 4-4 shows a Cisco router configured as a Frame Relay switch with two serial interfaces set up as DCE interfaces. The Cisco router behaving as a Frame Relay switch switches Frame Relay frames received from interface serial4/3 on DLCI 403 to interface serial4/1 on the outgoing DLCI to 304. Example 4-25 shows the sample configurations for the router configured as a Frame Relay switch.

Example 4-25. Configurations for Frame Relay Switch
SW#show running-config
Building configuration...
<output omitted>
!
hostname SW
!
<output omitted>
!
frame-relay switching
!
interface Serial4/1
 no ip address
 encapsulation frame-relay
 clockrate 64000
 frame-relay intf-type dce
 frame-relay route 304 interface Serial4/3 403
!
interface Serial4/3
 no ip address
 encapsulation frame-relay
 clockrate 64000
 frame-relay intf-type dce
 frame-relay route 403 interface Serial4/1 304

To configure a Cisco router as a Frame Relay switch, follow the configuration steps listed below:

Step 1. | Enable Frame Relay switching on the router using the command frame-relay switching in the global configuration mode.
Step 2. | Go to the interface configuration mode of the Frame Relay interface where you want to configure Frame Relay switching. Configure the interface as a DCE interface with the frame-relay intf-type dce interface configuration command.
Step 3. | Configure the Frame Relay switching on the interface using the frame-relay route command, specifying the incoming DLCI, the outgoing interface, and the outgoing DLCI. Note that Frame Relay switching can be configured only on physical interfaces.
Step 4. | The clockrate command is required on the serial interface of the Frame Relay switch (attached with the DCE end of the serial cable). It provides clocking signals to the connected Frame Relay routers, which are set up as DTE devices.

The frame-relay route interface configuration command is used to route an incoming DLCI to an outgoing interface and corresponding outgoing DLCI.

Router(config-if)#frame-relay route incoming-DLCI outgoing-interface outgoing DLCI

To verify the contents of the Frame Relay route table, the show frame-relay route privileged EXEC mode command is used. Example 4-26 shows the contents of the table displayed by the show frame-relay route command.

Example 4-26. Contents of show frame-relay route Command
SW#show frame-relay route
Input Intf      Input Dlci      Output Intf     Output Dlci   Status
Serial4/1       304             Serial4/3       403           active
Serial4/3       403             Serial4/1       304           active
SW#

NOTE

Take note that the frame-relay route command must be configured in pairs on both the incoming interface and outgoing interface for the Frame Relay route to become active.

The Cisco Frame Relay switching feature can be used to support a Frame Relay network using only routers. Consider the example in Figure 4-5 in which two Cisco routers are configured as Frame Relay switches implementing a Network-to-Network Interface (NNI) between them. To enable communication between two Frame Relay switches, the NNI signaling protocol is used between them. Configuration examples involving two Frame Relay switches communicating in NNI mode are shown in Example 4-27.

Example 4-27. Configurations for the Frame Relay Switches
SW#show running-config
Building configuration...
<output omitted>
!
hostname SW
!
<output omitted>
!
frame-relay switching
!
interface Serial2/1
 no ip address
 encapsulation frame-relay
 clockrate 64000
 frame-relay intf-type dce
 frame-relay route 100 interface Serial2/3 300
!
interface Serial2/3
 no ip address
 encapsulation frame-relay
 clockrate 64000
 frame-relay intf-type nni
 frame-relay route 300 interface Serial2/1 100

SW2#show running-config
Building configuration...
<output omitted>
!
hostname SW2
!
<output omitted>
!
frame-relay switching
!
interface Serial3/1
 no ip address
 encapsulation frame-relay
 clockrate 64000
 frame-relay intf-type dce
 frame-relay route 200 interface Serial3/3 300
!
interface Serial3/3
 no ip address
 encapsulation frame-relay
 clockrate 64000
 frame-relay intf-type nni
 frame-relay route 300 interface Serial3/1 200

Figure 4-5. Two Frame Relay Switches Communicating with NNI Interface

Previous Page
Next Page


Local Significance Approach to DLCI Assignment

Earlier chapters discussed the concept of DLCI local significance. In the context of local significance on a Frame Relay network, the end devices at two different ends of a connection can use a different DLCI to refer to that same connection. This section discusses setting up a Frame Relay DLCI addressing scheme using the local significance approach to DLCI assignment. Later in the section, an alternate addressing scheme using the global significance approach is examined. Global significance of DLCI is part of the LMI enhancements to Frame Relay.

Figure 4-6 shows a hub-and-spoke Frame Relay network with five nodes using a DLCI scheme that conforms to the concept of local significance.

Figure 4-6. Local Significance Addressing

The configuration files of the Frame Relay switch for the network depicted in Figure 4-6 with the local significance addressing approach are shown in Example 4-28.

Example 4-28. Configuration Files for Frame Relay Switch Using Local Significance Addressing
SW#show running-config
<output omitted>
hostname SW
!
no ip routing
!
frame-relay switching
!
interface Serial1/0
! Connection to Router Spoke A
 no ip address
 encapsulation frame-relay
 clockrate 64000
 frame-relay intf-type dce
 frame-relay route 201 interface Serial4/3 102
!
interface Serial1/1
! Connection to Router Spoke B
 no ip address
 encapsulation frame-relay
 clockrate 64000
 frame-relay intf-type dce
 frame-relay route 301 interface Serial4/3 103
!
interface Serial1/7
! Connection to Router Spoke D
 no ip address
 encapsulation frame-relay
 clockrate 64000
 frame-relay intf-type dce
 frame-relay route 501 interface Serial4/3 105
!
interface Serial4/1
! Connection to Router Spoke C
 no ip address
 encapsulation frame-relay
 clockrate 64000
 frame-relay intf-type dce
 frame-relay route 401 interface Serial4/3 104
!
interface Serial4/3
! Connection to the Hub Router
 no ip address
 encapsulation frame-relay
 clockrate 64000
 frame-relay intf-type dce
 frame-relay route 102 interface Serial1/0 201
 frame-relay route 103 interface Serial1/1 301
 frame-relay route 104 interface Serial4/1 401
 frame-relay route 105 interface Serial1/7 501

SW#show frame-relay route
Input Intf      Input Dlci      Output Intf     Output Dlci   Status
Serial1/0       201             Serial4/3       102           active
Serial1/1       301             Serial4/3       103           active
Serial1/7       501             Serial4/3       105           active
Serial4/1       401             Serial4/3       104           active
Serial4/3       102             Serial1/0       201           active
Serial4/3       103             Serial1/1       301           active
Serial4/3       104             Serial4/1       401           active
Serial4/3       105             Serial1/7       501           active
SW#

On a Frame Relay network using the global addressing approach, a unique DLCI address is assigned to each Frame Relay DTE device, including routers. The global addressing scheme allows Frame Relay devices to be uniquely identified by their assigned DLCIs. However, similar to the constraints of IP addressing, an assigned DLCI value cannot be reused in any other parts of the same Frame Relay network. In addition to this constraint, the number of Frame Relay devices that can be supported by global addressing is limited. Because global addressing requires the DLCI values to be unique, the maximum number of Frame Relay devices allowed is 992 (1024 possible DLCI values 32 reserved DLCI addresses). Figure 4-7 presents an example of a Frame Relay network utilizing the global addressing scheme.

Figure 4-7. Global Significance Addressing

The configuration files of the Frame Relay switch for the network depicted in Figure 4-7 with the global significance addressing approach are shown in Example 4-29.

Example 4-29. Configuration Files for Frame Relay Switch Using Global Significance Addressing
SW#show running-config
<output omitted>
hostname SW
!
no ip routing
!
frame-relay switching
!
interface Serial1/0
 ! Connection to Router Spoke A
 no ip address
 encapsulation frame-relay
 clockrate 64000
 frame-relay intf-type dce
 frame-relay route 101 interface Serial4/3 201
!
interface Serial1/1
 ! Connection to Router Spoke B
 no ip address
 encapsulation frame-relay
 clockrate 64000
 frame-relay intf-type dce
 frame-relay route 101 interface Serial4/3 301
!
interface Serial1/7
 ! Connection to Router Spoke D
 no ip address
 encapsulation frame-relay
 clockrate 64000
 frame-relay intf-type dce
 frame-relay route 101 interface Serial4/3 501
!
interface Serial4/1
 ! Connection to Router Spoke C
 no ip address
 encapsulation frame-relay
 clockrate 64000
 frame-relay intf-type dce
 frame-relay route 101 interface Serial4/3 401
!
interface Serial4/3
 ! Connection to the Hub Router
 no ip address
 encapsulation frame-relay
 clockrate 64000
 frame-relay intf-type dce
 frame-relay route 201 interface Serial1/0 101
 frame-relay route 301 interface Serial1/1 101
 frame-relay route 401 interface Serial4/1 101
 frame-relay route 501 interface Serial1/7 101


Verifying Frame Relay Connections with IOS show Commands

Many Cisco IOS commands that are supported on Cisco routers can be used either to validate users' Frame Relay configuration command changes, to verify the status of the Frame Relay connection, or as a troubleshooting tool. For instance, the show frame-relay map command displays the remote network address to local DLCI mapping and indicates the remote network destinations reachable via the connected Frame Relay network. This section looks at the general IOS show commands most commonly used on Cisco routers for Frame Relay.

show interface serial interface-type number

The show interface serial privileged EXEC mode command displays detailed information of a physical interface or a subinterface. The information shown by the show interface serial command offers the following information on Frame Relay:

  • The type of Frame Relay encapsulation used on an interface or PVC

  • The keepalive interval configured

  • The Frame Relay LMI type used

  • The status of Frame Relay LMI

  • Information on whether the interface is configured as a Frame Relay DTE or a DCE device

Example 4-30 shows a sample output of the show interface serial command. Different hardware interface types might have slightly different output formats.

Example 4-30. Sample Output of show interface serial Command
Router#show interface serial1/2
Serial1/2 is up, line protocol is up
  Hardware is CD2430 in sync mode
  Internet address is 172.16.1.1/24
  MTU 1500 bytes, BW 128 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  131, LMI stat recvd 116, LMI upd recvd 0, DTE LMI up
  LMI enq recvd 0, LMI stat sent  0, LMI upd sent  0
  LMI DLCI 1023  LMI type is CISCO  frame relay DTE
  FR SVC disabled, LAPF state down
  Broadcast queue 0/64, broadcasts sent/dropped 9/0, interface broadcasts 0
  Last input 00:00:03, output 00:00:03, output hang never
  Last clearing of "show interface" counters 00:24:10
  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
  Queueing strategy: fifo
  Output queue :0/40 (size/max)
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
     241 packets input, 8933 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
     164 packets output, 2865 bytes, 0 underruns
     0 output errors, 0 collisions, 10 interface resets
     0 output buffer failures, 0 output buffers swapped out
     2 carrier transitions
     DCD=up  DSR=up  DTR=up  RTS=up  CTS=up

The output of the show interface serial command offers other beneficial information for verifying the Frame Relay router's connection to the CSU/DSU. When the output of the show interface serial command shows Serial1/2 is up, line protocol is up, this indicates that the router is communicating properly with the connected CSU/DSU and is successfully exchanging LMI status messages with the Frame Relay switch. The line Serial1/2 is down, line protocol is down reveals that a line problem has occurred with the router's connection to the CSU/DSU. The causes of the problem are typically cabling or signaling issues. The last line of the show interface serial command offers information on the status of the interface's connection with the CSU/DSU. When the output shows Serial1/2 is up, line protocol is down, this means that the local connection to the CSU/DSU is functioning properly, but the router is not exchanging LMI messages properly with the switch.

show frame-relay lmi [interface_type interface_number]

The show frame-relay lmi privileged EXEC mode command displays LMI statistics of Frame Relay enabled interfaces on the router. Alternatively, the command can be used to display the LMI statistics of a certain interface by specifying the interface type and the interface number. For example, show frame-relay lmi serial4/2 displays the LMI statistics for the Frame Relay operations configured on serial4/2 only. The information displayed by the show frame-relay lmi command shows the LMI type used by the Frame Relay interface as well as the counters for the LMI status exchange sequence, including errors such as LMI timeouts. Example 4-31 shows a sample output of the show frame-relay lmi command.

Example 4-31. Sample Output of show frame-relay lmi Command
Router#show frame-relay lmi
LMI Statistics for interface Serial1/2 (Frame Relay DTE) LMI TYPE = CISCO
  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
  Num Status Enq. Sent 159              Num Status msgs Rcvd 144
  Num Update Status Rcvd 0              Num Status Timeouts 16

show frame-relay map

The show frame-relay map privileged EXEC mode command shows the contents of the next hop protocol address to DLCI mapping table on the router. The table contains both dynamic mapped and static mapped entries. Example 4-32 shows a sample output of the show frame-relay map command.

Example 4-32. Sample Output of show frame-relay map Command
Router#show frame-relay map
Serial1/2 (up): ip 172.16.1.4 dlci 401(0x191,0x6410), dynamic,
              broadcast,, status defined, active
Serial1/2 (up): ip 172.16.1.5 dlci 501(0x1F5,0x7C50), dynamic,
              broadcast,, status defined, active
Serial1/2 (up): ip 172.16.1.2 dlci 301(0x12D,0x48D0), dynamic,
              broadcast,, status defined, active

show frame-relay pvc

The show frame-relay pvc privileged EXEC mode command displays detailed information of the PVC statistics on the router. This is an important command for monitoring Frame Relay connections on the router. It offers information such as all the DLCIs on the router, the interface that a DLCI is associated with, and the status of the PVC, as well as traffic and congestion management parameters such as the number of BECN, FECN, and DE flagged packets received. It also shows the input and output rate information on a per-VC basis.

NOTE

The format of the show frame-relay pvc output changes slightly and presents more information when certain Frame Relay features are configured on the router.

Example 4-33 shows a sample standard output of the show frame-relay pvc command.

Example 4-33. Sample Output of show frame-relay pvc Command
Router#show frame-relay pvc
PVC Statistics for interface Serial3/0 (Frame Relay DTE)

              Active     Inactive      Deleted       Static
  Local          1            0            0            0
  Switched       0            0            0            0
  Unused         0            0            0            0

DLCI = 101, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial3/0

  input pkts 12            output pkts 3            in bytes 408
  out bytes 102            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 3         out bcast bytes 102
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
  pvc create time 00:23:41, last time pvc status changed 00:23:41

show frame-relay route

The show frame-relay route privileged EXEC mode command is used to monitor the Frame Relay route table on the Cisco router configured as a Frame Relay switch. The Frame Relay switch uses the routes constructed in the table to switch frames from an incoming VC on an interface to an outgoing VC on another interface. The table also shows the current status of the switched VCs. This command is useful only on the router configured as a Frame Relay switch. Example 4-34 shows a sample output of the show frame-relay route command.

Example 4-34. Sample Output of show frame-relay route Command
Router#show frame-relay route
Input Intf      Input Dlci      Output Intf     Output Dlci   Status
Serial1/0       101             Serial4/3       201           active
Serial1/1       101             Serial4/3       301           active
Serial1/7       101             Serial4/3       501           active
Serial4/1       101             Serial4/3       401           active
Serial4/3       201             Serial1/0       101           active
Serial4/3       301             Serial1/1       101           active
Serial4/3       401             Serial4/1       101           active
Serial4/3       501             Serial1/7       101           active


Troubleshooting Frame Relay Connections with Cisco IOS debug Commands

This final section discusses the common issues and problems encountered on Frame Relay networks and how several IOS debug commands are used for troubleshooting Frame Relay connections.

In general, debug commands are used on a Cisco router only for diagnostic and troubleshooting purposes. During normal operation, all debug commands should be turned off. Debug commands generate massive overhead by taking up CPU cycles on the router. Enabling many debug commands at once can overwhelm the router and adversely affect its performance.

When using debug commands, the user has several options for logging the debug messages. The debug messages can be logged directly onto the router console, logged to a monitor if the router is accessed via Telnet, logged to a syslog server on the network, or stored in a buffer. Storing the debug messages inside the buffer is an attractive option because it creates less overhead. It is beyond the scope of this book to discuss the troubleshooting methodology of Cisco IOS in detail.

debug frame-relay events

The debug frame-relay events EXEC mode command can be used to identify the cause of end-to-end connection problems during installations of Frame Relay networks. When the router is using Frame Relay dynamic addressing, the debug frame-relay events displays information about Frame Relay Inverse ARP packets exchanged between the local router and the Frame Relay network.

Use the no form of the debug frame-relay events command to disable the debugging output. Example 4-35 shows a sample debug output of the debug frame-relay events command.

Example 4-35. Sample Output of debug frame-relay events Command
Router#debug frame-relay events
*Mar  1 01:16:39.235: Serial1/2: FR ARP input
*Mar  1 01:16:39.235: datagramstart = 0x7D0DE6E, datagramsize = 34
*Mar  1 01:16:39.235: FR encap = 0x64110300
*Mar  1 01:16:39.235: 80 00 00 00 08 06 00 0F 08 00 02 04 00 08 00 00
*Mar  1 01:16:39.239: AC 10 01 04 18 51 00 00 00 00 01 02 00 00
*Mar  1 01:16:39.239:
*Mar  1 01:16:44.899: Serial1/2: FR ARP input
*Mar  1 01:16:44.899: datagramstart = 0x7D0E0EE, datagramsize = 34
*Mar  1 01:16:44.899: FR encap = 0x30910300
*Mar  1 01:16:44.899: 80 00 00 00 08 06 00 0F 08 00 02 04 00 09 00 00
*Mar  1 01:16:44.899: AC 10 01 02 30 91 AC 10 01 01 01 02 00 00
*Mar  1 01:17:44.911: Serial1/2: FR ARP input
*Mar  1 01:17:44.911: datagramstart = 0x7D0CCEE, datagramsize = 34
*Mar  1 01:17:44.911: FR encap = 0x48D10300
*Mar  1 01:17:44.911: 80 00 00 00 08 06 00 0F 08 00 02 04 00 09 00 00
*Mar  1 01:17:44.911: AC 10 01 02 48 D1 AC 10 01 01 01 02 00 00

debug frame-relay lmi

The debug frame-relay lmi EXEC mode command is used to display information on the LMI packets exchanged by the router and the Frame Relay switch. The information from the debugging output can be used to determine whether the router and the Frame Relay switch are sending and receiving LMI packets properly.

The no form of this command disables the debugging output. Example 4-36 shows the sample debugging output of the debug frame-relay lmi command.

Example 4-36. Sample Output of debug frame-relay lmi Command
Router#debug frame-relay lmi
*Mar  1 01:26:16.063: Serial1/2(out): StEnq, myseq 43, yourseen 42, DTE up
*Mar  1 01:26:16.063: datagramstart = 0x7B00E94, datagramsize = 13
*Mar  1 01:26:16.063: FR encap = 0xFCF10309
*Mar  1 01:26:16.063: 00 75 01 01 00 03 02 2B 2A
*Mar  1 01:26:16.063:
*Mar  1 01:26:16.071: Serial1/2(in): Status, myseq 43
*Mar  1 01:26:16.071: RT IE 1, length 1, type 0
*Mar  1 01:26:16.071: KA IE 3, length 2, yourseq 43, myseq 43
*Mar  1 01:26:16.075: PVC IE 0x7 , length 0x6 , dlci 201, status 0x2 , bw 0
*Mar  1 01:26:16.075: PVC IE 0x7 , length 0x6 , dlci 301, status 0x2 , bw 0
*Mar  1 01:26:16.075: PVC IE 0x7 , length 0x6 , dlci 401, status 0x2 , bw 0
*Mar  1 01:26:16.075: PVC IE 0x7 , length 0x6 , dlci 501, status 0x2 , bw 0

The first line in the debugging output of debug frame-relay lmi is the LMI request the router has sent out to the switch. This is indicated by Serial1/2(out), which shows that the LMI request was sent out on serial1/2 to the switch. The sixth line in the debugging output shows the LMI response received from the switch, indicated by Serial1/2(in). The last four lines in the debugging output show the full LMI status message, which includes a description of the router's active PVCs.

debug frame-relay packet

The debug frame-relay packet EXEC command is used to analyze the packets sent on the Frame Relay interface. Because this debug command generates a large amount of debugging output, the command offers options to log the debugging output only to a specific interface or DLCI. Use the no form of the debug frame-relay packet command to disable the logging of the debugging output.

Example 4-37 shows the sample debugging output of the debug frame-relay packet command.

Example 4-37. Sample Output of debug frame-relay packet Command
Router#debug frame-relay packet
*Mar  1 01:37:25.195: Serial1/2(i): dlci 501(0x7C51), pkt type 0x800, datagramsize 53
*Mar  1 01:37:28.195: Serial1/2(i): dlci 501(0x7C51), pkt type 0x800, datagramsize 53
*Mar  1 01:37:31.203: Serial1/2(i): dlci 501(0x7C51), pkt type 0x800, datagramsize 53
*Mar  1 01:37:34.203: Serial1/2(i): dlci 501(0x7C51), pkt type 0x800, datagramsize 53

The debugging output shows that packets are received on Serial1/2 on DLCI 501. The packet type is 0x800 (IP on 10 MB net), and the size of the packets is 53 bytes.


Summary

This chapter focused on the practical aspects of Frame Relay technology by discussing the Cisco IOS configuration commands required to enable basic Frame Relay operation on a Cisco router. This chapter started by explaining the configuration tasks required to enable Frame Relay on a supported interface, including configuring LMI. LMI is a set of maintenance protocols for Frame Relay. LMI autosense allows a Cisco router to dynamically learn the LMI type supported by the Frame Relay switch. LMI autosense is enabled by default on Cisco IOS Release 11.2 or later.

This chapter also explained the frame-relay lmi-type configuration command, which allows users to specifically select the LMI type to be used. Dynamic Inverse ARP is enabled by default, and it allows a router to perform the remote network layer address to local DLCI resolution dynamically without user intervention. The frame-relay map configuration command was also introduced. It allows the user to perform static address mapping.

The configuration tasks involved in creating a logical subinterface under the physical interface were discussed. Both point-to-point and multipoint subinterface creation were explained. Because a Cisco router can be set up to function as a Frame Relay switch, the configuration examples for configuring a Frame Relay switch to use both local and global significant addressing were demonstrated. The final sections in this chapter introduced and explained the Cisco IOS show and debug commands, which are valuable for monitoring and troubleshooting basic Frame Relay operations.

This chapter concludes Part I of this book. Part II of this book looks at the Cisco IOS features for performing traffic policing and shaping.


Review Questions

1: | What is the Cisco IOS command required for enabling Frame Relay encapsulation on an interface?
2: | What are the differences between static and dynamic address mapping?
3: | What is the global configuration command required to configure a Cisco router as a Frame Relay switch?
4: | What is the command used for monitoring the contents of the address-to-DLCI mapping table?
5: | What is the debug command used for analyzing the details of the packets sent out of an interface on a specific DLCI?


Reference

Cisco IOS Release 12.2 Wide Area Network Command Reference: http://www.cisco.com/univercd/cc/td/doc/product/software/wan_r/wrdfrely.htm http://www.cisco.com/unverscd/cc/td/doc/product/software/ios122/122cgcr/fwan_r/frcmds/index.htm


Part II. Cisco Frame Relay Solutions for Policing and Shaping

Previous Page
Next Page

Part II: Cisco Frame Relay Solutions for Policing and Shaping

Chapter 5 Frame Relay Traffic Shaping

Chapter 6 Cisco Frame Relay Switching Enhancements

Chapter 7 Cisco Frame Relay End-to-End Keepalive


Chapter 5. Frame Relay Traffic Shaping

Part II of this book begins the discussion of a series of Cisco IOS software features developed specifically for managing traffic and network congestion on Frame Relay networks. This chapter focuses on the Frame Relay Traffic Shaping feature, a key Cisco solution for managing network congestion on Frame Relay networks. After the completion of this chapter, readers will be able to understand network congestion issues that are frequently encountered by Frame Relay users and how Frame Relay Traffic Shaping can effectively avert these problems.

This chapter explains how Frame Relay Traffic Shaping works on a Cisco router and addresses the Cisco IOS configuration commands involved and the configuration tasks required to set up Frame Relay Traffic Shaping. In addition, this chapter discusses the Cisco IOS show commands useful for monitoring and verifying Frame Relay Traffic Shaping information on a Cisco router. At the end of this chapter, two case studies on the implementation of the Frame Relay Traffic Shaping feature are presented.

The topics and questions that this chapter addresses include the following:

  • Synopsis of the issues of oversubscription of bandwidth and the problems created by network congestion

  • Overview of how Frame Relay Traffic Shaping works and how it can effectively manage network congestion

  • Introduction to Frame Relay adaptive shaping to Backward Explicit Congestion Notification (BECN) and ForeSight

  • Configuration tasks for enabling Frame Relay Traffic Shaping on a Cisco router

  • Managing Frame Relay broadcast traffic with a broadcast queue

  • Comparison of Frame Relay Traffic Shaping and generic traffic shaping

  • Case studies on Frame Relay Traffic Shaping

After completing this chapter, readers will be able to appreciate the use of the Frame Relay Traffic Shaping feature to control congestion on Frame Relay networks. Readers will be able to understand the parameters involved in Frame Relay Traffic Shaping and to configure the Frame Relay Traffic Shaping feature on a Cisco router with the Cisco IOS software.

Finally, readers will be able to effectively maintain and troubleshoot Frame Relay Traffic Shaping configurations on a Cisco router using the relevant Cisco IOS show and debug commands.


Current Issues

Congestion has been an inherent problem in Frame Relay networks for quite some time now. With bandwidth being such a scarce resource, network operators and their customers have struggled to ease the congestion conditions on their networks without having to increase their bandwidth tariffs.

As discussed in Chapter 3, "Planning and Managing Frame Relay Networks," today's network traffic trend is generally bursty in nature. As such, sudden bursts of a large volume of data transactions from users' applications can easily overwhelm a transmission pipe, often leading to temporary network congestion until the entire transaction completes. At its worst, a sustained burst of data traffic can compete with mission-critical traffic for a greater share of the available bandwidth. Without a proper traffic prioritization scheme deployed, mission-critical traffic can experience a high level of latency. When the available bandwidth is limited, there has to be a way to restrict the rate at which users can send traffic into the Frame Relay network. Effective use of queuing mechanisms can ensure that mission-critical traffic on the network always receives its minimum required level of service.

Dealing with Oversubscription

Today, many Frame Relay carriers and service providers allow oversubscription by agreeing to carry the customers' traffic above their subscribed level of the committed information rate (CIR) when there is no congestion. Consequently, customers burst their traffic into the Frame Relay network at the link access rate, which is usually much higher than their subscribed CIR. To handle the excess traffic, the providers' Frame Relay switches forward traffic above the CIR range only when the intended traffic path is not congested. Without any doubt, oversubscription can make a Frame Relay carrier's service more competitive. The ability to burst traffic above the subscribed CIR is attractive to many customers and users. At present, oversubscription has become a common item in the service level agreements drawn up by many Frame Relay carriers and service providers.

Nonetheless, oversubscription has to be carefully monitored, managed, and controlled, otherwise congestion can quickly build up. When users burst their traffic on a virtual circuit (VC) into the Frame Relay network, the input traffic rate at the Frame Relay switch rapidly climbs up. Once the traffic rate on the VC reaches the excess burst (Be) range, frames are queued up in the switches' hold queues rather than being sent directly to the output interfaces' transmission buffers. During a sustained period of oversubscription, congestion begins to occur.

As soon as the traffic load has exceeded the excess burst limit, all further frames received by the Frame Relay switches are discarded.

To prevent frames from being sent out on the wire to be discarded eventually, the Frame Relay switches need to communicate with the users' Frame Relay access routers to exchange information on the congestion conditions of the network. Frame Relay has congestion notification mechanisms built in to the specifications (FECN and BECN), but these are mainly intended for the end systems. Therefore, it is necessary to allow the Frame Relay access routers to react to receiving notifications of congestion from the Frame Relay network.

Data Rate Mismatch

Data rate mismatch is a commonly unnoticed cause of network congestion. Hub-and-spoke topology is by far the most popular and cost-saving topology on any Frame Relay network because there are fewer required point-to-point connections. Even so, congestion can occur because of bottlenecks in hub-and-spoke networks with high-speed connections to the central site and low-speed connections to the branch site. The mismatch in data rate often results in congestion in the branch sites when the central site sends its traffic downstream at a higher throughput.


Solutions to Current Issues

Frame Relay Traffic Shaping is a key Cisco IOS feature for handling users' traffic and managing network congestion on Frame Relay networks.

NOTE

Released in 1996, the Frame Relay Traffic Shaping feature is available from IOS Software Release 11.2 onward.

Though the Frame Relay Traffic Shaping feature is described in detail in the sections that follow, it is described generally here so that you can understand how it helps to provide a solution to current and existing problems of congestion.

Cisco's Frame Relay Traffic Shaping feature allows users to perform rate enforcement of traffic on a serial interface connected to a Frame Relay switch. Frame Relay Traffic Shaping is especially effective on hub-and-spoke networks where high speed to low speed circuit mismatch is common. For example, the Frame Relay Traffic Shaping feature can be applied at the egress interface at the higher speed site (usually the hub site) to rate limit the outgoing traffic so that it does not exceed the remote sites' lower access speed.

Per-VC queuing is an essential component of Frame Relay Traffic Shaping. Frame Relay Traffic Shaping supports both priority and custom queuing configured on a per-VC basis.

The Frame Relay Traffic Shaping feature supports adaptive shaping as its congestion management tool. The early implementation of Frame Relay Traffic Shaping feature supports adaptive shaping to BECN feedback. In later implementations, adaptive shaping to foresight was added to the whole feature's list of functionalities.


Frame Relay Traffic Shaping Explained

Cisco's Frame Relay Traffic Shaping feature provides many parameters for handling users' traffic and managing congestion on Frame Relay networks. With Frame Relay Traffic Shaping, users are able to configure rate enforcement to either the CIR level or to other user-defined values on a per-VC basis. In this way, bandwidth can be flexibly allocated to each VC and tailored to specific requirements. This allows the feature to provide a mechanism for sharing a common Frame Relay connection by multiple VCs over the same line.

In addition, Frame Relay Traffic Shaping allows traffic queuing to be configured at the VC level. Presently, Frame Relay Traffic Shaping supports priority queuing, custom queuing, and First-In-First-Out (FIFO) queuing (default). Queuing allows a finer level of granularity in the prioritization of traffic by providing users with more control over the traffic flow on individual VCs. For example, when custom queuing is applied on a VC, users can time multiplex multiple traffic types such as IP, IPX, and SNA, thereby guaranteeing a minimum bandwidth for each type of traffic on the VC. Alternatively, if the user wants to guarantee bandwidth for a certain type of traffic, a priority queue can be defined on the VC for the specified traffic type assigned with the highest priority.

Besides administering bandwidth, Frame Relay Traffic Shaping can be used to manage network congestion. The Frame Relay specifications support a congestion notification mechanism with the implementation of BECN and FECN bits inside the Frame Relay headers. Before Frame Relay Traffic Shaping, there was no mechanism to allow the Cisco Frame Relay Access Device (FRAD) to react to BECN-tagged packets received from the network. With Frame Relay Traffic Shaping, a Cisco router can dynamically throttle traffic as soon as it detects congestion, signaled by the presence of BECN tagged packets. When a Cisco router is configured to respond to BECN, it holds the overload packets in the queues to reduce the flow of data into a congested Frame Relay network. The throttling is performed at a per-VC level, and the transmission rate is adjusted dynamically based on the number of BECN-tagged packets received. This allows a Cisco router to actively adapt to downstream congestion conditions in the Frame Relay network.

In addition to adaptive shaping to BECN, Frame Relay Traffic Shaping supports adaptive shaping to ForeSight, an additional functionality that allows a Cisco router to actively communicate with a Cisco Frame Relay switch using timed ForeSight messages. When adaptive shaping to ForeSight is enabled, a Cisco router can dynamically adjust its transmission rate based on congestion conditions reported in ForeSight messages received from the switch without relying on remote devices to send BECN tagged packets. Figure 5-1 illustrates the small difference between adaptive shaping to BECN and ForeSight.

Figure 5-1. Using BECN and ForeSight as Congestion Notification Mechanisms

In summary, the Frame Relay Traffic Shaping feature provides functionalities in three major components:

  • Rate Enforcement configured on a per-VC basis

  • Priority queuing, custom queuing, or default FIFO queuing at the VC level

  • BECN and ForeSight support for congestion management.


How Frame Relay Traffic Shaping Works

This section discusses how Frame Relay Traffic Shaping generally works. Figure 5-2 illustrates a flow diagram of a packet arriving on an interface of a router that has Frame Relay Traffic Shaping enabled on the packet's outgoing interface.

Figure 5-2. Flow Diagram of Packet with Frame Relay Traffic Shaping

An incoming packet that enters an interface of a router can be fast switched or process switched.

Process Switching

Process switching is a "process-oriented" switching method that requires a routing table lookup for every packet switched. With process switching, the router copies an incoming packet to the processor memory, consults its Layer 3 routing table to determine the next hop address and output interface, and finally rewrites the packet with the destination address and frame Media Access Control (MAC) header. Process switching is slow, but it supports per-packet load-sharing.

Fast Switching

Fast switching is a major improvement over process switching. In fast switching, a route cache is used to speed up the entire switching process. With fast switching, when an incoming packet is received by a router on an interface, the router performs a lookup in its route cache for the destination network address. If there is an entry in the route cache, the router immediately rewrites the header and forwards the packet to the corresponding output interface. If a route cache entry does not exist for the destination of the packet, the packet is process switched, but an entry is populated in the route cache. Subsequent packets received by the router that are destined for the same destination are fast switched as long as the cache entry exists.

Fast switching is enabled by default on all interfaces that support fast switching. Fast switching only supports per-destination-based load-sharing.

Frame Relay Traffic Shaping on Egress Interface

If the transit packet needs to exit on an interface of the router that does not have Frame Relay Traffic Shaping enabled, the packet is immediately sent the output interface. However, if the router needs to transmit a packet on an interface that has Frame Relay Traffic Shaping enabled, the router needs to verify several things. First, the router checks whether sufficient credit is available to transmit the packet. The term credit is analogous to a measure of available bandwidth that can be used without causing oversubscription on the network. The credit system used in Frame Relay Traffic Shaping is based on a token bucket algorithm, which is explained later in this section.

If there is sufficient credit available, the router immediately sends the packet to the output interface, deducts the packet size from the credit pool, and then proceeds to start the transmission process for the packet. On the other hand, if there is insufficient credit available, the packet has to be delayed and is immediately sent to a queue set up on the outgoing Frame Relay permanent virtual circuit (PVC). The packet is held in the queue and waits until sufficient credits have built up for transmission. However, in the event the queue on the Frame Relay PVC is full, the router discards the packet. The Frame Relay Traffic Shaping feature supports several queuing systems on a Frame Relay PVC. The queuing algorithms include the default FIFO queuing, priority queuing, and custom queuing.

NOTE

Each queuing system supports different a queue size or depth. By default, the queue depth of FIFO queues is 40 packets. The user specifies the queue depths of priority queues and custom queues.

The Frame Relay Traffic Shaping feature uses a credit system based on a leaky bucket algorithm to regulate traffic flows. The following section provides the definition of the leaky bucket algorithm and explains how it works. The flow diagram of the token bucket algorithm is shown in Figure 5-3.

Figure 5-3. Token Bucket or Leaky Bucket Flowchart

A token bucket is a mechanism that rate enforcement systems use to define the rate of transfer and to regulate the flow of traffic entering a network. Frame Relay Traffic Shaping implements a variation of the token bucket algorithm also known as the leaky bucket algorithm. The leaky bucket algorithm smooths out the data flow exiting the traffic shaper and entering the Frame Relay network. In the context of this chapter, the terms "token bucket" and "leaky bucket" are used interchangeably. In the token bucket algorithm system, the token bucket has a fixed size and contains tokens that are typically equal in representation to actual packet size.

Beginning with the Credit available condition in the flow chart diagram depicted in Figure 5-3, the Frame Relay Traffic Shaping system transmits a packet from a queue only if there are available tokens equivalent to the size of the packet in the token bucket. If sufficient tokens are available, the packet is sent to the output interface for transmission, and the required tokens are removed from the token bucket.

After the transmission of the packet is completed, the system verifies whether the Frame Relay PVC queues are empty. If the queues are not empty (which indicates congestion), the system smooths the output rate. This prevents overrun by ensuring that the next packet is transmitted after a time interval when tokens are replenished. If there is no congestion (as indicated by an empty queue), the arriving packet is transmitted, and the tokens are removed from the token bucket. If there are not enough tokens in the bucket, the arriving packet is sent to the queues, or the system continues to buffer the existing packets in the queues until sufficient tokens are available in the next time interval. In the event that there are no available tokens and the queues on the Frame Relay PVC are filled, the arriving packets are discarded.

In every time interval, the token bucket system generates tokens, and the tokens are added to the token bucket. The time interval is a constant fixed rate, which is also known as the measurement interval. If the token bucket is full when tokens are replenished, the newly arriving tokens are discarded instead of overflowing the token bucket.

The token bucket algorithm uses several important parameters: mean rate, burst size, and time interval. They are related by the following formula:

mean rate = burst size / time interval

Consider the Frame Relay terminologies introduced in Chapter 1, "Introduction to Frame Relay." In Frame Relay terms, the mean rate defined in the token bucket algorithm is equal to the CIR, which is defined as the rate of transfer in bits per second that the network commits to transfer under normal conditions. The burst size corresponds to the committed burst (Bc). It represents the maximum amount of committed data that may be sent in one time interval Tc. The excess burst (Be) is the maximum amount of uncommitted data that may be sent in one time interval Tc.

The leaky bucket that Frame Relay Traffic Shaping uses has a maximum capacity of Bc plus Be. Hence, the maximum burst allowed is equal to Bc + Be. A sum of tokens equivalent to Bc is added to the token bucket in every Tc time interval. When the router needs to transmit a packet on an exit interface with Frame Relay Traffic Shaping enabled, the packet is transmitted only if there are sufficient tokens in the token bucket. Otherwise, the packet is buffered in the queues set up on the Frame Relay PVC until sufficient tokens are available. In this way, Frame Relay Traffic Shaping ensures that the long-term transmission rate does not exceed the established rate at which tokens are replaced in the bucket and allows the network to manage congestion.


Adaptive Shaping to BECN

This section discusses the adaptive shaping to BECN component of the Frame Relay Traffic Shaping feature. When adaptive shaping to BECN is enabled on a Cisco router, the router throttles its output transmission rate on a Frame Relay PVC based on BECN tagged packets received from the Frame Relay network. To use adaptive shaping to BECN, Frame Relay Traffic Shaping must be configured at the main interface.

When a Cisco router receives a BECN tagged packet in the opposite direction of an active traffic flow, this represents a signal of congestion in the Frame Relay network. The router responds to this condition by decreasing its output transmission rate on the congested Frame Relay PVC by a large amount. Subsequently, the router continues to lower its output rate on the Frame Relay PVC with every BECN tagged packet received until its present transmission rate eventually drops to the Minimum CIR (MINCIR) value. The router should not lower its transmission rate to a level below the true CIR rate guaranteed by the service provider.

After a period of time when the router no longer receives any BECN tagged packets, the router increases and builds up the transmission rate slightly to avoid any underutilization. Note that because adaptive shaping to BECN depends on a BECN tagged packet being received from the congested network, it requires a user packet with the BECN tagged frame to be sent in the opposite direction of the active traffic flow causing congestion.

When setting up the parameters for adaptive shaping to BECN, the MINCIR value on the router is normally set to the true CIR value of the Frame Relay PVC purchased from the service provider. To allow oversubscription, the CIR value on the router is set to the physical link access rate.

NOTE

MINCIR is the minimum acceptable incoming or outgoing CIR for a Frame Relay VC. If not configured, the MINCIR defaults to half of the CIR. If CIR is not configured either, it defaults to 56 kpbs on Cisco routers.


Adaptive Shaping to ForeSight

Adaptive shaping to ForeSight allows a Cisco router to respond to ForeSight messages and to react to network congestion by enabling VC-level traffic shaping and rate limiting in a timely manner. Adaptive shaping to ForeSight is a component of Frame Relay Traffic Shaping. On Cisco switches, router ForeSight is a network traffic control software that allows the Frame Relay switches to extend ForeSight messages over a User-to-Network (UNI) interface and passes the BECN bit for VCs.

To enable adaptive shaping to ForeSight on a Cisco router, Frame Relay Traffic Shaping must be configured on the main interface. Additionally, the Frame Relay switch must be able to support adaptive shaping to ForeSight.

NOTE

By default, adaptive shaping to ForeSight is enabled on a Cisco router when Frame Relay Traffic Shaping is configured. However, it is not applied to any VC until the frame-relay adaptive-shaping foresight command is applied to the specified VC's map class.

When adaptive shaping to ForeSight is configured on a Frame Relay switch, the switch periodically sends out ForeSight messages based on a configured time interval (which ranges from 40 to 5000 milliseconds). On receiving ForeSight messages that carry congestion information from the switch, the router becomes aware that certain data-link connection identifiers (DLCIs) are congested. The router responds to the ForeSight message by applying traffic shaping to slow down the output rate on the congested VCs.

Compared with adaptive shaping to BECN, the router reacts in the same way as if it had received a BECN tagged packet. Therefore, both adaptive shaping to BECN and ForeSight reduce the output traffic rate during periods of network congestion. A notable difference between BECN and ForeSight is that BECN requires a user packet to be sent in the direction of the congested DLCI to inform a congested state. However, sending user packets is unpredictable and thus is generally not a reliable mechanism. On the other hand, timed ForeSight messages allow a router to always receive a congestion notification message before congestion escalates to become a significant problem. With adaptive shaping to ForeSight, traffic shaping is applied timely to slow down the output traffic rate on the congested DLCIs.

Frame Relay Traffic Shaping is available as of IOS Software Release 11.2 with adaptive shaping to BECN support. In Cisco IOS Software Release 11.3, adaptive shaping to ForeSight message support has been added to the traffic shaping feature's list of functionalities.

NOTE

The frame-relay adaptive-shaping { becn | foresight } command introduced in IOS Release 11.3 has replaced the frame relay becn-response-enable command.


Configuring Frame Relay Traffic Shaping

This section discusses the IOS configuration commands for configuring Frame Relay Traffic Shaping on a Cisco router.

NOTE

For this discussion, IOS Release 12.2(1) was used on all routers in the lab to maintain a consistency of software versions. The same release was used in the case study scenarios at the end of this chapter.

Before configuring Frame Relay Traffic Shaping on a Cisco router, you must enable Frame Relay encapsulation on the main interface. By default, configuring Frame Relay Traffic Shaping on the main interface enables traffic shaping with per-VC queuing for all PVCs and switched virtual circuits (SVCs) under the main interface. To configure Frame Relay Traffic Shaping on a specified main interface, follow the configuration steps listed below:

Step 1. | Go into the interface configuration mode of the main interface on which you want to configure Frame Relay Traffic Shaping. Frame Relay encapsulation must be enabled on the specified main interface.
Step 2. | Enable Frame Relay Traffic Shaping with per-VC queuing on the main interface with the frame-relay traffic-shaping interface configuration command.

Example 5-1 shows a configuration example of enabling Frame Relay Traffic Shaping on an interface.

Example 5-1. Configuration Example for Enabling Frame Relay Traffic Shaping
Router#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router(config)#interface serial4/2
Router(config-if)#encapsulation frame-relay
Router(config-if)#frame-relay traffic-shaping
Router(config-if)#

NOTE

Note that Frame Relay Traffic Shaping can be enabled only on the main interface. Presently, it is not possible to enable traffic shaping for only a particular DLCI or a subinterface under the main interface.


Creating a Traffic Shaping Map Class

A Frame Relay map-class command is used to define and set up the various traffic shaping parameters for use in the feature. The traffic rate enforcement parameters, per-VC queuing, and adaptive shaping to BECN or ForeSight are collectively configured under a Frame Relay map class. Table 5-1 summarizes the Frame Relay Traffic Shaping parameters that are used to manage traffic.

Table 5-1. Traffic Shaping Parameters

Parameters

Definitions

Bc

Committed burst size

Be

Excess burst size

CIR

Committed information rate

DE

Discard eligibility

EIR

Excess information rate

MINCIR

Minimum CIR, defaults to half the value of CIR

Tc

Measurement interval, equal to Bc/CIR

To configure a map class, follow the configuration steps listed as follows:

Step 1.
In the global configuration mode, specify the map class name with map-class frame-relay map-class-name. This enters the user into the map-class configuration mode.

Step 2.
(optional) In the map-class configuration mode, specify a custom queue list for the map class with the frame-relay custom-queue-list list-number command. This requires the user to create the custom queue list.

Step 3.
(optional) In the map-class configuration mode, specify a priority queue list for the map class with the frame-relay priority-group list-number command. This requires the user to create the priority queue group.

Step 4.
(optional) In the map-class configuration mode, set the following parameters for rate enforcement:

- Specify the CIR with frame-relay cir bps command.

- Specify the MINCIR with frame-relay mincir bps command.

- Specify the committed burst size with frame-relay bc bits command.

- Specify the excess burst size with frame-relay be bits command.

- The single frame-relay traffic-rate CIR max-peak command can be used to set the CIR rate and the maximum peak (CIR + EIR).

- Specify the idle timer with frame-relay idle-timer duration command. The command is usually used for SVC connections to specify the maximum idle time before tearing down the connection.

Step 5.
(optional) In the map-class configuration mode, enable BECN or ForeSight feedback on the map class with the frame-relay adaptive-shaping { becn | foresight } command.

Example 5-2 shows an example of creating a Frame Relay map class named QOS.

Example 5-2. Creating a Frame Relay Map Class
Router#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router(config)#map-class frame-relay QOS
Router(config-map-class)#

Example 5-3 shows a configuration example of assigning a custom queue list to the QOS map class.

Example 5-3. Assigning a Custom Queue List to the Map Class
Router#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router(config)#map-class frame-relay QOS
Router(config-map-class)#frame-relay custom-que
Router(config-map-class)#frame-relay custom-queue-list ?
  <1-16>  Custom queue list number

Router(config-map-class)#frame-relay custom-queue-list 1

Example 5-4 shows a configuration example of assigning a priority queue group to the QOS map class.

Example 5-4. Assigning a Priority Queue Group to the Map Class
Router#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router(config)#map-class frame-relay QOS
Router(config-map-class)#frame-relay priority-group ?
  <1-16>  Priority group number

Router(config-map-class)#frame-relay priority-group 1

NOTE

Under a Frame Relay map class, only a single type of queuing can be configured at any one time. For example, if a custom queue list is applied to the map class, it is not possible to apply a priority group to the same map class without first removing the custom queue list. Moreover, if neither priority queuing nor custom queuing is configured, the Frame Relay map class defaults to FIFO queuing. The case studies later in this chapter provide some configuration examples of setting a priority group and a custom queue list using access lists.

Example 5-5 shows a configuration example setting up the various Frame Relay Traffic Shaping parameters inside a Frame Relay map class. The frame-relay cir command shown in this example specifies the inbound or outbound CIR. It is important to know that the CIR value specified in the map class usually does not reflect the CIR value given by the Frame Relay carriers. Most often, the CIR value specified in the frame-relay cir command represents the rate at which the Frame Relay access router sends its traffic on the VC into the Frame Relay network, averaged over a minimum increment of time (Tc). The "in" and "out" parameters for the frame-relay cir command are optional, but when the direction is not specified, the configured CIR is applied to both incoming and outgoing directions.

NOTE

When Frame Relay Traffic Shaping is enabled, and if a particular DLCI or VC has no map class applied under it, that DLCI or VC is assigned a default map class with a CIR value of 56000.

The frame-relay bc and frame-relay be map-class configuration commands set the committed burst size and the excess burst size, respectively. As a rule of thumb, Bc is usually set to 1/8 the value of CIR. Be represents the excess burst size.

The frame-relay mincir command sets the minimum acceptable level of CIR on the VC, either in the outgoing direction or both incoming and outgoing. When Frame Relay Traffic Shaping is used for an oversubscription configuration, the MINCIR value is typically set to the CIR value assigned by the Frame Relay carriers. The CIR value is then set to the link access speed. In this way, it is possible to burst above the guaranteed rate when there is no congestion and then to fall back to the guaranteed rate when congestion builds up.

Alternatively, the traffic shaping parameters can be set up using a single frame-relay traffic-rate map-class configuration command. The first parameter in the frame-relay traffic-rate command specifies the average rate (normally true CIR value) and the second parameter indicates the peak rate (CIR + EIR rate).

Take note that the units of measurement used in the Frame Relay map-class configuration commands for setting up the traffic shaping parameters is bits per second (bps).

Example 5-5. Configuration Example for Frame Relay Traffic Shaping Parameters Setup
Router(config-map-class)#frame-relay cir ?
  <1-45000000>  Applied to both Incoming/Outgoing CIR, Bits per second
  in            Incoming CIR
  out           Outgoing CIR

Router(config-map-class)#frame-relay cir 128000

Router(config-map-class)#frame-relay bc ?
  <300-16000000>  Applied to both Incoming/Outgoing Bc, Bits
  in              Incoming Bc
  out             Outgoing Bc
  <cr>

Router(config-map-class)#frame-relay bc 16000
Router(config-map-class)#frame-relay be ?
  <0-16000000>  Applied to both Incoming/Outgoing Be, Bits
  in            Incoming Be
  out           Outgoing Be
  <cr>

Router(config-map-class)#frame-relay be 0

Router(config-map-class)#frame-relay mincir ?
  <1000-45000000>  Applied to both Incoming/Outgoing CIR, Bits per second
  out              Outgoing minimum acceptable CIR

Router(config-map-class)#frame-relay mincir 64000

Router(config-map-class)#frame-relay traffic-rate ?
  <600-45000000>  Committed Information Rate (CIR)

Router(config-map-class)#frame-relay traffic-rate 64000 128000

NOTE

Typically, the "out" or default option is used in the commands for setting up the Frame Relay Traffic Shaping parameters in a map class.

Example 5-6 shows a configuration example of enabling BECN and ForeSight as the congestion backward notification mechanism for Frame Relay Traffic Shaping. This is accomplished with the frame-relay adaptive-shaping {BECN | ForeSight} configuration command under the Frame Relay map-class configuration mode. Both congestion notification mechanisms are mutually exclusive. For example, when adaptive shaping to BECN is enabled, configuring adaptive shaping to ForeSight in the same map class automatically removes adaptive shaping to BECN.

Example 5-6. Configuring Adaptive Shaping to BECN as the Selected Congestion Notification
Enter configuration commands, one per line.  End with CNTL/Z.
Router(config)#map-class frame-relay QOS
Router(config-map-class)#frame-relay adaptive-shaping becn
Router(config-map-class)#

Router#show running-config
Building configuration...

Current configuration : 2493 bytes
<output omitted>

map-class frame-relay QOS
 frame-relay traffic-rate 64000 128000
 frame-relay adaptive-shaping becn
 frame-relay cir 128000
 frame-relay bc 16000
 frame-relay be 0
 frame-relay mincir 64000
 frame-relay priority-group 1
Router#

Router#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router(config)#map-class frame-relay QOS
Router(config-map-class)#frame-relay adaptive-shaping foresight
Router(config-map-class)#
Router#show running-config
Building configuration...
Current configuration : 2493 bytes

<output omitted>
!
map-class frame-relay QOS
 frame-relay traffic-rate 64000 128000
 frame-relay adaptive-shaping foresight
 frame-relay cir 128000
 frame-relay bc 16000
 frame-relay be 0
 frame-relay mincir 64000
 frame-relay priority-group 1
Router#


Associating the Frame Relay Map Class

After setting up a Frame Relay map class with the default or user-defined traffic shaping parameters, the configured map class has to be associated with a main interface or a subinterface or assigned directly to a VC. For this purpose, the frame-relay class interface configuration command is used to associate a created Frame Relay map class with a specified main interface or subinterface.

A user can choose from three levels of a hierarchy when associating a Frame Relay map class. First of all, when a Frame Relay map class is associated with a main interface, the map class's configurations apply to all VCs under the main interface. All existing VCs on any subinterfaces created under the main interface inherit the traffic shaping parameters defined in the map class.

If a map class is applied at the subinterface level, all existing VCs under the chosen subinterface inherit the map class's traffic shaping configurations, but they override any map class associated with the main interface if there are any configured.

The final level of the hierarchy allows a map class to be directly associated with an individual VC at the per-DLCI level using the class virtual circuit configuration command. As such, the VC bypasses and overrides any map class applied at the main interface or subinterface. To illustrate this slightly perplexing concept, a simple configuration is used in Example 5-7.

Example 5-7. Associating a Frame Relay Map Class
Router#show running-config
<output omitted>
!
interface serial2/0
encapsulation frame-relay
frame-relay class class_a
interface serial2/0.1 multipoint
frame-relay class class_b
frame-relay interface-dlci 100
frame-relay interface-dlci 200
  class class_c
  !
map-class frame-relay class_a
!
map-class frame-relay class_b
!
map-class frame-relay class_c

In this configuration, DLCI 200 is associated directly with the map class class_c. Using the class configuration command at the DLCI level overrides map class class_a and class_b assigned to the main interface and subinterface, respectively. DLCI 100 under the subinterface s2/0.1 is associated with map-class class_b and overrides map class class_a. Finally, all VCs under the main interface not associated with any subinterface or VC level map classes are associated with the map class class_a.

To associate a Frame Relay map class to either a main interface or a subinterface, follow the configuration steps listed as follows, beginning in global configuration mode:

Step 1. | Go into the main interface or subinterface configuration mode of the main interface/subinterface on which you want to associate the Frame Relay map class.
Step 2. | Associate the map class to the main interface or subinterface with the frame-relay class class-name command. To remove the Frame Relay map class from the main interface or subinterface, use the no form the frame-relay class command.

Example 5-8 shows a configuration example associating the Frame Relay map class named fast_vc at the main interface and subinterface level.

Example 5-8. Configuration Example Associating Map Class at the Interface and Subinterface Level
Router#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router(config)#interface serial3/0
Router(config-if)#frame-relay class ?
  WORD  map class name

Router(config-if)#frame-relay class fast_vc

Router#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router(config)#interface serial3/0.1 multipoint
Router(config-subif)#frame-relay class ?
  WORD  map class name

Router(config-subif)#frame-relay class fast_vc

To associate a Frame Relay map class directly at the VC level, follow the configuration steps listed as follows, beginning in the interface or subinterface configuration mode:

Step 1. | Go into the Frame Relay DLCI configuration mode from the interface or subinterface mode with the frame-relay interface-dlci dlci command.
Step 2. | To associate a map class with a specified DLCI, use the class virtual circuit configuration command. To remove the association between the DLCI and the map class, use the no form of this command.

Example 5-9 presents configuration examples for associating a Frame Relay map class directly to a DLCI assigned to a multipoint subinterface.

Example 5-9. Configuration Examples for Associating a Specific Map Class Directly to a DLCI
Router#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router(config)#interface serial3/0.1 multipoint
Router(config-subif)#frame-relay interface-dlci 100
Router(config-fr-dlci)#class ?
  WORD  map class name

Router(config-fr-dlci)#class slow_vc


Monitoring Frame Relay Traffic Shaping Information

This section uses a hub-and-spoke Frame Relay network to illustrate the Cisco IOS show commands, which are useful for monitoring Frame Relay Traffic Shaping information on a Cisco router. The hub-and-spoke Frame Relay network is depicted in Figure 5-4.

Figure 5-4. Network Topology for Configuration Examples

In this setup, a hub-and-spoke Frame Relay network with a central hub site is connected to three remote branch office sites. The central hub site is connected to two remote branch office sites with a multipoint subinterface residing on subnet 172.16.1.0/24. The central hub site is connected to the third remote branch office site on a point-to-point link residing on subnet 172.16.2.0/30. At the same time, a few servers are set up to generate network traffic from the central hub site into the Frame Relay network.

The main objective of the traffic simulation is to analyze the traffic shaping functions on the routers based on the parameters defined in the routers' configurations. Frame Relay Traffic Shaping is enabled on all the routers in the network. In this example, the routers are connected directly to a Cisco IGX 8420 multiservice WAN switch configured as a Frame Relay switch. On the Frame Relay switch, three Frame Relay PVCs are provisioned to carry traffic between the sites. The point-to-point Frame Relay PVC between hub router A and remote spoke router D is provisioned with an end-to-end CIR of 64 kpbs. The Frame Relay PVCs on hub router A connected to spoke router B and spoke router C each has a lower CIR rate of 32 kpbs.

Example 5-10 shows the running configuration of the routers based on the parameters defined in Figure 5-4.

Example 5-10. Running Configurations of the Routers
! RouterA Configuration:

   RouterA#show running-config
   Building configuration...
   <output-omitted>
   !
   interface Ethernet1/1
    ip address 192.168.1.254 255.255.255.0
   !
   interface Serial3/0
    bandwidth 128
    no ip address
    encapsulation frame-relay
    frame-relay class slow_vc
    frame-relay traffic-shaping
   !
   interface Serial3/0.101 multipoint
    ip address 172.16.1.1 255.255.255.0
    frame-relay map ip 172.16.1.2 102 broadcast
    frame-relay map ip 172.16.1.3 103 broadcast
   !
   interface Serial3/0.104 point-to-point
    ip address 172.16.2.1 255.255.255.252
    frame-relay interface-dlci 104
     class fast_vc
   !
   map-class frame-relay fast_vc
    frame-relay cir 64000
    frame-relay bc 8000
    frame-relay be 0
   !
   map-class frame-relay slow_vc
    frame-relay cir 32000
    frame-relay bc 4000
    frame-relay be 0

   ! Router B Configuration:

   RouterB#show running-config
   Building configuration...
   <output omitted>
   !
   interface Serial1/1
    ip address 172.16.1.2 255.255.255.0
    encapsulation frame-relay
    frame-relay class slow-vc
    frame-relay traffic-shaping
    frame-relay map ip 172.16.1.1 201 broadcast
    frame-relay map ip 172.16.1.3 201 broadcast
   !
   map-class frame-relay slow-vc
    frame-relay cir 32000
    frame-relay bc 4000
    frame-relay be 0

   ! Router C Configuration:

   RouterC#show running-config
   Building configuration...
   <output omitted>
   !
   interface Serial3
    ip address 172.16.1.3 255.255.255.0
    encapsulation frame-relay
    frame-relay class slow-vc
    frame-relay traffic-shaping
    frame-relay map ip 172.16.1.1 301 broadcast
    frame-relay map ip 172.16.1.2 301 broadcast
   !
   map-class frame-relay slow-vc
    frame-relay cir 32000
    frame-relay bc 4000
    frame-relay be 0

   ! Router D Configuration:

   RouterD#show running-config
   Building configuration...
   <output omitted>
   !
   interface Serial0
    no ip address
    encapsulation frame-relay
    frame-relay traffic-shaping
   !
   interface Serial0.401 point-to-point
    ip address 172.16.2.2 255.255.255.252
    frame-relay interface-dlci 401
     class fast-vc
   !
   map-class frame-relay fast-vc
    frame-relay cir 64000
    frame-relay bc 8000
    frame-relay be 0

show frame-relay pvc

The show frame-relay pvc [dlci] command in the privileged EXEC mode displays the statistics of a Frame Relay PVC referenced by its DLCI on a Cisco router. The dlci parameter is optional. If it is not supplied, the show frame-relay pvc command displays the information of all Frame Relay PVCs created on the router. Alternatively, there is a full version of the command that involves supplying the DLCI value of a particular Frame Relay PVC. The show frame-relay pvc dlci command displays more detailed information on the selected PVC. The additional information shown includes the CIR, Bc, Be, and MINCIR values; the status of shaping; the number of packets dropped by shaping; and the queuing strategy used. Example 5-11 illustrates the output of both versions of the show frame-relay pvc command executed on the routers in Figure 5-4.

Example 5-11. Sample Output of show frame-relay pvc Command at the Hub Router
RouterA#show frame-relay pvc

PVC Statistics for interface Serial3/0 (Frame Relay DTE)

              Active     Inactive      Deleted       Static
  Local          3            0            0            0
  Switched       0            0            0            0
  Unused         0            0            0            0

DLCI = 102, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial3/0.102

  input pkts 0             output pkts 0            in bytes 0
  out bytes 0              dropped pkts 0           in pkts dropped 0
  out pkts dropped 0                out bytes dropped 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
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
pvc create time 00:43:22, last time pvc status changed 00:43:02

DLCI = 103, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial3/0.102
  input pkts 0             output pkts 0            in bytes 0
  out bytes 0              dropped pkts 0           in pkts dropped 0
  out pkts dropped 0                out bytes dropped 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
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
pvc create time 00:43:32, last time pvc status changed 00:43:12

DLCI = 104, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial3/0.104

  input pkts 0             output pkts 1            in bytes 0
  out bytes 298            dropped pkts 0           in pkts dropped 0
  out pkts dropped 0                out bytes dropped 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
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
pvc create time 00:43:48, last time pvc status changed 00:41:58

RouterA#show frame-relay pvc 102

PVC Statistics for interface Serial3/0 (Frame Relay DTE)

DLCI = 102, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial3/0.102

  input pkts 0             output pkts 0            in bytes 0
  out bytes 0              dropped pkts 0           in pkts dropped 0
  out pkts dropped 0       out bytes dropped 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
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
  pvc create time 00:45:47, last time pvc status changed 00:45:27
  cir 32000     bc 4000      be 0         byte limit 500    interval 125
mincir 16000     byte increment 500   Adaptive Shaping none
  pkts 0         bytes 0         pkts delayed 0         bytes delayed 0
  shaping inactive
  traffic shaping drops 0
  Queueing strategy: fifo
Output queue 0/40, 0 drop, 0 dequeued

RouterA#show frame-relay pvc 103

PVC Statistics for interface Serial3/0 (Frame Relay DTE)

DLCI = 103, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial3/0.102

  input pkts 0             output pkts 0            in bytes 0
  out bytes 0              dropped pkts 0           in pkts dropped 0
  out pkts dropped 0       out bytes dropped 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
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
  pvc create time 00:45:50, last time pvc status changed 00:45:30
  cir 32000     bc 4000      be 0         byte limit 500    interval 125
  mincir 16000     byte increment 500   Adaptive Shaping none
  pkts 0         bytes 0         pkts delayed 0         bytes delayed 0
  shaping inactive
  traffic shaping drops 0
  Queueing strategy: fifo
Output queue 0/40, 0 drop, 0 dequeued

RouterA #show frame-relay pvc 104

PVC Statistics for interface Serial3/0 (Frame Relay DTE)

DLCI = 104, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial3/0.104

  input pkts 3             output pkts 3            in bytes 891
  out bytes 894            dropped pkts 0           in pkts dropped 0
  out pkts dropped 0                out bytes dropped 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 3         out bcast bytes 894
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
  pvc create time 00:45:52, last time pvc status changed 00:44:02
  cir 64000     bc 8000      be 0         byte limit 1000   interval 125
  mincir 32000     byte increment 1000  Adaptive Shaping none
  pkts 3         bytes 894       pkts delayed 0         bytes delayed 0
  shaping inactive
  traffic shaping drops 0
  Queueing strategy: fifo
Output queue 0/40, 0 drop, 0 dequeued

show traffic-shape

The show traffic-shape command in the user EXEC mode can be used to display interface-by-interface information of the traffic shaping rate configurations on the router. Refer to Example 5-12 for a sample output of this command, executed on router A in Figure 5-4.

Example 5-12. The show traffic-rate Command
RouterA#show traffic-shape

Interface   Se3/0.102
       Access Target    Byte   Sustain   Excess    Interval  Increment Adapt
VC     List   Rate      Limit  bits/int  bits/int  (ms)      (bytes)   Active
103           32000     500    4000      0         125       500       -
102           32000     500    4000      0         125       500       -

Interface   Se3/0.104
       Access Target    Byte   Sustain   Excess    Interval  Increment Adapt
VC     List   Rate      Limit  bits/int  bits/int  (ms)      (bytes)   Active
104           64000     1000   8000      0         125       1000      -

Figure 5-5 provides an explanation of the various fields that the show traffic-rate command displays.

Figure 5-5. Explanation of the Fields in show traffic-rate

Given the Frame Relay network setup in Figure 5-4 and the routers' configurations in Example 5-10, traffic streams are set up on the servers residing on the 192.168.1.0/24 subnet. The main objective in this section is to generate downstream traffic from the servers toward the spoke networks. Sufficient output traffic must be generated from the hub router entering the Frame Relay network to activate Frame Relay Traffic Shaping on the hub router.

Three individual traffic streams are set up on the servers with an initial rate of 24 kbps, 24 kbps, and 56 kbps. They are destined for router B, router C, and router D, respectively. On the hub router, recall that DLCI 102 and 103 have a CIR of 32 kbps each, and DLCI 104 has a CIR of 64 kbps. The traffic rate originating from the servers is stepped up to eventually cause congestion in the Frame Relay network and to activate Frame Relay Traffic Shaping on router A. The show frame-relay pvc dlci command is used to observe Frame Relay Traffic Shaping on the hub router A. Example 5-13 shows the output of the show frame-relay pvc command on router A before the traffic rate exceeds the traffic shaping threshold.

Example 5-13. Output of the show frame-relay pvc dlci Command After Traffic Ison, but Before Traffic Rate Reaches Shaping Threshold
RouterA#show frame-relay pvc 102

PVC Statistics for interface Serial3/0 (Frame Relay DTE)

DLCI = 102, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial3/0.102

  input pkts 0             output pkts 932          in bytes 0
  out bytes 932000         dropped pkts 0           in pkts dropped 0
  out pkts dropped 0                out bytes dropped 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
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute output rate 24000 bits/sec, 3 packets/sec
  pvc create time 01:10:51, last time pvc status changed 01:10:31
  cir 32000     bc 4000      be 0         byte limit 500    interval 125
  mincir 16000     byte increment 500   Adaptive Shaping none
  pkts 934       bytes 934000    pkts delayed 0         bytes delayed 0
  shaping inactive
  traffic shaping drops 0
  Queueing strategy: fifo
  Output queue 0/40, 0 drop, 5 dequeued

RouterA#show frame-relay pvc 103

PVC Statistics for interface Serial3/0 (Frame Relay DTE)

DLCI = 103, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial3/0.102

  input pkts 0             output pkts 1004         in bytes 0
  out bytes 1004000        dropped pkts 0           in pkts dropped 0
  out pkts dropped 0                out bytes dropped 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
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute output rate 24000 bits/sec, 3 packets/sec
  pvc create time 01:11:15, last time pvc status changed 01:10:55
  cir 32000     bc 4000      be 0         byte limit 500    interval 125
  mincir 16000     byte increment 500   Adaptive Shaping none
  pkts 1006      bytes 1006000   pkts delayed 0         bytes delayed 0
  shaping inactive
  traffic shaping drops 0
  Queueing strategy: fifo
Output queue 0/40, 0 drop, 0 dequeued

RouterA#show frame-relay pvc 104
PVC Statistics for interface Serial3/0 (Frame Relay DTE)

DLCI = 104, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial3/0.104

  input pkts 28            output pkts 2482         in bytes 8316
  out bytes 2462344        dropped pkts 0           in pkts dropped 0
  out pkts dropped 0                out bytes dropped 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 28        out bcast bytes 8344
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute output rate 56000 bits/sec, 7 packets/sec
  pvc create time 01:11:31, last time pvc status changed 01:09:41
  cir 64000     bc 8000      be 0         byte limit 1000   interval 125
  mincir 32000     byte increment 1000  Adaptive Shaping none
  pkts 2483      bytes 2463344   pkts delayed 5         bytes delayed 1490
  shaping inactive
  traffic shaping drops 0
  Queueing strategy: fifo
  Output queue 0/40, 0 drop, 5 dequeued

As seen in Example 5-13, the rate of the initial traffic streams is not sufficient to create congestion to activate Frame Relay Traffic Shaping on router A. To simulate congestion, the rate of the traffic streams originating from the servers has been increased dramatically to 40 kbps, 40 kbps, and 72 kbps (the aggregate output rate is 152 kbps). Example 5-14 shows the output of the show frame-relay pvc command on router A after the rate of the traffic streams has exceeded the traffic shaping thresholds.

Example 5-14. Output of the show frame-relay pvc dlci Command After Traffic Is on but Traffic Rate Has Exceeded Shaping Threshold
RouterA#show frame-relay pvc 102
PVC Statistics for interface Serial3/0 (Frame Relay DTE)

DLCI = 102, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial3/0.102

  input pkts 0             output pkts 2762         in bytes 0
  out bytes 2762000        dropped pkts 108         in pkts dropped 0
  out pkts dropped 108              out bytes dropped 108000
  late-dropped out pkts 108         late-dropped out bytes 108000
  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
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute output rate 32000 bits/sec, 4 packets/sec
  pvc create time 01:20:07, last time pvc status changed 01:19:47
  cir 32000     bc 4000      be 0         byte limit 500    interval 125
  mincir 16000     byte increment 500   Adaptive Shaping none
  pkts 2725      bytes 2725000   pkts delayed 590       bytes delayed 590000
  shaping active
  traffic shaping drops 0
  Queueing strategy: fifo
  Output queue 40/40, 109 drop, 594 dequeued

RouterA#show frame-relay pvc 103
PVC Statistics for interface Serial3/0 (Frame Relay DTE)

DLCI = 103, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial3/0.102

  input pkts 0             output pkts 2901         in bytes 0
  out bytes 2901000        dropped pkts 144         in pkts dropped 0
  out pkts dropped 144              out bytes dropped 144000
  late-dropped out pkts 144         late-dropped out bytes 144000
  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
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute output rate 32000 bits/sec, 4 packets/sec
  pvc create time 01:20:43, last time pvc status changed 01:20:23
  cir 32000     bc 4000      be 0         byte limit 500    interval 125
  mincir 16000     byte increment 500   Adaptive Shaping none
  pkts 2867      bytes 2867000   pkts delayed 732       bytes delayed 732000
  shaping active
  traffic shaping drops 0
  Queueing strategy: fifo
Output queue 39/40, 145 drop, 736 dequeued
RouterA#show frame-relay pvc 104
PVC Statistics for interface Serial3/0 (Frame Relay DTE)

DLCI = 104, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial3/0.104

  input pkts 38            output pkts 6674         in bytes 11286
  out bytes 6647324        dropped pkts 164         in pkts dropped 0
  out pkts dropped 164              out bytes dropped 164000
  late-dropped out pkts 164         late-dropped out bytes 164000
  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 38        out bcast bytes 11324
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute output rate 64000 bits/sec, 8 packets/sec
  pvc create time 01:21:03, last time pvc status changed 01:19:13
  cir 64000     bc 8000      be 0         byte limit 1000   interval 125
  mincir 32000     byte increment 1000  Adaptive Shaping none
  pkts 6642      bytes 6615324   pkts delayed 1639      bytes delayed 1628470
  shaping active
  traffic shaping drops 0
  Queueing strategy: fifo
Output queue 40/40, 166 drop, 1647 dequeued

Frame Relay Traffic Shaping is activated on a Frame Relay PVC when the rate of the traffic flow it carries exceeds the traffic shaping threshold configured for the DLCI. As shown in router A's show frame-relay pvc output in Example 5-14, Frame Relay Traffic Shaping is active on DLCI 102, 103, and 104 due to congestion. The active shaper has rate limited the output traffic rate on DLCI 102, 103, and 104 to 32 kbps, 32 kbps, and 64 kbps, respectively. In addition, the default FIFO queue on each DLCI is full, and incoming frames are dropped. Frame Relay Traffic Shaping supports other queuing strategies, such as custom queuing and priority queuing, which are discussed in depth in Part IV of this book. Finally, the effective aggregate output rate at the physical interface is smoothed at 128 kbps, as shown in Example 5-15.

Example 5-15. The Aggregate Output Rate at the Interface Level on Router A
RouterA#show interface s3/0
Serial3/0 is up, line protocol is up
  Hardware is M4T
  MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec,
     reliability 255/255, txload 21/255, rxload 1/255
  Encapsulation FRAME-RELAY, crc 16, loopback not set
  Keepalive set (10 sec)
  Restart-Delay is 0 secs
  LMI enq sent  816, LMI stat recvd 816, LMI upd recvd 0, DTE LMI up
  LMI enq recvd 0, LMI stat sent  0, LMI upd sent  0
  LMI DLCI 1023  LMI type is CISCO  frame relay DTE
  FR SVC disabled, LAPF state down
  Broadcast queue 0/64, broadcasts sent/dropped 136/0, interface broadcasts 0
  Last input 00:00:03, output 00:00:00, output hang never
  Last clearing of "show interface" counters 02:16:01
  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 18229
  Queueing strategy: fifo
  Output queue: 0/40 (size/max)
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute output rate 128000 bits/sec, 16 packets/sec
     952 packets input, 54264 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
     107834 packets output, 106933136 bytes, 0 underruns
     0 output errors, 0 collisions, 0 interface resets
     0 output buffer failures, 0 output buffers swapped out
     0 carrier transitions     DCD=up  DSR=up  DTR=up  RTS=up  CTS=up

NOTE

By using a different Frame Relay map class, the Frame Relay Traffic Shaping parameters can be set up differently on each DLCI.

Results of Throttling the Output Rate Dynamically

The Frame Relay Traffic Shaping rate can be throttled dynamically by changing the configurations in the Frame Relay map class. This can be performed even when there is active traffic flowing in the router. Frame Relay Traffic Shaping can respond to the new parameters and adjust its shaper rate accordingly. The hub router A in Figure 5-4 activates Frame Relay Traffic Shaping on a DLCI to perform rate enforcement when the output traffic rate reaches the CIR threshold for the DLCI. Even after you increase the aggregate rate of the traffic streams originating from the server, the router continues to maintain its interface output rate at 128 kbps.

At this point, an example is used to verify how Frame Relay Traffic Shaping can dynamically throttle its output rate. The original CIR value in the Frame Relay map class fast_vc is changed while the router is still sending out traffic. In the fast_vc map class that is associated with DLCI 104, the CIR value in the map class is reduced from the initial 64 kpbs to 56 kpbs. Example 5-16 shows that Frame Relay Traffic Shaping has throttled the output rate on DLCI 104, resulting in more packets being delayed and dropped.

Example 5-16. After the CIR Is Reduced Dynamically
RouterA#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
RouterA(config)#map-class frame-relay fast-vc
RouterA(config-map-class)#frame-relay cir 56000
RouterA#show frame-relay pvc 104

PVC Statistics for interface Serial3/0 (Frame Relay DTE)

DLCI = 104, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial3/0.104

  input pkts 151           output pkts 61227        in bytes 44847
  out bytes 61120998       dropped pkts 6971        in pkts dropped 0
  out pkts dropped 6971             out bytes dropped 6971000
  late-dropped out pkts 6971        late-dropped out bytes 6971000
  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 151       out bcast bytes 44998
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute output rate 56000 bits/sec, 7 packets/sec
  pvc create time 03:14:27, last time pvc status changed 03:12:37
  cir 56000     bc 8000      be 0         byte limit 1000   interval 142
  mincir 28000     byte increment 994   Adaptive Shaping none
  pkts 61121     bytes 61014998  pkts delayed 56118     bytes delayed 56028144
  shaping active
  traffic shaping drops 0
  Queueing strategy: fifo
Output queue 40/40, 7043 drop, 56125 dequeued

Verifying Regulation of Output Traffic Rate

This section describes how to verify that a Cisco router is able to regulate the output traffic rate according to the BECN or ForeSight congestion notifications. For the purpose of the verification, the Cisco IGX 8420 is now configured to manage network congestion using BECN flagged packets and timed ForeSight messages. The network diagram in Figure 5-4 has been modified slightly to look like the one shown in Figure 5-6.

Figure 5-6. Network Diagram for Monitoring Adaptive Shaping to BECN and ForeSight

An additional point-to-point VC (DLCI 501) is provisioned on the Frame Relay switch to connect between router A and router D. The hub router, router A, is configured to use adaptive shaping to BECN on DLCI 104 and adaptive shaping to ForeSight on DLCI 105, both under the same main interface. A server on router A's 199.0.0.0/24 subnet is set up to send a traffic stream to router A on each DLCI with an aggregate rate of 128 kbps. On the hub router A, the CIR in the Frame Relay map class is configured at 128 kbps, equivalent to the physical line speed of the access circuit connected to the Frame Relay switch. However, the true CIR provisioned on the Frame Relay switch for each PVC is 64 kpbs. Hence, the MINCIR value is configured at 64000 in the Frame Relay map-class setup for each VC. This arrangement mimics an oversubscription scenario where the switch allocates a bandwidth of 64 kbps to each VC, but the Frame Relay users send long bursts of data at a rate very close to the physical line speed. Example 5-17 shows the running configurations of Router A.

Example 5-17. Running Configurations for Router A
RouterA#show running-config
Building configuration...

Current configuration : 3420 bytes
<output omitted>
!
interface Ethernet1/2
 ip address 199.0.0.2 255.255.255.0
!
interface Serial6/1
 no ip address
 encapsulation frame-relay
 frame-relay traffic-shaping
!
interface Serial6/1.401 point-to-point
 ip address 192.168.1.1 255.255.255.252
 frame-relay interface-dlci 401
  class fast_vc_foresight
!
interface Serial6/1.501 point-to-point
 ip address 192.168.2.1 255.255.255.252
frame-relay interface-dlci 501
  class fast_vc_BECN
!
map-class frame-relay fast_vc_foresight
 frame-relay cir 128000
 frame-relay bc 16000
 frame-relay be 0
 frame-relay mincir 64000
 frame-relay adaptive-shaping foresight
!
map-class frame-relay fast_vc_BECN
 frame-relay cir 128000
 frame-relay bc 16000
 frame-relay be 0
 frame-relay mincir 64000
 frame-relay adaptive-shaping becn

Shortly after all traffic streams are sent out from the servers, the output rate at router A builds up rapidly. During a period of sustained congestion such the one introduced in this example, the router regulates its output traffic rate and discards any packets unable to be sent out or queued. With adaptive shaping to BECN or ForeSight enabled, a Cisco router dynamically reduces its output traffic rate by a large amount for every BECN tagged packet or timed ForeSight message received from the Frame Relay switch. The output rate falls substantially when adaptive shaping becomes active but the output rate does not drop below the configured MINCIR value (which is incidentally set to the true CIR value configured on the Frame Relay switch). After a time interval where the router detects no congestion (by not hearing it), the router starts to increase its output rate by a small increment. Example 5-18 shows the output of the following commands: show frame-relay pvc, show interface, and show traffic-shape at router A.

Example 5-18. Output of the Various show Commands
RouterA#show frame-relay pvc 401

PVC Statistics for interface Serial6/1 (Frame Relay DTE)

DLCI = 401, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial6/1.401

  input pkts 2138          output pkts 25249        in bytes 141127
  out bytes 25206155       dropped pkts 9581        in FECN pkts 0
  in BECN pkts 93          out FECN pkts 0          out BECN pkts 0
  in DE pkts 0             out DE pkts 0
  out bcast pkts 55        out bcast bytes 16635
  Shaping adapts to ForeSight        in ForeSight signals 606
  pvc create time 00:54:14, last time pvc status changed 00:08:14
  cir 128000    bc 16000     be 0         byte limit 2000   interval 125
  mincir 64000     byte increment 1125  Adaptive Shaping F/S
  pkts 15611     bytes 15568155  pkts delayed 15532     bytes delayed 15513904
  shaping active
  traffic shaping drops 0
  Queueing strategy: fifo
Output queue 40/40, 9598 drop, 15532 dequeued

RouterA#show frame-relay pvc 501

PVC Statistics for interface Serial6/1 (Frame Relay DTE)

DLCI = 501, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial6/1.501

  input pkts 2308          output pkts 10031        in bytes 151508
  out bytes 9991964        dropped pkts 3783        in FECN pkts 0
  in BECN pkts 278         out FECN pkts 0          out BECN pkts 0
  in DE pkts 0             out DE pkts 0
  out bcast pkts 56        out bcast bytes 16964
  Shaping adapts to BECN
  pvc create time 00:55:40, last time pvc status changed 00:09:40
  cir 128000    bc 16000     be 0         byte limit 2000   interval 125
  mincir 64000     byte increment 1375  Adaptive Shaping BECN
  pkts 6201      bytes 6161964   pkts delayed 6122      bytes delayed 6115040
  shaping active
  traffic shaping drops 0
  Queueing strategy: fifo
Output queue 40/40, 3790 drop, 6122 dequeued

RouterA#show traffic-shape

Interface   Se6/1.401
       Access Target    Byte   Sustain   Excess    Interval  Increment Adapt
VC     List   Rate      Limit  bits/int  bits/int  (ms)      (bytes)   Active
401           128000    2000   16000     0         125       1625      F/S

Interface   Se6/1.501
       Access Target    Byte   Sustain   Excess    Interval  Increment Adapt
VC     List   Rate      Limit  bits/int  bits/int  (ms)      (bytes)   Active
501           128000    2000   16000     0         125       1000      BECN
RouterA#

RouterA#show interface s6/1
Serial6/1 is up, line protocol is up
  Hardware is M4T
  MTU 1500 bytes, BW 2048 Kbit, DLY 20000 usec,
     reliability 255/255, txload 19/255, rxload 1/255
  Encapsulation FRAME-RELAY, crc 16, loopback not set
  Keepalive set (10 sec)
  LMI enq sent  762, LMI stat recvd 763, LMI upd recvd 0, DTE LMI up
  LMI enq recvd 0, LMI stat sent  0, LMI upd sent  0
  LMI DLCI 1023  LMI type is CISCO  frame relay DTE
  FR SVC disabled, LAPF state down
  Broadcast queue 0/64, broadcasts sent/dropped 256/4234, interface broadcasts 0
  Last input 00:00:00, output 00:00:00, output hang never
  Last clearing of "show interface" counters 02:07:11
  Queueing strategy: fifo
  Output queue 0/40, 32424 drops; input queue 0/75, 0 drops
  1 minute input rate 3000 bits/sec, 13 packets/sec
  1 minute output rate 157000 bits/sec, 20 packets/sec
     90330 packets input, 2286028 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
     61070 packets output, 60123100 bytes, 0 underruns
     0 output errors, 0 collisions, 3 interface resets
     0 output buffer failures, 0 output buffers swapped out
     3 carrier transitions     DCD=up  DSR=up  DTR=up  RTS=up  CTS=up

The show interface command output (interface serial6/1) shown in the previous example indicates that the combined output traffic rate is now regulated at just about 156 kbps, dropped from the burst rate of 256 kbps (128 kbps x 2 DLCI). The aggregate CIR for both VCs on the line is 128 kbps. The controlled traffic rate is very close to the actual combined CIR allocated for both DLCIs on the Frame Relay switch. This verifies that both adaptive shaping to BECN and ForeSight are functioning properly when configured under the same main interface.

In Example 5-19, the traffic stream on DLCI 501 is turned off, and the output traffic rate on DLCI 401 is reduced to approximately 48 kbps, below the true CIR allocated on the Frame Relay switch. With this lower traffic rate, both Frame Relay Traffic Shaping and adaptive shaping to ForeSight are inactive.

Example 5-19. Frame Relay Traffic Shaping Is Inactive When Throughput Is Lower Than CIR
RouterA#show interface serial 6/1
Serial6/1 is up, line protocol is up
  Hardware is M4T
  MTU 1500 bytes, BW 2048 Kbit, DLY 20000 usec,
     reliability 255/255, txload 5/255, rxload 1/255
  Encapsulation FRAME-RELAY, crc 16, loopback not set
  Keepalive set (10 sec)
  LMI enq sent  1, LMI stat recvd 1, LMI upd recvd 0, DTE LMI up
  LMI enq recvd 0, LMI stat sent  0, LMI upd sent  0
  LMI DLCI 1023  LMI type is CISCO  frame relay DTE
  FR SVC disabled, LAPF state down
  Broadcast queue 0/64, broadcasts sent/dropped 0/0, interface broadcasts 0
  Last input 00:00:00, output 00:00:00, output hang never
  Last clearing of "show interface" counters 00:00:13
  Queueing strategy: fifo
  Output queue 0/40, 0 drops; input queue 0/75, 0 drops
  1 minute input rate 2000 bits/sec, 11 packets/sec
  1 minute output rate 48000 bits/sec, 6 packets/sec
     163 packets input, 4335 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
     90 packets output, 88026 bytes, 0 underruns
     0 output errors, 0 collisions, 0 interface resets
     0 output buffer failures, 0 output buffers swapped out
     0 carrier transitions     DCD=up  DSR=up  DTR=up  RTS=up  CTS=up

RouterA#show frame-relay pvc 401

PVC Statistics for interface Serial6/1 (Frame Relay DTE)

DLCI = 401, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial6/1.401

  input pkts 116           output pkts 690          in bytes 7420
  out bytes 688608         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 2         out bcast bytes 608
  Shaping adapts to ForeSight        in ForeSight signals 0
  pvc create time 02:14:00, last time pvc status changed 00:04:00
  cir 128000    bc 16000     be 0         byte limit 2000   interval 125
  mincir 64000     byte increment 1000  Adaptive Shaping F/S
  pkts 690       bytes 688608    pkts delayed 0         bytes delayed 0
  shaping inactive
  traffic shaping drops 0
  Queueing strategy: fifo
  Output queue 0/40, 0 drop, 0 dequeued

When debugging adaptive shaping to ForeSight, you can use the debug frame-relay foresight debug command to monitor the received ForeSight messages on the router. This is shown in example 5-20.

Example 5-20. Using debug frame-relay foresight Command to Monitor Adaptive Shaping to ForeSight
Router#debug frame-relay foresight
02:39:50: FR rate control for DLCI 401 due to ForeSight msg
02:39:50: FR rate control for DLCI 401 due to ForeSight msg
02:39:50: FR rate control for DLCI 401 due to ForeSight msg
02:39:56: FR rate control for DLCI 401 due to ForeSight msg
02:40:02: FR rate control for DLCI 401 due to ForeSight msg
02:40:02: FR rate control for DLCI 401 due to ForeSight msg
02:40:08: FR rate control for DLCI 401 due to ForeSight msg
02:40:09: FR rate control for DLCI 401 due to ForeSight msg

The next section looks at several optional configuration commands for working with the Frame Relay Traffic Shaping feature.


Configuring Discard Eligibility (DE)

The users can opt to specify which Frame Relay packets should have a lower priority or time sensitivity and should be subjected to be dropped when the Frame Relay switch experiences congestion. The Discard Eligibility (DE) mechanism allows the Frame Relay switch to identify packets that can be dropped during network congestion. This command assumes that the Frame Relay switch is able to detect and recognize the DE bit and to take action accordingly. Some Frame Relay switches are unable to interpret the DE bit and will do no action.

Use the frame-relay de-list global configuration command to define a DE list specifying the packets that have the DE bit set and thus are eligible for discarding when congestion is experienced on the Frame Relay switch.

[View full width]

Router(config)#frame-relay de-list list-number {protocol protocol | interface type number}
   characteristic

To delete a portion of a previously defined DE list, use the no form of this command. Table 5-2 lists the supported protocols and characteristics of the packet that can be used for classification.

Table 5-2. Syntax Description of frame-relay de-list Command

Syntax

Description

Protocol

arp Address Resolution Protocol

apollo Apollo Domain

appletalk AppleTalk

bridge bridging device

clns ISO Connectionless Network Service

clns_es CLNS end systems

clns_is CLNS intermediate systems

compressedtcp Compressed Transmission Control Protocol (TCP)

decent DECnet

decnet_node DECnet end node

decnet_router-L1 DECnet Level 1 (intraarea) router

decnet_router-L2 DECnet Level 2 (interarea) router

ip Internet Protocol

ipx Novell Internet Packet Exchange Protocol

vines Banyan VINES

xns Xerox Network Systems

Characteristic

fragments Fragmented IP packets

tcp port TCP packets to or from a specified port

udp port User Datagram Protocol (UDP) packets to or from a specified port

list access-list-number Previously defined access list number

gt bytes Sets the DE bit for packets larger than the specified number of bytes (including the 4-byte Frame Relay encapsulation)

lt bytes Sets the DE bit for packets smaller than the specified number of bytes (including the 4-byte Frame Relay encapsulation)

A DE list can be defined based on the protocol or the interface and on characteristics such as fragmentation of the packet, a specific TCP or UDP port, an access list number, or a packet size. After setting up the DE list, use the frame-relay de-group command to assign the DE list to a specified DLCI on the interface.

Router(config-if)#frame-relay de-group group-number dlci

Example 5-21 shows a configuration example creating a DE list based on IP protocol and packet size greater than 1500 bytes. Then the DE list is assigned to DLCI 200 on a serial interface.

Example 5-21. Configuration Example Assigning a DE List
Router(config)#frame-relay de-list 1 protocol ip gt 1500
Router(config)#inter serial4/2
Router(config-if)#frame-relay de-group 1 200


Configuring Frame Relay Broadcast Queue

On very large hub-and-spoke Frame Relay networks where several hundreds of branch sites terminate their DLCIs in the central site, it is highly possible to run into performance degradation issues. There is a significant amount of broadcast traffic generated if routing protocol updates or IPX service advertising updates must be replicated on each DLCI at the hub router. The broadcast traffic can consume access-link bandwidth and cause significant latency variation in user traffic; the updates can also consume interface buffers and lead to higher packet loss for both user data and routing updates.

To avoid these problems, Cisco supports a Frame Relay broadcast queue at the interface level to create a special queue for a specified interface to hold broadcast traffic that has been replicated for transmission on multiple DLCIs. The Frame Relay broadcast queue is created independently of other queues with its own buffers and has a configurable size and service rate.

A broadcast queue is given a maximum transmission rate (throughput) limit measured in bytes per second and packets per second. The queue is serviced to ensure that only this maximum is provided. The broadcast queue has priority when transmitting at a rate below the configured maximum and therefore has a guaranteed minimum bandwidth allocation. The two transmission rate limits are intended to avoid flooding the interface with broadcasts. The actual limit in any second is the first rate limit that is reached.

To configure a broadcast queue for a Frame Relay interface, perform the following command, beginning in the interface configuration mode:

Router(config-if)#frame-relay broadcast-queue size byte-rate packet-rate

Example 5-22 shows a configuration example creating a Frame Relay broadcast queue.

Example 5-22. Creating a Frame Relay Broadcast Queue
Router#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router(config)#interface serial4/2
Router(config-if)#frame-relay broadcast-queue ?
  <1-65535>  Queue size for broadcasts, <cr> to set default values
  <cr>
Router(config-if)#frame-relay broadcast-queue 20 ?
  <1000-8000000>  Byte rate per sec. for broadcasts transmission

Router(config-if)#frame-relay broadcast-queue 20 1000 ?
  <1-80000>  Max. packets/S broadcasts transmission

Router(config-if)#frame-relay broadcast-queue 20 1000 1000 ?
  <cr>

Router(config-if)#frame-relay broadcast-queue 20 1000 1000


Configuring DLCI Priority Levels

DLCI priority level is a legacy traffic management tool that allows users to prioritize multiple parallel Frame Relay DLCIs based on the types of Frame Relay traffic that are carried. DLCI priority level can be used to alleviate congestion for certain types of traffic by allowing users to define different DLCIs for different categories of traffic based on traffic priorities. For example, DLCI priority level is useful in situations in which delay-sensitive traffic is mixed with non-real-time traffic. In such a case, the delay-sensitive traffic can be assigned to the high-priority DLCI level.

It is important to highlight that the DLCI priority level command requires the DLCIs used to be parallel. The source and destination endpoints of the multiple DLCIs must be the same. The command should be applied to Frame Relay multipoint subinterfaces so that more than one DLCI can be assigned. In addition, the DLCI priority level command is not associated with priority queuing, but the command can be used together with priority queuing.

To configure DLCI priority levels, perform the following configuration command in interface configuration mode:

[View full width]

Router(config-if)#frame-relay priority-dlci-group group-number high-dlci medium-dlci
   normal-dlci low-dlci

NOTE

If a DLCI is not explicitly specified for each of the priority levels, the last DLCI specified in the command line is used as the value of the remaining arguments. At a minimum, you are required to configure the high-priority and medium-priority DLCIs.


Differences Between Frame Relay Traffic Shaping and Generic Traffic Shaping

This section explains the differences between generic traffic shaping and Frame Relay Traffic Shaping. Generic traffic shaping shapes traffic by reducing outbound traffic flow to avoid congestion. Generic traffic shaping is applied on a per-interface basis, and access lists can be used to selectively filter the type of traffic to shape. Generic traffic shaping works with Frame Relay, ATM, Switched Multimegabit Data Service (SMDS), and Ethernet. Both generic traffic shaping and Frame Relay Traffic Shaping are similar in implementation, but there are some notable differences. Generic traffic shaping mainly differs from Frame Relay Traffic Shaping with regard to CLI configuration and the queue types used. Table 5-3 sums up the differences between generic traffic shaping and Frame Relay Traffic Shaping.

Table 5-3. Differences Between GTS and FRTS

Mechanism

Generic Traffic Shaping

Frame Relay Traffic Shaping

CLI

Applies parameters on a per-interface basis

traffic group command used

Classes of parameters configured in map class

Applies parameters to all VCs on an interface through inheritance

No traffic group command supported

Queues supported

Weighted Fair Queuing (WFQ) per subinterface

Weighted Fair Queuing (WFQ), Priority Queuing, Custom Queuing, First-In-First-Out (FIFO) per VC supported


Summary

This chapter focused on the Cisco IOS Frame Relay Traffic Shaping feature and discussed its role and function as a traffic and congestion management tool in depth. The Frame Relay Traffic Shaping feature is composed of different components. Frame Relay Traffic Shaping supports rate enforcement of network traffic based on user-defined CIR, per-VC queuing (default FIFO, PQ, and CQ), and adaptive shaping to BECN and ForeSight.

This chapter also introduced and explained the configuration steps and commands for enabling Frame Relay Traffic Shaping on a Cisco router. Practical examples were used to demonstrate Frame Relay Traffic Shaping and adaptive shaping. Additionally, this chapter explained the Cisco IOS show and debug commands for monitoring and troubleshooting Frame Relay Traffic Shaping. At the end of this chapter, two case studies based on implementing Frame Relay Traffic Shaping will be presented.

In the next chapter, the Frame Relay Switching Enhancements feature will be discussed in detail. Frame Relay Switching Enhancements is an important feature that provides switching capabilities for a traditional Cisco router.


Review Questions

1: | Name and explain the algorithm that Frame Relay Traffic Shaping uses to perform rate enforcement of traffic.
2: | Identify the queuing components supported by Frame Relay Traffic Shaping.
3: | Explain the method to set up different traffic shaping parameters for different Frame Relay PVCs.
4: | Explain the main differences between adaptive shaping to BECN and adaptive shaping to ForeSight.


Reference

Cisco IOS Release 12.2 Wide Area Network Command Reference: http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/fwan_r/frcmds/index.htm


Case Study: Managing Data Traffic

A local grocery chain store in Japan has six office locations connected by traditional leased line circuits. It runs mostly e-mail, billing data, and data warehousing traffic over its network. The chain has rapidly grown in the past two years. It expects to expand its operation to four other locations within the next six months. The IT director faces a dilemma, because she needs to purchase 30 additional long-haul leased circuits from her provider to connect the current offices to the new offices. A fully meshed network between all 10 locations requires 45 point-to-point physical leased circuits.

Fortunately, the service provider's consultant offered an alternative solution to migrate the chain store's current leased line circuit to a physical hub-and-spoke Frame Relay network. He argued that the proposed hub-and-spoke Frame Relay would reduce recurring costs and minimize bandwidth tariffs in the long run. Setting up a fully meshed topology between all sites would still require 45 logical Frame Relay PVCs to be provisioned, but the company would need to maintain only 10 physical leased circuits. Moreover, this is a more scalable solution if more sites are to be added in the future. Figure 5-7 shows the new hub-and-spoke Frame Relay network. The running configurations of the hub router and a typical spoke router are shown in Example 5-23. A 64-kbps CIR is allocated for each point-to-point VC.

Example 5-23. Running Configurations of the Hub Router and a Typical Spoke
Hub router:

   <output omitted>
   hostname Tokyo
   !
   interface serial1
    no ip address
    encapsulation frame-relay
    frame-relay traffic-shaping
   !
   interface serial1.100 point-to-point
    description Connected to Abiko office
    ip address 172.16.1.1 255.255.255.252
    frame-relay interface-dlci 100
     class central_office
   !
   interface serial1.101 point-to-point
    description Connected to Chiba office
    ip address 172.16.1.5 255.255.255.252
    frame-relay interface-dlci 101
     class central_office
   !
   interface serial1.102 point-to-point
    description Connected to Fuji office
    ip address 172.16.1.9 255.255.255.252
    frame-relay interface-dlci 102
     class central_office
   !
   interface serial1.103 point-to-point
    description Connected to Fukui office
    ip address 172.16.1.13 255.255.255.252
    frame-relay interface-dlci 103
     class central_office
   !
   interface serial1.104 point-to-point
    description Connected to Sapporo office
    ip address 172.16.1.17 255.255.255.252
    frame-relay interface-dlci 104
     class central_office
   !
   interface serial1.105 point-to-point
    description Connected to Kanagi office
    ip address 172.16.1.21 255.255.255.252
    frame-relay interface-dlci 105
     class central_office
   !
   interface serial1.106 point-to-point
    description Connected to Hakuba office
    ip address 172.16.1.25 255.255.255.252
    frame-relay interface-dlci 106
     class central_office
   !
   interface serial1.107 point-to-point
    description Connected to Joge office
    ip address 172.16.1.29 255.255.255.252
    frame-relay interface-dlci 107
     class central_office
   !
   interface serial1.108 point-to-point
    description Connected to Izumo office
    ip address 172.16.1.33 255.255.255.252
    frame-relay interface-dlci 108
     class central_office
   !
   !
   map-class central_office
    frame-relay adaptive-shaping becn
    frame-relay cir 128000
    frame-relay bc 16000
    frame-relay be 0
    frame-relay mincir 64000

   Typical spoke:

   <output omitted>
   hostname Abiko
   !
   interface serial1
    no ip address
    encapsulation frame-relay
    no fair-queue
    frame-relay traffic-shaping
   !
   interface serial1.100 point-to-point
    description Connected to Tokyo Head Office
    ip address 172.16.1.2 255.255.255.252
    frame-relay interface-dlci 100
     class branch_office
   !
   map-class branch_office
    frame-relay adaptive-shaping becn
    frame-relay cir 128000
    frame-relay bc 16000
    frame-relay be 0
    frame-relay mincir 64000
   !
   ip route 0.0.0.0 0.0.0.0 172.16.1.1

Figure 5-7. Japanese Grocery Chain Store Network Topology

Previous Page
Next Page


Case Study: A Small Hub-and-Spoke Network Running Voice and Video Traffic

A small law firm in California has its main operations headquartered in San Francisco. It has three other branch offices located in San Jose, Anaheim, and Sacramento. All four locations are connected on a partially meshed topology with the hub site situated in San Francisco. The sites are connected to a national Frame Relay network on T1 line circuits.

Recently, the law firm has decided to add Polycom units to its premises to allow IP voice and video conferencing between its associates stationed at its various offices. The law firm did not face any problem before when running data alone on its network, but it is now experiencing many problems in network latency and jitters. The quality of the IP voice and video conferencing is so unacceptable that the firm is thinking of abandoning the whole idea altogether. Fortunately, the IT manager has decided to hire a consultant to look into the possibility of salvaging this dire situation.

You, the consultant, are completely aware that the added voice/video traffic has caused considerable congestion to the network. Traffic shaping has to be implemented to ease the congestion and improve the quality of service. As you know, for QoS to work properly, the transmitting router needs to have an accurate understanding of the real-time bandwidth to the receiver. Traffic shaping provides that feedback. In conjunction with timely BECN feedback from the Frame Relay switches, the customer does not need to give up the ability to burst. The law firm's network diagram is shown in Figure 5-8. The sample running configurations of the routers are shown in Example 5-24.

Figure 5-8. Network Diagram of the Small Law Firm

Note that this example applies Cisco's Low Latency Queuing (LLQ) in association with Frame Relay Traffic Shaping. To explain in a few words, LLQ is a form of queuing strategy implemented by Cisco that applies strict priority queuing for a specified type of traffic (voice/video traffic in this example) and weighted fair queues for other classes of traffic. LLQ and its use will be explained in greater detail in the QoS chapters in Part IV of this book.

Before the consultant was hired to reconfigure the network, video and voice conferencing was unreliable. After the proposed implementation, the law firm has yet to see a single dropped packet on its network.

Example 5-24. Running Configurations of the Routers in the Small Law Firm
Hub router at San Francisco:

   ! Class map IP video for Polycom units precedence 4
   class-map match-all video
     match access-group 101
   !
   ! Policy Map for IP Video for Polycom Units
   policy-map IPVC
     class video
       priority 420
     class class-default
       fair-queue
   !
   interface Serial0/0
    description connection to Frame Relay carrier
    no ip address
    encapsulation frame-relay
    load-interval 30
    no fair-queue
    frame-relay traffic-shaping
   !
   interface Serial0/0.1 point-to-point
    description Frame Relay line to San Jose
    ip address 192.168.31.5 255.255.255.252
    frame-relay interface-dlci 101
     class voice_adaptive
   !
   interface Serial0/0.2 point-to-point
    description Frame Relay line to Sacramento
    ip address 192.168.31.9 255.255.255.252
    frame-relay interface-dlci 102
     class voice_adaptive
   !
   interface Serial0/0.3 point-to-point
    description Frame Relay line to Anaheim
    ip address 192.168.31.21 255.255.255.252
    frame-relay interface-dlci 103
     class voice_adaptive
   !
   map-class frame-relay voice_adaptive
    frame-relay adaptive-shaping becn
    frame-relay cir 1536000
    frame-relay mincir 512000
    service-policy output IPVC
   !
   access-list 101 permit ip any any precedence flash-override

   Typical remote:

   ! Class map IP video for Polycom units precedence 4
   class-map match-all video
     match access-group 101
   !
   ! Policy Map for IP Video for Polycom Units
   policy-map IPVC
     class video
       priority 420
     class class-default
       fair-queue
   !
   interface Serial0/0
    no ip address
    encapsulation frame-relay
    no fair-queue
    frame-relay traffic-shaping
    frame-relay lmi-type ansi
   !
   interface Serial0/0.1 point-to-point
    description Frame Relay line to national carrier
    ip address 192.168.31.10 255.255.255.252
    frame-relay interface-dlci 101
     class voice_adaptive
   !
   map-class frame-relay voice_adaptive
    frame-relay adaptive-shaping becn
    frame-relay cir 1536000
    frame-relay mincir 512000
    service-policy output IPVC
   !
   access-list 101 permit ip any any precedence flash-override


Chapter 6. Cisco Frame Relay Switching Enhancements

The Cisco Frame Relay Switching Enhancements feature is composed of a suite of functionalities specifically developed by Cisco to allow a traditional Cisco router to function as a Frame Relay switch in a Frame Relay network. Collectively, the functionalities in the feature provide conventional routers with the true switching capabilities of full-featured commercial Frame Relay switches.

This chapter discusses the configuration tasks required to enable the Frame Relay Switching Enhancements functionalities on a Cisco router. Detailed configuration examples are presented to illustrate the points. Later in the chapter, the various Cisco IOS show commands for monitoring and verifying Frame Relay Switching Enhancements information on a Cisco router will be explained based on examples from production Frame Relay networks.

The topics and questions that this chapter addresses include the following:

  • Detailed overview of the Frame Relay Switching Enhancements feature

  • Frame Relay Traffic Shaping over switched permanent virtual circuit (PVC) and Frame Relay switching over ISDN

  • Frame Relay traffic policing on a User-to-Network Interface (UNI) Data Circuit-Terminating Equipment (DCE) interface

  • Congestion management on switched PVC

  • Configuring Frame Relay switching for switched PVC on serial and ISDN BRI interfaces

  • Configuring Frame Relay congestion management

  • Monitoring and verifying Frame Relay Switching Enhancements feature

After completing this chapter, readers will be able to understand the functionalities of the Frame Relay Switching Enhancements feature and its associated benefits. Readers will learn to configure the Frame Relay Switching Enhancement functionalities on a Cisco router with the Cisco IOS software. You will also be able to perform maintenance and troubleshooting of the Frame Relay Switching Enhancement configurations on a Cisco router using the relevant Cisco IOS show commands.


Current Issues

Before the development of the Cisco Frame Relay Switching Enhancements feature, most conventional routers in the market were incapable of performing the roles of specialized Frame Relay switches. Conventional routers lacked the functionality to control network congestion and to police ingress traffic on permanent virtual circuits. Consequently, many customers, especially enterprise corporations and service providers, requested a more scalable and reliable Frame Relay switching solution. The requested features are in addition to the existing Frame Relay switching functionalities available in the Cisco IOS. Customers sought a solution that allows a router to be used as a Frame Relay switch, coupled with the ability to switch PVC over ISDN. The feature should also provide a router with the capability to police ingress network traffic on the PVC and set the FECN and BECN bits in the frame headers to notify of a congestion condition on the Frame Relay network.


Solutions to Current Issues

Cisco developed the Frame Relay Switching Enhancements feature in 1999 to provide a Cisco router with the true switching functionalities of Frame Relay switches in a Frame Relay network.

NOTE

Released in IOS Software Release 12.1(2)T, the feature is supported on Cisco platform series 1600, 2500, 2600, 3600, 4000, 7200, and 7500 (nondistributed mode).

The solution answers the calls from customers who want to deploy a Cisco router as a Frame Relay switch at the front end of a Frame Relay network. The following section describes Frame Relay Switching Enhancements in detail.

Frame Relay Switching Enhancements

Before the Frame Relay Switching Enhancements feature was developed, conventional routers had very limited Frame Relay switching functionalities. With the Frame Relay Switching Enhancements feature, a Cisco router can be used as a virtual Frame Relay switch with switching capabilities similar to a full-featured Frame Relay switch. The Frame Relay Switching Enhancements feature consists of the following functionalities, which are subsequently described in more detail in this section:

  • Frame Relay Traffic Shaping on switched PVC

  • Frame Relay switching over ISDN B channels

  • Basic policingtraffic policing on UNI DCE

  • Congestion management on switched PVCs

Frame Relay Traffic Shaping on Switched PVC

The Frame Relay switching feature provides a Cisco router with the new ability to apply the existing Frame Relay Traffic Shaping feature on switched PVCs. Supporting Frame Relay Traffic Shaping on switched PVCs allows a Cisco router to be used as a Frame Relay port concentrator, which is typically placed before a Frame Relay switch in the Frame Relay network. See Figure 6-1 for an illustration of how a Frame Relay port concentrator is typically deployed in a Frame Relay network.

Figure 6-1. Cisco Router Used as a Frame Relay Port Concentrator

As shown in the figure, the router configured as a Frame Relay switch is generally positioned at a central location and is typically connected to multiple spoke routers. In this arrangement, the router acts as a port concentrator and switches the PVCs between the spoke routers and the Frame Relay switch. When Frame Relay Traffic Shaping is configured on the switched PVC, the ingress traffic from the spokes is shaped before it enters the Frame Relay network. If adaptive shaping mechanisms are configured, the Frame Relay port concentrator can react to BECN and ForeSight messages on a per-PVC basis.

Frame Relay Switching over ISDN B Channels

The Frame Relay Switching Enhancements feature allows Cisco routers to transport Frame Relay over ISDN lines. Supporting Frame Relay over ISDN allows small offices' connections to be aggregated by the larger central offices instead of connecting each small location directly to the core network. In this way, the hub router at the central offices acts as a Frame Relay switch, switching Frame Relay between ISDN and serial interfaces. This is shown in Figure 6-2.

Figure 6-2. Using Frame Relay over ISDN

[View full size image]

To allow Frame Relay to be transported over ISDN, the Frame Relay Switching Enhancements feature supports the following new functionalities:

  • Local Management Interface (LMI) LMI is supported on ISDN Frame Relay DCE interfaces. Previously, LMI was supported only on Frame Relay DCE serial interfaces. Now, LMI is supported on both ISDN Basic Rate Interface (BRI) and Primary Rate Interface (PRI). LMI is primarily used to exchange status enquiry messages between Frame Relay devices.

  • PRI/BRI PRI and BRI can use a combination of switched PVCs and terminated PVCs.

  • Leased-Line ISDN and Switched ISDN Frame Relay switching supports both leased-line ISDN and switched ISDN. In leased-line ISDN, the Bearer (B) channel is permanently connected, whereas in switched ISDN, the B channels are dynamically set up and torn down.

Basic PolicingTraffic Policing on UNI DCE

The Frame Relay Switching Enhancements feature enables a router to police ingress network traffic on incoming switched PVCs. As such, network operators can make certain that their users' traffic adheres to their service contract. The major difference between Frame Relay Traffic Shaping and Frame Relay policing is that Frame Relay Traffic Shaping affects outgoing PVC traffic, whereas Frame Relay policing affects incoming PVC traffic. Frame Relay Traffic Shaping also queues traffic and delivers it smoothly into the Frame Relay network. On the other hand, Frame Relay policing does not perform any queuing, and it discards excess traffic at the ingress point when the allowed traffic rate threshold is exceeded. When Frame Relay policing is configured on an ingress interface, it prevents network congestion by discarding or setting the Discard Eligibility (DE) bit on packets that have exceeded the specified traffic policing parameters. Frame Relay policing acts on incoming traffic and is configured on the UNI DCE interface.

Similar to Frame Relay Traffic Shaping, Frame Relay policing uses the Frame Relay traffic parameters committed information rate (CIR), committed burst (Bc), excess burst (Be), and time interval (Tc) in a Frame Relay map class to control the policing rates.

Congestion Management on Switched PVCs

The Frame Relay Switching Enhancements feature allows a router in a Frame Relay network to manage network congestion on a per-PVC basis. This congestion management is bidirectional. When Frame Relay congestion management is enabled on the switched PVCs, the router sets the FECN and BECN bits in the Frame Relay headers when it is experiencing network congestion. When a switched PVC or output interface is congested, all frames traveling in the direction of congestion are marked with the FECN bit, while all frames traversing in the reverse direction are marked with the BECN bit. When the frames eventually reach a user device at the end of the network, the user device can react to the ECN bits and adjust its traffic rate accordingly. This assumes that the end user device is capable of performing rate adjustment after it detects the ECN bits in the Frame Relay headers.

A Cisco router enabled with congestion management can be configured to discard packets marked with the DE bit. When the traffic rate has exceeded a defined level of congestion, the router can be configured to discard all incoming packets marked with the DE bit set.

Two levels of congestion management can be configured on the router. First, congestion management can be applied to an individual switched PVC transmitting in excess of its CIR. The second level allows congestion management to be applied to all switched PVCs created at the interface.

NOTE

It is important to note that the Frame Relay Switching Enhancements feature does not support Frame Relay subinterfaces. Additionally, the Frame Relay Traffic Shaping on switched PVC functionality does not allow priority queuing and custom queuing to be used. The default queuing mechanism used is First-In-First-Out (FIFO) queuing.


Configuring Frame Relay Switching Enhancements on a Cisco Router

The following section explains the configuration commands for enabling the Frame Relay Switching Enhancements feature on a Cisco router. The configuration tasks needed to enable the individual functionality in the Frame Relay Switching Enhancements feature are listed as follows:

  • Configuring Frame Relay switching and creating switched PVCs on both serial and ISDN interfaces

  • Configuring Frame Relay Traffic Shaping on outgoing switched PVC

  • Configuring Frame Relay policing on incoming switched PVC

  • Configuring Frame Relay congestion management

NOTE

IOS Software Release 12.2(1) is used on the routers in the Cisco test lab for the purpose of the discussion in this section.

Configuring Frame Relay Switching on Switched PVC for Serial and ISDN Interfaces

Before configuring Frame Relay Switching Enhancements, Frame Relay switching must be enabled globally on the router. To enable Frame Relay switching, use the frame-relay switching global configuration command as follows:

Router(config)#frame-relay switching

To create switched PVCs, use the following commands, beginning from the global configuration mode:

Step 1. | Define the connections between Frame Relay PVCs using the connect connection-name interface dlci interface dlci global configuration command. Note that the global connect command assigns DLCI numbers to the respective switched interfaces on the router. The connect command works similarly to the frame-relay route command.
Step 2. | (optional) To attach a Frame Relay map class defined with traffic shaping or policing parameters to a switched PVC, you are required to identify a PVC as switched. To identify a PVC as switched, use the frame-relay interface-dlci dlci [switched] interface configuration command.

Example 6-1 shows both configuration examples of configuring switched PVCs over a serial interface and over an ISDN B channel. In both cases in this example, switched DLCI 100 is connected to switched DLCI 200. DLCI 200 is explicitly identified as a switched PVC using the frame-relay interface-dlci dlci switched interface configuration command. This command enters the user into the frame-relay interface-dlci configuration mode where a Frame Relay map class that is set up with user-defined shaping or policing parameters can be directly associated with the switched PVC.

Example 6-1. Creating Switched PVC and Identifying a DLCI as a Switched PVC
frame-relay switching
!
interface serial 3/2
encapsulation frame-relay
frame-relay intf-type dce
clock rate 56000
!
interface serial 4/2
encapsulation frame-relay
frame-relay intf-type dce
clock rate 56000
frame-relay interface-dlci 200 switched
!
connect fast serial3/2 100 serial4/2 200

frame-relay switching
!
isdn switch-type basis-5ess
!
interface bri 1/0
dialer pool-member 1
!
interface dialer1
encapsulation frame-relay
dialer pool 1
dialer-group 1
dialer caller 4085253422
dialer string 4085253422
frame-relay intf-type dce
!
interface serial 3/2
encapsulation frame-relay
frame-relay intf-type dce
clock rate 56000
!
connect fast serial3/2 100 dialer1 200
!
dialer-list 1 protocol ip permit

NOTE

When configuring a router as a Frame Relay switch in a Frame Relay network, you are required to identify the connected interface on the switch router as a DCE device. This is accomplished using the frame-relay intf-type dce interface configuration command. Because the routers in the lab are connected directly back-to-back on serial cables, the clock rate command is required on the DCE side to supply clocking on the line to the other DTE interface.

Configuring Frame Relay Traffic Shaping on Outgoing Switched PVC

To configure Frame Relay Traffic Shaping on switched PVCs, Frame Relay Traffic Shaping must be enabled first at the egress interface. To enable Frame Relay Traffic Shaping, use the frame-relay traffic-shaping interface configuration command as follows:

Router(config-if)#frame-relay traffic-shaping

NOTE

When using Frame Relay Traffic Shaping together with Frame Relay switching, Frame Relay Traffic Shaping does not apply to "routed PVCs" created with the legacy frame-relay route command.

After Frame Relay Traffic Shaping is enabled under the main interface, a Frame Relay map class with user-defined traffic shaping parameters can be associated with each switched VC. To associate a Frame Relay map class directly with the switched PVCs, use the following commands, beginning from the interface configuration mode:

Step 1. | In the interface configuration mode of the main interface, identify the DLCI of the PVC with the frame-relay interface dlci switched interface configuration command.
Step 2. | Associate the created Frame Relay map class directly with the switched PVC using the class map-class-name configuration command.

It is optional to associate a Frame Relay map class with the switched PVC. If no map class is associated with the switched PVC, the default traffic shaping parameters are applied to the switched PVC. By default, the value of CIR is 56,000, Bc is 7000, and Be is 0. Creating a Frame Relay map class for Frame Relay policing follows the same rules of inheritance applied to terminated PVCs in Frame Relay Traffic Shaping.

If there are no traffic shaping parameters defined in a Frame Relay map class and policing is configured on the ingress side of the switched PVC, Frame Relay Traffic Shaping calculates the shaping values based on the configured policing values as follows:

Frame Relay Traffic Shaping CIR = Policing CIR + Policing EIR (equivalent to Bc/Tc + Be/Tc)

Traffic Shaping MinCIR = Policing CIR

Traffic Shaping Bc = Policing Bc + Policing Be

Traffic Shaping Be = 0

Example 6-2 demonstrates the traffic shaping map class inheritance for switched PVCs.

Example 6-2. Frame Relay Traffic Shaping on Switched PVC
frame-relay switching
!
interface serial4/2
encapsulation frame-relay
clock rate 56000
frame-relay intf-type dce
frame-relay traffic-shaping
frame-relay class fast_vc
frame-relay interface-dlci 100 switched
  class slow_vc
  !
interface serial2/1
encapsulation frame-relay
clock rate 56000
frame-relay intf-type dce
!
connect slow serial4/2 100 serial2/1 300
connect fast serial4/2 200 serial2/1 400
!
map-class frame-relay fast_vc
frame-relay cir 64000
frame-relay bc 8000
frame-relay be 0
!
map-class frame-relay slow_vc
frame-relay cir 32000
frame-relay bc 4000
frame-relay be 0

In Example 6-2, the Frame Relay map class slow_vc is explicitly applied to switched PVC 300/100. Hence, the traffic shaping parameters defined in the slow_vc map class are used for shaping the traffic on switched PVC 300/100 before its entry to the Frame Relay network. On the other hand, switched PVC 400/200 is not explicitly associated with any map class at the DLCI level. Hence, it implicitly inherits the shaping parameters from the Frame Relay map class fast_vc defined at the main interface level using the frame-relay class fast_vc interface configuration command.

Configuring Frame Relay Policing on Incoming Switched Interface

To enable Frame Relay policing on an ingress interface and configure traffic policing parameters, use the frame-relay policing interface configuration command as follows:

Router(config-if)#frame-relay policing

NOTE

It is possible to configure Frame Relay Traffic Shaping and Frame Relay policing on the same interface. When both are enabled on the same interface, Frame Relay Traffic Shaping acts on outgoing traffic, and Frame Relay policing polices incoming traffic.

It is necessary to set up the Frame Relay policing parameters in a Frame Relay map class to define the values for performing Frame Relay policing on the ingress switched PVC. The Frame Relay policing parameters that can be defined in the map class are CIR, Bc, Be, and Tc.

To set up the policing parameters for Frame Relay policing, perform the following configuration tasks, beginning in global configuration mode:

Step 1. | In the global configuration mode, create a Frame Relay map class by specifying a map class name with the map-class frame-relay map-class-name interface configuration command. This enters the user into the map-class configuration mode. NOTE Note that in Steps 2 through 4 that follow, the command supports a new in option so that the value is used exclusively for Frame Relay policing.
Step 2. | In the map-class configuration mode, the values of CIR, Bc, Be, and Tc can be defined as follows:
Step 3. | Specify the incoming CIR rate with the frame-relay cir in bps map-class configuration command.
Step 4. | Specify the incoming Bc value with the frame-relay Bc in bps map-class configuration command.
Step 5. | Specify the incoming Be value with the frame-relay Be in bps map-class configuration command.
Step 6. | Specify the Tc period with the frame-relay tc milliseconds map-class configuration command. This command is optional. By default, the Tc value is calculated from the Bc/CIR. The Tc value is set up only when the CIR is zero.
Step 7. | Identify the switched PVC with the frame-relay interface-dlci dlci switched interface configuration command. Associate the Frame Relay map class created with the policing parameters using the class map-class-name command.

NOTE

The new in and out keywords in the Frame Relay map class configuration commands for defining CIR, Bc, and Be values are meant to distinguish between traffic shaping and policing parameters when the same map class is used for both Frame Relay Traffic Shaping and Frame Relay policing. When defining the parameters for traffic shaping, use the out keyword. The in keyword should be used when defining policing parameters.

Example 6-3 is a configuration example of applying Frame Relay policing parameters to the switched PVC using a Frame Relay map class.

Example 6-3. Configuring Frame Relay Policing and Applying Policing Parameters in a Map Class
frame-relay switching
!
interface serial4/2
encapsulation frame-relay
clock rate 64000
frame-relay intf-type dce
frame-relay policing
frame-relay interface-dlci 100 switched
  class traffic_police
  !
interface serial2/1
encapsulation frame-relay
clock rate 64000
frame-relay intf-type dce
!
connect switching serial4/2 100 serial2/1 300

!
map-class frame-relay traffic_police
frame-relay cir in 64000
frame-relay bc in 8000
frame-relay be in 0

Configuring Frame Relay Congestion Management

As mentioned earlier in this chapter, it is possible to configure two levels of Frame Relay congestion management on a Cisco router. The first level applies Frame Relay congestion management directly on the traffic shaping queues of individual switched PVCs transmitting traffic in excess of the CIR. In this mode, only FIFO queues are supported. The second level applies to the output interface queue, which acts on all of the switched PVCs that are created at the interface as a whole. The first level gives users more granular control by allowing congestion management to be applied directly to the selected switched PVCs.

To configure Frame Relay congestion management on the FIFO traffic-shaping queues of individual switched PVCs, first create a Frame Relay map class to define the threshold values, beginning in the global configuration mode, as follows:

Step 1. | In the global configuration mode, create a Frame Relay map class with the map-class frame-relay map-class-name interface configuration command. This enters the user into the map-class configuration mode.
Step 2. | Configure the threshold at which received DE-marked packets will be discarded from the traffic shaping queues of the switched PVC using the frame-relay congestion threshold de percentage map-class configuration command. The percentage specified is pegged to the traffic shaping queue depth. When the queue is at or above the DE threshold, packets with the DE bit set will be discarded instead of queued.
Step 3. | Configure the threshold at which Explicit Congestion Notification (ECN) bits (BECN and FECN) will be set on packets in the traffic shaping queues of the switched PVC using the frame-relay congestion threshold ecn percentage map-class configuration command. The percentage specified is pegged to the traffic shaping queue depth. When the queue is at or above the ECN threshold, all packets received will be marked with FECN or BECN bit according to their direction of travel.
Step 4. | Configure the maximum size of the FIFO traffic-shaping queue on the switched PVC with the frame-relay holdq queue-size map-class configuration command. Valid queue size is from 1 to 512.
Step 5. | Associate the Frame Relay map class with the switched PVC. First, identify the switched PVC at the interface configuration mode with the frame-relay interface-dlci dlci switched interface configuration command. Then associate the Frame Relay map class with the switched PVC using the class map-class-name command.

Example 6-4 is a configuration example of applying Frame Relay congestion management on individual switched PVCs. The traffic-shaping hold queue on DLCI 200 is configured at 100, and the congestion threshold for DE is set at 50. This implies that when the traffic shaping hold queue is at or has exceeded 50 percent (50/100) capacity, Frame Relay packets received with the DE bit set are discarded instead of queued.

Example 6-4. Configuring Frame Relay Congestion Management Applied to Individual Switched PVC
frame-relay switching
!
interface Serial3/0
 no ip address
 encapsulation frame-relay
 clockrate 64000
 frame-relay traffic-shaping
 frame-relay interface-dlci 200 switched
  class congestion
 frame-relay lmi-type ansi
 frame-relay intf-type dce
 !
interface Serial4/0
 no ip address
 encapsulation frame-relay
 clockrate 64000
 frame-relay intf-type dce
!
map-class frame-relay congestion
 frame-relay holdq 100
 frame-relay congestion threshold de 50
!
connect switch Serial4/0 100 Serial3/0 200

NOTE

To apply Frame Relay congestion management directly on the traffic shaping queues of individual switched PVCs on an interface, Frame Relay Traffic Shaping must be enabled on the interface.

To enable Frame Relay congestion management on all switched PVCs on an interface, use the frame-relay congestion-management interface configuration command, as follows:

Router(config-if)#frame-relay congestion-management

Router(config-fr-congest)#

This enters the user into the Frame Relay congestion management subconfiguration mode. In the Frame Relay congestion management subconfiguration mode, configure the congestion management threshold as follows:

Step 1. | In the Frame Relay congestion management subconfiguration mode, configure the threshold at which received DE-marked packets will be discarded from switched PVCs on the output interface using the threshold de percentage configuration command. The percentage specified is pegged to the queue depth of the interface output hold queue. When the queue is at or has exceeded the DE threshold, all packets with the DE bit set crossing the interface will be discarded instead of queued.
Step 2. | In the Frame Relay congestion management configuration mode, configure the threshold at which ECN bits will be set on packets in switched PVCs on the output interface using the threshold ecn { bc | be } percentage configuration command. The percentage specified is pegged to the queue depth of the interface output hold queue. When the queue is at or has exceeded the ECN threshold, the BECN or FECN bit is set in the packets crossing the interface corresponding to the direction of traffic.
Step 3. | (optional) Set the size of the interface output queue using the hold-queue queue-size out interface configuration command. Valid queue size is from 0 to 4096.

Refer to Example 6-5 for configuring congestion management at the interface level. The output queue size can be adjusted from the default of 40 to a value between 0 and 4096 using the hold-queue queue-size {in | out} command. In this example, the threshold for ECN is set at 50 percent for Bc traffic. This implies that when the output hold queue has exceeded 50 percent capacity, the interface will set the BECN and FECN bits in packets transmitted on the interface to notify a congestion condition. When the output queue size is over 75 packets, the DE threshold configured with the threshold de command is reached, and all DE marked packets subsequently received are dropped from the interface output queue.

Example 6-5. Configuring Congestion Management on the Interface
frame-relay switching
   !
   interface Serial3/0
    no ip address
    encapsulation frame-relay
    no fair-queue
    clockrate 64000
    frame-relay traffic-shaping
    frame-relay lmi-type ansi
    frame-relay intf-type dce
    frame-relay congestion-management
     threshold ecn bc 50
     threshold de 75
    hold-queue 100 out
   !
   interface Serial4/0
    no ip address
    encapsulation frame-relay
    clockrate 64000
    frame-relay intf-type dce
   !
   connect switch Serial4/0 100 Serial3/0 200


Monitoring and Verifying Frame Relay Switching Enhancements on a Cisco Router

This section discusses the IOS show commands for monitoring and verifying the Frame Relay Switching Enhancements information on a Cisco router. To facilitate the discussion on how Frame Relay switching enhancements work, traffic flow is generated on the network to help simulate actual users' traffic. Refer to the network depicted in Figure 6-3. Two servers are set up, one at each end of the Frame Relay network for the purpose of generating users' traffic into the Frame Relay network. IOS show commands are used to monitor the Frame Relay switching enhancement information and statistics on the router.

Example 6-6. Running Configuration of the Router Switch Configured as a Frame Relay Switch
hostname Switch
!
frame-relay switching
!
interface Serial3/3
 no ip address
 encapsulation frame-relay
 frame-relay interface-dlci 100 switched
 frame-relay lmi-type ansi
 frame-relay intf-type dce
!
interface Serial4/2
 no ip address
 encapsulation frame-relay
 frame-relay interface-dlci 200 switched
 frame-relay lmi-type ansi
 frame-relay intf-type dce
!
connect frswitch1 Serial3/3 100 Serial4/2 200

Figure 6-3. Simple Frame Relay Network Using a Frame Relay Switch

Right after the switched PVCs become active, the show frame-relay pvc privileged EXEC command can be used to verify the status of the switched PVC. The show connection all privileged EXEC command can be used to display the status of the switched connections on the Frame Relay switch. The outputs are shown in Example 6-7.

Example 6-7. Verifying the Status of the Switched PVC
Switch#show frame-relay pvc 100

PVC Statistics for interface Serial3/3 (Frame Relay DCE)

DLCI = 100, DLCI USAGE = SWITCHED, PVC STATUS = ACTIVE, INTERFACE = Serial3/3

  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            Num Pkts Switched 0
  pvc create time 00:00:51, last time pvc status changed 00:00:25
Switch#

Switch#show frame-relay pvc 200

PVC Statistics for interface Serial4/2 (Frame Relay DCE)

DLCI = 200, DLCI USAGE = SWITCHED, PVC STATUS = ACTIVE, INTERFACE = Serial4/2

  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            Num Pkts Switched 0
  pvc create time 00:00:50, last time pvc status changed 00:00:34
Switch#

Switch#show connection all

ID   Name               Segment 1            Segment 2           State
========================================================================
1    frswitch1         Serial3/3 100        Serial4/2 200        UP

Switch#

Monitoring and Verifying Frame Relay Traffic Shaping on Switched PVCs

On the router with host name Switch, the switched PVCs are defined and connected with the global connect command, as demonstrated in the configurations in Example 6-6. To apply Frame Relay Traffic Shaping on the outgoing switched PVC, the interface command frame-relay traffic-shaping is configured under Switch's interface serial4/2. The traffic shaping parameters defined in the Frame Relay map class named cir_48000 are attached to switched DLCI 200. Refer to Example 6-8 for the running configurations of router Switch and the details of the shaping parameters defined in the Frame Relay map class.

Example 6-8. Configuring Frame Relay Traffic Shaping on Router Switch
interface Serial4/2
    no ip address
    encapsulation frame-relay
    clockrate 64000
    frame-relay traffic-shaping
    frame-relay interface-dlci 200 switched
     class cir_48000
    frame-relay lmi-type ansi
    frame-relay intf-type dce
   !
   map-class frame-relay cir_48000
    frame-relay cir 48000
    frame-relay bc 6000
    frame-relay be 0
    frame-relay holdq 1

The server connected to router R1 is configured to send out a traffic stream to router R2 en route to the Frame Relay network. The details of the traffic stream setup on the server are specified as follows:

  • Size of packet (inclusive of IP and Frame Relay headers) = 1000 bytes

  • Rate of traffic stream = 7 packets per second (effectively equivalent to 56000 bps (7 pkt per second x 1000 bytes per pkt / 8 bits per bytes))

On the server, the traffic stream is turned on for a total duration of 5 minutes. As such, a total of 2100 packets (7 pkt/sec x 300 sec) are sent from the server destined to router R2. Figure 6-4 illustrates the flow of the traffic from the server into the Frame Relay network.

Figure 6-4. Directional Flow of the Traffic Stream towards Router R2

On the router Switch, Frame Relay Traffic Shaping is configured on switched DLCI 200 with the traffic shaping parameters CIR = 48000, Bc = 6000, and Be = 0 set up in a map class. The hold queue at the output interface is set at 1 packet so that any packets exceeding the CIR rate are likely to be dropped immediately. The Tc interval is effectively 125 msec (Bc/CIR = 6000/48000 = 125 msec).

In one Tc interval, 7000 bits of data are transmitted out of the interface on switched DLCI 200 at router Switch (56000 bits/sec x 125 msec). Because the configured Bc per Tc interval is only 6000 bits and Be = 0, approximately 1000 bits falls short, and packet drops occur on the egress interface serial4/2 of router Switch at the rate of 1 packet per second. Hence, 300 packets (1 packet per second x 300 second) are dropped over a 5-minute period at the interface because of rate limiting enforced by Frame Relay Traffic Shaping. Example 6-9 shows the output of the show frame-relay pvc command after all 2100 packets are completely sent. As expected, the result of the show frame-relay pvc output reflects that approximately 300 packets are dropped by Frame Relay Traffic Shaping.

Example 6-9. The show frame-relay pvc Output After the Traffic Stream Is Transmitted
Switch#show frame-relay pvc 200

PVC Statistics for interface Serial4/2 (Frame Relay DCE)

DLCI = 200, DLCI USAGE = SWITCHED, PVC STATUS = ACTIVE, INTERFACE = Serial4/2

  input pkts 0             output pkts 2100         in bytes 0
  out bytes 2100000        dropped pkts 299         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 299       pkt above DE 0           policing drop 0
  pvc create time 06:50:14, last time pvc status changed 06:48:49
  cir 48000     bc 6000      be 0         byte limit 750    interval 125
  mincir 24000     byte increment 750   Adaptive Shaping none
  pkts 1801      bytes 1801000   pkts delayed 1402      bytes delayed 1402000
  shaping inactive
  traffic shaping drops 0
  Queueing strategy: fifo
  Output queue 0/1, 299 drop, 1402 dequeued

Monitoring and Verifying Frame Relay Policing on Ingress Interface

This section describes the Cisco IOS show commands for monitoring and verifying Frame Relay policing at the ingress interface. Referring to Figure 6-4 again, Frame Relay policing is configured at the ingress interface serial3/3 of router Switch. A Frame Relay map class is created to define the policing parameters at Switch for performing Frame Relay policing of traffic on the incoming switched DLCI 100. Example 6-10 shows the running configuration of router Switch with Frame Relay policing enabled and the resultant output of the show frame-relay pvc command.

Example 6-10. Show Running Configuration of the Router Switch and Output of show frame-relay pvc of Switched DLCI 100
frame-relay switching
!
interface Serial3/3
 no ip address
 encapsulation frame-relay
 no fair-queue
 frame-relay interface-dlci 100 switched
   class police_24000
 frame-relay lmi-type ansi
 frame-relay intf-type dce
 frame-relay policing
!
interface Serial4/2
 no ip address
 encapsulation frame-relay
 no fair-queue
 frame-relay interface-dlci 200 switched
 frame-relay lmi-type ansi
 frame-relay intf-type dce
!
map-class frame-relay police_24000
 frame-relay cir 24000
 frame-relay bc 12000
 frame-relay be 12000
 !
connect frswitch1 Serial3/3 100 Serial4/2 200

Switch#show frame-relay pvc 100

PVC Statistics for interface Serial3/3 (Frame Relay DCE)

DLCI = 100, DLCI USAGE = SWITCHED, PVC STATUS = ACTIVE, INTERFACE = Serial3/3

  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 07:10:05, last time pvc status changed 07:08:48
  policing enabled, 0 pkts marked DE
  policing Bc  12000       policing Be  12000       policing Tc  500 (msec)
  in Bc pkts   0           in Be pkts   0           in xs pkts   0
  in Bc bytes  0           in Be bytes  0           in xs bytes  0

In this section, a new Frame Relay map class named police_24000 was configured to set up different traffic parameters for verifying Frame Relay policing. Compared with the earlier map class that was defined for Frame Relay Traffic Shaping on switched DLCI 200, the map class created for Frame Relay policing has a lower CIR rate of 24000 bps, and both Bc and Be values are set at 12000 bits. Hence, the resultant Tc interval is 0.5 seconds (Bc/CIR = 12000/24000). The rate of the traffic stream configured to originate from the server remains unchanged at 56000 bps. 56000 bits, or 7000 bytes, of data are received by the router Switch every second on the switched DLCI 100 on the ingress interface serial3/3. The available credits in the Bc and Be pool per Tc time interval (per 0.5 seconds) are 12000 bits, or 1500 bytes. Therefore, the amount of credits available in the Bc and Be pool is 24000 bps, or 3000 bytes per second. Note that one byte is equivalent to eight bits. For the purpose of clarity, all calculations in the sections to follow are performed in bytes, as follows:

  • Incoming rate of traffic arriving on switched DLCI 100 = 7000 bytes per second

  • Bc credit available per second = 3000 bytes

  • Be credit available per second = 3000 bytes

  • Excess packets discarded per second = 7000 (3000 + 3000) = 1000 bytes

Therefore, in every second, 1 packet (1000 bytes) is discarded by Frame Relay traffic policing enabled on switched DLCI 100.

After 5 minutes has elapsed, when all 2100 packets are completely sent from the server, a total of 300 packets are dropped (1 packet/second x 300 seconds). The observation in Example 6-11 confirms the expected behavior.

Example 6-11. show frame-relay pvc Output of Switched DLCI 100 for Frame Relay Policing
Switch#show frame-relay pvc 100

PVC Statistics for interface Serial3/3 (Frame Relay DCE)

DLCI = 100, DLCI USAGE = SWITCHED, PVC STATUS = ACTIVE, INTERFACE = Serial3/3

  input pkts 1801          output pkts 0            in bytes 1801000
  out bytes 0              dropped pkts 299         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 1801
  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 299
  pvc create time 00:12:34, last time pvc status changed 00:11:59
  policing enabled, 900 pkts marked DE
  policing Bc  12000       policing Be  12000       policing Tc  500 (msec)
  in Bc pkts   901         in Be pkts   900         in xs pkts   299
  in Bc bytes  901000      in Be bytes  900000      in xs bytes  299000

Switch#show frame-relay pvc 200

PVC Statistics for interface Serial4/2 (Frame Relay DCE)

DLCI = 200, DLCI USAGE = SWITCHED, PVC STATUS = ACTIVE, INTERFACE = Serial4/2

  input pkts 0             output pkts 1801         in bytes 0
  out bytes 1801000        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 900
  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 00:12:50, last time pvc status changed 00:12:43

Referring again to Example 6-11, a total of 900 Bc packets and 900 Be packets are received (3000 bytes/second x 300 seconds / 1000 bytes/packet), which is indicated by the "in Bc pkts" and "in Be pkts" counters. The remaining 300 packets are discarded because the total Bc + Be token pool is depleted over every Tc interval during the entire transmission duration. The number of packets dropped because of Frame Relay policing is indicated by the values shown in the "policing drops" and "in xs pkts" counters. Finally, the show frame-relay pvc output of the egress switched DLCI 200 reveals that 900 packets are marked with the DE bits. This is because all packets transmitted using the credits from the Be token pool are marked with DE.

NOTE

When DE-marked packets or packets with a size greater than the Bc are received on the interface enabled with Frame Relay policing, the incoming traffic is directly checked against the Be pool first for transmission. Generally, Frame Relay policing sets the DE bit on packets, but it never clears the DE bits on any packets transmitted.

Monitoring and Verifying Frame Relay Congestion Management

This section examines how to monitor and verify Frame Relay congestion management information on a Cisco router. The section uses examples to demonstrate Frame Relay congestion management applied directly on individual switched PVCs.

Using the network diagram in Figure 6-3, a new traffic stream will be sent from the second server into the Frame Relay network, en route to router R1. The traffic path of the new traffic stream is directly opposite to the original traffic stream. Later, when both traffic streams are simultaneously generated on the network with the two equally opposite traffic paths, the operations of Frame Relay congestion management on the router Switch will be verified. See Figure 6-5 for the network diagram illustrating the new traffic flow.

Figure 6-5. Directional Flow of the Two Traffic Streams Generated from Both Servers on the Network

Notice that the throughput of the new traffic stream setup is slightly lower than the original traffic stream. The first stream en route to router R2 is sent at a rate of 64 kbps, whereas the second stream sent in the opposite direction to router R1 is generated at a slower 56 kbps. The purpose of creating a second traffic stream in this section is to simulate a high-speed-to-low-speed network mismatch normally seen in hub-and-spoke Frame Relay networks. Note the example in this section is using only a modest 8 kbps bandwidth mismatch. In reality, the bandwidth mismatch can be much higher; for example, a T1 versus fractional T1 would have a 128 kbps bandwidth mismatch. In this example, because of the bandwidth mismatch, congestion is likely to occur on switched DLCI 200 at router Switch. When congestion occurs, the second traffic stream with the opposite directional flow allows BECN bits to be set on frames traversing on the interface.

A configuration example of Frame Relay congestion management applied on the traffic shaping queues of individual switched PVC is shown in Example 6-12.

Example 6-12. Configuration Example of Frame Relay Congestion Management on Traffic Shaping Queues of Switched PVC
frame-relay switching
!
interface Serial3/3
 no ip address
 encapsulation frame-relay
 clockrate 64000
 frame-relay interface-dlci 100 switched
 frame-relay intf-type dce
!
interface Serial4/2
 no ip address
 encapsulation frame-relay
clockrate 56000
 frame-relay traffic-shaping
 frame-relay interface-dlci 200 switched
  class congestion_pvc
 frame-relay lmi-type ansi
 frame-relay intf-type dce
!
map-class frame-relay congestion_pvc
 frame-relay holdq 100
 frame-relay congestion threshold ecn 50
 !
connect frswitch1 Serial3/3 100 Serial4/2 200

After setting up the above configurations on the Frame Relay switch, the traffic streams are sent out from each server into the Frame Relay network. The first server connected to router R1's Ethernet subnet sends out a traffic stream at a rate of 64 kpbs (1000 bytes per packet x 8 packets/second x 8 bits/byte) into the Frame Relay switch en route to router R2. The second server connected to router R2's Ethernet subnet generates a traffic stream at a lower rate of 56 kbps (1000 bytes per packets at 7 packets/second) into the Frame Relay switch en route to router R1. When the traffic is running on the network, the show frame-relay pvc command is performed several times on router Switch, where Frame Relay congestion management is applied on switched DLCI 200. Example 6-13 shows the status of the congestion management before it becomes activated. Example 6-14 shows the same configuration but after Frame Relay congestion management is activated.

Example 6-13. show frame-relay pvc Output of Frame Relay Switch Before Frame Relay Congestion Management Is Activated
Switch#show frame-relay pvc 100

PVC Statistics for interface Serial3/3 (Frame Relay DCE)

DLCI = 100, DLCI USAGE = SWITCHED, PVC STATUS = ACTIVE, INTERFACE = Serial3/3

  input pkts 298           output pkts 261          in bytes 298000
  out bytes 261000         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 298
  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 17:27:28, last time pvc status changed 17:26:52

Switch#show frame-relay pvc 200

PVC Statistics for interface Serial4/2 (Frame Relay DCE)

DLCI = 200, DLCI USAGE = SWITCHED, PVC STATUS = ACTIVE, INTERFACE = Serial4/2

  input pkts 342           output pkts 391          in bytes 342000
  out bytes 391000         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 342
  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 17:22:17, last time pvc status changed 17:22:10
  Congestion ECN threshold 50, not congested
  cir 56000     bc 7000      be 0         byte limit 875    interval 125
  mincir 28000     byte increment 875   Adaptive Shaping none
  pkts 350       bytes 350000    pkts delayed 344       bytes delayed 344000
  shaping active
  traffic shaping drops 0
  Queueing strategy: fifo
  Output queue 49/100, 0 drop, 344 dequeued

Example 6-14. show frame-relay pvc Output of Frame Relay Switch After Frame Relay Congestion Management Is Activated
Switchshow frame-relay pvc 100

PVC Statistics for interface Serial3/3 (Frame Relay DCE)

DLCI = 100, DLCI USAGE = SWITCHED, PVC STATUS = ACTIVE, INTERFACE = Serial3/3

  input pkts 430           output pkts 377          in bytes 430000
  out bytes 377000         dropped pkts 0           in FECN pkts 0
  in BECN pkts 0           out FECN pkts 0          out BECN pkts 14
  in DE pkts 0             out DE pkts 0
  out bcast pkts 0         out bcast bytes 0
  switched pkts 430
  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 17:27:44, last time pvc status changed 17:27:09

Switch#show frame-relay pvc 200

PVC Statistics for interface Serial4/2 (Frame Relay DCE)

DLCI = 200, DLCI USAGE = SWITCHED, PVC STATUS = ACTIVE, INTERFACE = Serial4/2

  input pkts 443           output pkts 507          in bytes 443000
  out bytes 507000         dropped pkts 0           in FECN pkts 0
  in BECN pkts 0           out FECN pkts 93         out BECN pkts 0
  in DE pkts 0             out DE pkts 0
  out bcast pkts 0         out bcast bytes 0
  switched pkts 443
  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 17:22:32, last time pvc status changed 17:22:25
  Congestion ECN threshold 50, congested
  cir 56000     bc 7000      be 0         byte limit 875    interval 125
  mincir 28000     byte increment 875   Adaptive Shaping none
  pkts 453       bytes 453000    pkts delayed 447       bytes delayed 447000
  shaping active
  traffic shaping drops 0
  Queueing strategy: fifo
Output queue 63/100, 0 drop, 447 dequeued

The outputs in Examples 6-13 and 6-14 show that when the Frame Relay Traffic Shaping queue on switched DLCI 200 is below 50, Frame Relay congestion management remains inactive and no BECN or FECN bits are set. This is correct, because the queue depth of the Frame Relay Traffic Shaping queue on switched DLCI 200 is configured at 100 with the frame-relay holdq command in the map class congestion_pvc, and the threshold for sending ECN is 50 percent using the frame-relay congestion threshold ecn map-class configuration command. As soon as the output queue depth is at or has exceeded 50, BECN and FECN bits are set in the frames traveling in the direction of the congestion accordingly.

The next step is for the DE threshold to be set up on router Switch with the frame-relay congestion threshold de command in the Frame Relay map class to discard DE marked packets when the DE threshold level is reached. Example 6-15 displays the resultant running configurations on Switch and the show frame-relay pvc output before and after the DE threshold is reached.

Example 6-15. Running Configurations on Switch and the show frame-relay pvc Output Before and After the DE Threshold Is Reached
interface Serial4/2
 no ip address
 encapsulation frame-relay
 no fair-queue
 clockrate 56000
 frame-relay traffic-shaping
 frame-relay interface-dlci 200 switched
  class congestion_pvc
 frame-relay lmi-type ansi
 frame-relay intf-type dce
 !
map-class frame-relay congestion_pvc
 frame-relay holdq 100
 frame-relay congestion threshold de 50

Before DE threshold level is reached:

Switch#show frame-relay pvc 200

PVC Statistics for interface Serial4/2 (Frame Relay DCE)

DLCI = 200, DLCI USAGE = SWITCHED, PVC STATUS = ACTIVE, INTERFACE = Serial4/2

  input pkts 347           output pkts 397          in bytes 347000
  out bytes 397000         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 397
  out bcast pkts 0         out bcast bytes 0
  switched pkts 347
  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 18:00:40, last time pvc status changed 18:00:34
  Congestion DE threshold 50
  cir 56000     bc 7000      be 0         byte limit 875    interval 125
  mincir 28000     byte increment 875   Adaptive Shaping none
  pkts 356       bytes 356000    pkts delayed 352       bytes delayed 352000
  shaping active
  traffic shaping drops 0
  Queueing strategy: fifo
  Output queue 49/100, 0 drop, 352 dequeued

After DE threshold level is reached:

Switch#show frame-relay pvc 200

PVC Statistics for interface Serial4/2 (Frame Relay DCE)

DLCI = 200, DLCI USAGE = SWITCHED, PVC STATUS = ACTIVE, INTERFACE = Serial4/2

  input pkts 378           output pkts 432          in bytes 378000
  out bytes 432000         dropped pkts 3           in FECN pkts 0
  in BECN pkts 0           out FECN pkts 0          out BECN pkts 0
  in DE pkts 0             out DE pkts 432
  out bcast pkts 0         out bcast bytes 0
  switched pkts 378
  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 3         pkt above DE 0           policing drop 0
  pvc create time 18:00:45, last time pvc status changed 18:00:38
  Congestion DE threshold 50
  cir 56000     bc 7000      be 0         byte limit 875    interval 125
  mincir 28000     byte increment 875   Adaptive Shaping none
  pkts 386       bytes 386000    pkts delayed 382       bytes delayed 382000
  shaping active
  traffic shaping drops 0
  Queueing strategy: fifo
  Output queue 50/100, 4 drop, 382 dequeued

Congestion Management on the Interface Level

The next step is to look at monitoring and verifying Frame Relay congestion management configured on the interface level. The behavior of Frame Relay congestion management configured at the interface level is very similar to the congestion management enabled at the switched PVC level. The show frame-relay pvc command is used to observe the ECN/DE bits set on the switched PVC, and the show interface serial command is used to verify the interface output queue. Example 6-16 shows the running configurations of router Switch with Frame Relay congestion management enabled at the interface level.

Example 6-16. Running Configurations of Switch with Congestion Management at the Interface Level
   interface serial4/2
    no ip address
    encapsulation frame-relay
    no fair-queue
    clockrate 56000
    frame-relay traffic-shaping
    frame-relay interface-dlci 200 switched
    frame-relay lmi-type ansi
    frame-relay intf-type dce
    frame-relay congestion-management
     threshold ecn 50
     threshold de 75
    hold-queue 100 out

The show frame-relay pvc status of the switched DLCIs before and after Frame Relay congestion management is activated is shown in Example 6-17.

Example 6-17. show frame-relay pvc Output Before and After Frame Relay Congestion Management Is Activated
Before ECN threshold level is reached:

Switch#sh inter serial4/2
Serial4/2 is up, line protocol is up
  Hardware is M4T
  MTU 1500 bytes, BW 2048 Kbit, DLY 20000 usec,
     reliability 255/255, txload 2/255, rxload 2/255
  Encapsulation FRAME-RELAY, crc 16, loopback not set
  Keepalive set (10 sec)
  LMI enq sent  0, LMI stat recvd 0, LMI upd recvd 0
  LMI enq recvd 10, LMI stat sent  10, LMI upd sent  0, DCE LMI up
  LMI DLCI 0  LMI type is ANSI Annex D  frame relay DCE
  FR SVC disabled, LAPF state down
  Congestion ECN thresholds 50/50, DE threshold 75, DE drops 0
  Broadcast queue 0/64, broadcasts sent/dropped 0/0, interface broadcasts 0
Last input 00:00:00, output 00:00:00, output hang never
Last clearing of "show interface" counters 00:01:36
Queueing strategy: fifo
Output queue 50/100, 0 drops; input queue 0/75, 0 drops
5 minute input rate 20000 bits/sec, 7 packets/sec
5 minute output rate 21000 bits/sec, 7 packets/sec
   574 packets input, 564140 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
   612 packets output, 602145 bytes, 0 underruns
   0 output errors, 0 collisions, 0 interface resets

Switch#show frame-relay pvc 200

PVC Statistics for interface Serial4/2 (Frame Relay DCE)

DLCI = 200, DLCI USAGE = SWITCHED, PVC STATUS = ACTIVE, INTERFACE = Serial4/2

input pkts 541           output pkts 619          in bytes 541000
out bytes 619000         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 619
out bcast pkts 0         out bcast bytes 0
switched pkts 541
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 18:43:35, last time pvc status changed 00:19:07

After ECN threshold level is reached:

Switch#sh inter serial4/2
Serial4/2 is up, line protocol is up
  Hardware is M4T
  MTU 1500 bytes, BW 2048 Kbit, DLY 20000 usec,
     reliability 255/255, txload 2/255, rxload 2/255
  Encapsulation FRAME-RELAY, crc 16, loopback not set
  Keepalive set (10 sec)
  LMI enq sent  0, LMI stat recvd 0, LMI upd recvd 0
  LMI enq recvd 10, LMI stat sent  10, LMI upd sent  0, DCE LMI up
  LMI DLCI 0  LMI type is ANSI Annex D  frame relay DCE
  FR SVC disabled, LAPF state down
  Congestion ECN thresholds 50/50, DE threshold 75, DE drops 0
  Broadcast queue 0/64, broadcasts sent/dropped 0/0, interface broadcasts 0
  Last input 00:00:05, output 00:00:00, output hang never
  Last clearing of "show interface" counters 00:01:41
  Queueing strategy: fifo
  Output queue 53/100, 0 drops; input queue 0/75, 0 drops
  5 minute input rate 21000 bits/sec, 7 packets/sec
  5 minute output rate 22000 bits/sec, 7 packets/sec
     607 packets input, 597140 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
     646 packets output, 636145 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets

Switch#show frame-relay pvc 100

PVC Statistics for interface Serial3/3 (Frame Relay DCE)

DLCI = 100, DLCI USAGE = SWITCHED, PVC STATUS = ACTIVE, INTERFACE = Serial3/3

  input pkts 758           output pkts 664          in bytes 758000
  out bytes 664000         dropped pkts 0           in FECN pkts 0
  in BECN pkts 0           out FECN pkts 0          out BECN pkts 91
  in DE pkts 0             out DE pkts 0
  out bcast pkts 0         out bcast bytes 0
  switched pkts 758
  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 18:31:17, last time pvc status changed 00:07:41

Switch#show frame-relay pvc 200

PVC Statistics for interface Serial4/2 (Frame Relay DCE)

DLCI = 200, DLCI USAGE = SWITCHED, PVC STATUS = ACTIVE, INTERFACE = Serial4/2

  input pkts 613           output pkts 699          in bytes 613000
  out bytes 699000         dropped pkts 0           in FECN pkts 0
  in BECN pkts 0           out FECN pkts 46         out BECN pkts 0
  in DE pkts 0             out DE pkts 0
  out bcast pkts 0         out bcast bytes 0
  switched pkts 613
  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 18:31:10, last time pvc status changed 00:06:42

Before DE threshold level is reached:

Switch#show inter serial4/2
Serial4/2 is up, line protocol is up
  Hardware is M4T
  MTU 1500 bytes, BW 2048 Kbit, DLY 20000 usec,
     reliability 255/255, txload 5/255, rxload 5/255
  Encapsulation FRAME-RELAY, crc 16, loopback not set
  Keepalive set (10 sec)
  LMI enq sent  0, LMI stat recvd 0, LMI upd recvd 0
  LMI enq recvd 10, LMI stat sent  10, LMI upd sent  0, DCE LMI up
  LMI DLCI 0  LMI type is ANSI Annex D  frame relay DCE
  FR SVC disabled, LAPF state down
  Congestion ECN thresholds 50/50, DE threshold 75, DE drops 0
  Broadcast queue 0/64, broadcasts sent/dropped 0/0, interface broadcasts 0
  Last input 00:00:09, output 00:00:00, output hang never
  Last clearing of "show interface" counters 00:01:44
  Queueing strategy: fifo
  Output queue 70/100, 0 drops; input queue 0/75, 0 drops
  5 minute input rate 47000 bits/sec, 7 packets/sec
  5 minute output rate 45000 bits/sec, 7 packets/sec
     718 packets input, 708140 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
     756 packets output, 745164 bytes, 0 underruns
     0 output errors, 0 collisions, 0 interface resets
     0 output buffer failures, 0 output buffers swapped out
     0 carrier transitions     DCD=up  DSR=up  DTR=up  RTS=up  CTS=up

Switch#show frame-relay pvc 200

PVC Statistics for interface Serial4/2 (Frame Relay DCE)

DLCI = 200, DLCI USAGE = SWITCHED, PVC STATUS = ACTIVE, INTERFACE = Serial4/2

  input pkts 734           output pkts 839          in bytes 734000
  out bytes 839000         dropped pkts 0           in FECN pkts 0
  in BECN pkts 0           out FECN pkts 187        out BECN pkts 0
  in DE pkts 0             out DE pkts 839
  out bcast pkts 0         out bcast bytes 0
  switched pkts 734
  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 18:57:41, last time pvc status changed 00:33:13

After DE threshold level is reached:

Switch#show inter s4/2
Serial4/2 is up, line protocol is up
  Hardware is M4T
  MTU 1500 bytes, BW 2048 Kbit, DLY 20000 usec,
     reliability 255/255, txload 6/255, rxload 6/255
  Encapsulation FRAME-RELAY, crc 16, loopback not set
  Keepalive set (10 sec)
  LMI enq sent  0, LMI stat recvd 0, LMI upd recvd 0
  LMI enq recvd 14, LMI stat sent  14, LMI upd sent  0, DCE LMI up
  LMI DLCI 0  LMI type is ANSI Annex D  frame relay DCE
  FR SVC disabled, LAPF state down
  Congestion ECN thresholds 50/50, DE threshold 75, DE drops 25
  Broadcast queue 0/64, broadcasts sent/dropped 0/0, interface broadcasts 0
  Last input 00:00:01, output 00:00:00, output hang never
  Last clearing of "show interface" counters 00:02:14
  Queueing strategy: fifo
  Output queue 75/100, 0 drops; input queue 0/75, 0 drops
  5 minute input rate 54000 bits/sec, 6 packets/sec
  5 minute output rate 51000 bits/sec, 7 packets/sec
     930 packets input, 916196 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
     969 packets output, 955206 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets

Switch#show frame-relay pvc 200

PVC Statistics for interface Serial4/2 (Frame Relay DCE)

DLCI = 200, DLCI USAGE = SWITCHED, PVC STATUS = ACTIVE, INTERFACE = Serial4/2

  input pkts 958           output pkts 1095         in bytes 958000
  out bytes 1095000        dropped pkts 31          in FECN pkts 0
  in BECN pkts 0           out FECN pkts 416        out BECN pkts 0
  in DE pkts 0             out DE pkts 1095
  out bcast pkts 0         out bcast bytes 0
  switched pkts 958
  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 31          policing drop 0
  pvc create time 18:49:05, last time pvc status changed 00:24:37


Summary

This chapter demonstrated the capabilities of the Frame Relay Switching Enhancements feature. It showed how the feature enables a traditional router to be deployed as a Frame Relay switch or a Frame Relay port concentrator in a Frame Relay network. The Frame Relay Switching Enhancements feature is composed of several software components. Switched PVC allows a Cisco router to perform the function of a Frame Relay switch. The Frame Relay Switching Enhancements feature supports Frame Relay switching and traffic shaping on switched PVCs over serial and ISDN BRI interfaces. In addition, Frame Relay congestion management allows a Cisco router to perform policing on an ingress interface.

This chapter also explained the configuration steps required to enable the supported switching functionalities on a Cisco router. Detailed configuration examples were provided to supplement the discussion on how the various Cisco IOS show commands are used to monitor and verify for Frame Relay switching information on a Cisco router.

The next chapter discusses the Cisco Frame Relay End-to-End Keepalive feature, which allows Cisco devices to exchange status information.


Review Questions

1: | What are the differences between legacy Frame Relay switching using the frame-relay route interface command and the global connect command in the new switching capability offered by the Frame Relay switching enhancements feature?
2: | What is the purpose of switched PVC, and what is the command and keyword required to set up the switched PVC on a Frame Relay switch?
3: | What are the levels of congestion management supported by the Frame Relay Switching Enhancements feature?
4: | What are the steps required to set up congestion management on the Frame Relay switch?
5: | Identify the configuration mode and command required to enable Frame Relay traffic policing.


Reference

Cisco IOS Release 12.1(2)T - Frame Relay Switching Enhancements: http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121newft/121t/121t2/dtfrswen.htm


Case Study: Frame Relay Switching over ISDN

The network designs in many countries typically reflect the local demographic distribution. Most often, the network design follows a three-tier layout: the core nodes are usually sited in the central cities, the middle feeder nodes are found in regional locations, and the end nodes are situated in the customers' premises. In this fashion, it is expensive to run and support long haul leased lines from the end nodes to the core nodes.

A local advertising company wishes to use a high-speed Frame Relay service provided by its Frame Relay network carrier to connect its remote regional branch offices to the public Frame Relay network. The customer's various branch office sites are linked to the central office on ISDN connections.

Using the Frame Relay switching over ISDN feature allows the customer to feed Frame Relay encapsulated traffic into the ISDN interfaces in the central office (the feeder nodes). In turn, the feeder nodes can switch the Frame Relay traffic into the Frame Relay network in the core node. ISDN helps to provide security by means of authentication. Moreover, the Frame Relay policing, Frame Relay Traffic Shaping, and Frame Relay congestion management on switched PVCs functionalities bring added benefits to the Frame Relay switching enhancements feature.

Figure 6-6 shows a typical network diagram of the advertising company, and Example 6-18 shows the running configurations of the key routers involved in this setup. The branch office routers are connected to the regional Frame Relay access switch on T1 Primary Rate ISDN interfaces.

Example 6-18. The Running Configurations of a Branch Office Router and the Cisco Router Configured as a Frame Relay Switch
Branch office router:

<output omitted>
!
hostname branchA
!
isdn switch-type primary-5ess
!
controller T1 1/0
 framing esf
 linecode b8zs
 pri-group timeslots 1-24
!
interface Serial1/0:23
 description ENG PBX PRI phone num.: 81074
 no ip address
 dialer pool-member 1
 isdn switch-type primary-5ess
 isdn incoming-voice data
 no cdp enable
!
interface Dialer0
 ip address 1.1.1.1 255.0.0.0
 encapsulation frame-relay
 dialer remote-name frameswitch
 dialer pool 1
 dialer idle-timeout 70
 dialer string 81070
 dialer max-call 1
 dialer-group 1
 frame-relay map ip 1.3.3.3 101
 frame-relay interface-dlci 101
!
router eigrp 200
 network 1.0.0.0 0.255.255.255
 no auto-summary
!
access-list 100 deny   eigrp any any
access-list 100 permit ip any any
dialer-list 1 protocol ip list 100

Frame Relay router configured as Frame Relay access switch:

<output omitted>
!
hostname frameswitch
!
frame-relay switching
isdn switch-type primary-5ess
!
controller T1 0
 framing esf
 linecode b8zs
 pri-group timeslots 1-24
!
interface Serial0:23
 description ENG PBX PRI num.: 81070
 no ip address
 dialer pool-member 1
 isdn switch-type primary-5ess
 isdn incoming-voice data
 no cdp enable
!
interface Dialer0
 no ip address
 encapsulation frame-relay
 dialer remote-name branchA
 dialer pool 1
 dialer idle-timeout 3600
 dialer string 81074
 dialer max-call 1
 frame-relay interface-dlci 101 switched
 frame-relay intf-type dce
!
connect ONE Dialer0 101 Serial3 103

Frame Relay switch in the service provider's network:

<output omitted>
!
SP_switch
!
interface Serial1/0
 ip address 1.3.3.3 255.0.0.0
 encapsulation frame-relay
 no ip mroute-cache
 frame-relay map ip 1.1.1.1 103
 frame-relay interface-dlci 103

Figure 6-6. Frame Relay Network Diagram of the Advertising Company

Example 6-19 shows the status of the show frame-relay pvc command at the Frame Relay access switch and the connection status of the switched PVC at the Frame Relay switch after the branch office router A has activated its ISDN connection.

Example 6-19. Various show Outputs of the Case Study
frameswitch#show frame pvc 101

PVC Statistics for interface Dialer0 (Frame Relay DCE)

DLCI = 101, DLCI USAGE = SWITCHED, PVC STATUS = ACTIVE (spoofing), INTERFACE = Dialer0

  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            Num Pkts Switched 0
  pvc create time 00:00:29, last time pvc status changed 00:00:09

frameswitch#show int Dialer0
Dialer0 is up, line protocol is up (spoofing)
  Hardware is Unknown
  MTU 1500 bytes, BW 56 Kbit, DLY 20000 usec,
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation FRAME-RELAY, loopback not set
  DTR is pulsed for 1 seconds on reset
  LMI DLCI 1023  LMI type is CISCO  frame relay DCE
  FR SVC disabled, LAPF state down
  Last input never, output never, output hang never
  Last clearing of "show interface" counters 00:00:51
  Input queue: 0/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
     0 packets input, 0 bytes
0 packets output, 0 bytes

frameswitch#ping
Protocol [ip]: ip
Target IP address: 1.3.3.3
Repeat count [5]: 40
Datagram size [100]: 100
Timeout in seconds [2]: 2
Extended commands [n]: no
Sweep range of sizes [n]: n
Type escape sequence to abort.
Sending 40, 100-byte ICMP Echos to 1.3.3.3, timeout is 2 seconds:
......!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Success rate is 85 percent (34/40), round-trip min/avg/max = 60/60/64 ms

frameswitch#show connection all

ID   Name               Segment 1            Segment 2           State
========================================================================
1    ONE               Dialer0 101          Serial3 103          UP

frameswitch#


Chapter 7. Cisco Frame Relay End-to-End Keepalive

Frame Relay devices generally depend on the standard Frame Relay Local Management Interface (LMI) protocols to exchange keepalive messages in order to maintain the status of an active connection. This chapter describes the Cisco Frame Relay End-to-End Keepalive feature, which is an alternative keepalive mechanism supported only on Cisco devices. The Frame Relay End-to-End Keepalive feature allows a user to monitor the end-to-end status of an active Frame Relay permanent virtual circuit (PVC).

This chapter explains the Frame Relay End-to-End Keepalive mechanism and identifies the key benefits of the feature. The configuration tasks and commands required to enable the Frame Relay End-to-End Keepalive feature on a Cisco router are also explained. This chapter illustrates the Cisco IOS show and debug commands for monitoring and troubleshooting the feature on a Cisco router. A case study on the comparison between Frame Relay Network-to-Network Interface (NNI) LMI and the Frame Relay End-to-End Keepalive feature is presented at the end of the chapter.

The topics and questions that this chapter addresses include the following:

  • Overview of the Frame Relay End-to-End Keepalive feature

  • Frame Relay End-to-End Keepalive timers and modes

  • Configuring Frame Relay End-to-End Keepalive feature on a Cisco router

  • Monitoring and troubleshooting Frame Relay End-to-End Keepalive

  • Case study comparison between Frame Relay LMI protocol and Frame Relay End-to-End Keepalive

Upon the completion of this chapter, readers will recognize the limitations of the Frame Relay LMI protocol and will be able to appreciate the benefits of the Frame Relay End-to-End Keepalive feature's capability to detect the end-to-end status of a Frame Relay connection. Readers will learn about the operation of the Frame Relay End-to-End Keepalive feature, as well as the tasks and Cisco IOS commands necessary to configure it. Readers will be able to use the Cisco IOS show and debug commands to monitor and maintain Frame Relay End-to-End Keepalive configurations on Cisco routers.


Current Issues

Before the release of the Frame Relay End-to-End Keepalive feature, the LMI protocol remained the only form of communication channel available to provide a Frame Relay switch with the capability to carry information about the status of the PVC connections to the local Frame Relay access router (FRAD). The LMI specification is a connection status mechanism which provides information about the availability and unavailability of PVCs. The information is reported through the use of LMI status messages carried over special reserved DLCIs. There are currently three versions of LMI protocol available. The Cisco IOS supports the ANSI Annex D (T1.617), ITU Q.933 Annex A and the Gang of Four (Cisco) LMI protocols. Both the ANSI and ITU LMI protocols run on the reserved DLCI 0, whereas the Cisco LMI operates on the reserved DLCI 1023.

In a Frame Relay network, an end-to-end PVC connection between two end routers can be composed of multiple segments. The Frame Relay switch within the local PVC segment deduces the status of the remote PVC segment through an NNI interface and reports its status to the local router. Figure 7-1 illustrates the Frame Relay network.

Figure 7-1. Frame Relay Network with NNI Interfaces

The status information reported by the local Frame Relay switch is insufficient, however, because the LMI support within the Frame Relay switch is not end-to-end. Therefore, it does not reflect the true status of the end-to-end PVC. The following example explains this better, with reference to Figure 7-1.

Suppose the PVC segment between Frame Relay switch B and FRAD B encounters a fault and goes down. Frame Relay switch B might not propagate the PVC status changes to the Frame Relay switch A via NNI, and FRAD A will never know that the remote PVC has gone down. In many Frame Relay networks composed of multiple intermediate switching nodes, every Frame Relay switch along the path of the end-to-end PVC must implement NNI LMI protocol to propagate the status of the PVC from end to end. Thus, Frame Relay switch A and switch B must run NNI LMI between them to perform full status exchange to move the status from switch to switch and eventually to the local router. This is not easy to accomplish, because the intermediate nodes in a large Frame Relay network can be owned and managed by more than one network operator. The Frame Relay network requires all Frame Relay switches to be capable of running NNI LMI and coordinating full status exchange between them.

Moreover, when the Frame Relay network reports a PVC connection as inactive, the local router needs to decide whether to activate a backup circuit. Although this decision is easy to make on point-to-point interfaces, it is not as simple on multipoint interfaces. Currently, not all network layer protocols respond to PVC status changes. A suitable mechanism is therefore required to accurately determine that a PVC connection is inactive from end to end so that the appropriate backup mechanisms can be activated.


Solutions to Current Issues

Cisco released the Frame Relay End-to-End Keepalive feature in 1999 to allow peer Cisco routers in a Frame Relay network to effectively monitor the end-to-end status of a PVC connection. The Frame Relay End-to-End Keepalive feature provides a source of information about the remote router by verifying that data is getting through to the remote device via end-to-end, bidirectional communication. The Frame Relay End-to-End Keepalive mechanism helps to provide better management of individual virtual circuits (VCs) by ensuring periodic two-way communication between the end devices. Using Frame Relay End-to-End Keepalive, PVC-specific status and configuration information can be conveyed to better handle congestion situations and subsequently trigger any follow-up events, such as activating a backup link, if necessary.


Frame Relay End-to-End Keepalive Feature Defined

The Frame Relay End-to-End Keepalive feature is a Cisco proprietary protocol and is supported only on Cisco devices. It is an extension of the Frame Relay LMI protocol, and it runs over the data channels (DLCI) instead of the reserved DLCI used by the LMI protocols. The Frame Relay End-to-End Keepalive feature is configured in a Frame Relay map class and is supported on a per-PVC basis.

NOTE

The encapsulation method for Frame Relay End-to-End Keepalive packets is proprietary. Hence, the feature is available only on Cisco devices running IOS Release 12.0(5)T and later.

The Frame Relay End-to-End Keepalive Timers

The Frame Relay End-to-End Keepalive feature maintains two internal keepalive systems or timers, each for a different purpose. The first internal timer is used to send out keepalive requests on a user-configured interval and to handle responses to these requests. This is known as the send side. The second internal timer is for handling and replying to those requests. This is referred to as the receive side. On an end-to-end PVC, a device configured as the send side must communicate with the device configured as the receive side at the other end. Both the send timer and receive timer are user-configurable. The default values are 10 and 15 seconds, respectively. Figure 7-2 explains how the send side communicates with its counterpart receive side.

Figure 7-2. Send Side Communicates with Receive Side, and Vice Versa

At the send side, when the send timer timeout event occurs, the send side transmits a keepalive request to the receive side and waits for a reply. A reply message is used to reply to the request. When a reply is heard before the timer expires at the send side, the Frame Relay End-to-End Keepalive is recorded. However, if no reply is received, an error event is recorded.

The receive side operates in a similar fashion to the send side. The receive side waits for a request from the send side and sends out a reply to the request. The receive timer timeout event occurs when a request is not heard from the send side within a configured interval, and an error event is recorded. If a request is received before the receive timer expires, a success event is recorded.

In both cases, if a sufficient number of error events is observed, the keepalive status of the PVC is changed from UP to DOWN. The number of events necessary to change the keepalive status of the PVC from UP to the DOWN state is known as the event window. Similarly, if a sufficient number of consecutive success events are recorded, the status is changed from DOWN to UP. The event window is user-configurable. This approach can handle problems caused by intermittent line flaps on the end-to-end PVC.

By using Frame Relay End-to-End Keepalive, each end device can be associated with two statuses: send side and receive side. Table 7-1 provides a summary of the overall end-to-end PVC status as a result of the statuses of the send side, the receive side, and the local LMI.

Table 7-1. Overall Status of the VC as Determined by Keepalives and LMI

Keepalive Receive Side Status

Keepalive Send Side Status

LMI Status

Overall VC Status

UP

UP

UP

UP

DOWN

X

X

DOWN

X

DOWN

X

DOWN

UP

UP

DOWN

DOWN

Frame Relay End-to-End Keepalive Modes

Frame Relay End-to-End Keepalive can be configured in one of four modes: bidirectional, request, reply, and passive-reply.

Bidirectional Mode

In bidirectional mode, both the send side and the receive side are enabled. Both sides of a PVC connection send and respond to keepalive requests. The device's send side sends out and waits for replies to keepalive requests from the receive side of the other PVC device. Then the receive side waits for and replies to keepalive requests from the send side of the other PVC device.

The bidirectional mode sets the default value of the following parameters:

  • Send-side parameters

    Timer:

    10 seconds

    Event window:

    3

    Error threshold:

    2

    Success events:

    2

  • Receive-side parameters

    Timer:

    15 seconds

    Event window:

    3

    Error threshold:

    2

    Success events:

    2

If the device at one end is configured as bidirectional, the other device at the other end must also be configured as bidirectional.

Request Mode

In request mode, only the send side is enabled. The device sends out and waits for replies to its keepalive requests.

The request mode sets the default value of the following parameters:

  • Send-side parameters

    Timer:

    10 seconds

    Event window:

    3

    Error threshold:

    2

    Success events:

    2

If the device at one end is configured as request mode, the device at the other end must be configured as reply or passive-reply mode.

Reply Mode

In reply mode, only the receive side is enabled. The device waits for and replies to keepalive requests.

The reply mode sets the default value of the following parameters:

  • Receive-side parameters

    Timer:

    15 seconds

    Event window:

    3

    Error threshold:

    2

    Success events:

    2

If the device at one end is configured as reply mode, the device at the other end must be configured as request mode.

Passive-Reply Mode

In passive-reply mode, the device does not send out any keepalive requests. Rather, the device waits for the arrival of keepalive requests and responds to them. Moreover, it does not set any timers or keep track of the error counter.

If the device at one end is configured as passive-reply mode, the device at the other end must be configured as request mode.

Table 7-2 summarizes the possible combinations of the Frame Relay End-to-End Keepalive configuration modes between two end routers, FRADA and FRADB.

Table 7-2. Possible Combinations of the End-to-End Keepalive Configuration Modes Between FRADA and FRADB

FRADA

FRADB

Bidirectional

Bidirectional

Request

Reply

Request

Passive-Reply


Configuring Frame Relay End-to-End Keepalive

To configure Frame Relay End-to-End Keepalive on a Cisco router, perform the following commands beginning in global configuration mode:

Step 1. | Define a Frame Relay map class for enabling Frame Relay End-to-End Keepalive with the map-class frame-relay map-class-name global configuration command.
Step 2. | Under the Frame Relay map class, select the Frame Relay End-to-End Keepalive mode and configure Frame Relay End-to-End Keepalive with frame-relay end-to-end keepalive mode {bi-directional | request | reply | passive-reply}.
Step 3. | (optional) Modify the Frame Relay End-to-End Keepalive error threshold parameter by using the frame-relay end-to-end keepalive error-threshold {send | receive} count map-class configuration command. The error threshold count is the number of errors needed to flag the keepalive state from UP to DOWN. Valid range is from 1 to 32.
Step 4. | (optional) Modify the Frame Relay End-to-End Keepalive event window parameter by using the frame-relay end-to-end keepalive event-window {send | receive} count map-class configuration command. The event window count specifies the number of recent events that the device will use to check for errors. Valid range is from 1 to 32.
Step 5. | (optional) Modify the Frame Relay End-to-End Keepalive success events parameter by using the frame-relay end-to-end keepalive success-events {send | receive} count map-class configuration command. The success events count indicates the number of consecutive success events required to change the keepalive state from DOWN to UP. Valid range is from 1 to 32.
Step 6. | (optional) Modify the Frame Relay End-to-End Keepalive timer interval by using the frame-relay end-to-end keepalive timer {send | receive} interval. The timer interval is in seconds and the valid range is from 1 to 10,000 seconds.

NOTE

Use the no form of the commands to set the parameter values back to the default. For example, to restore the event window back to the default value of 3 in the send or reply mode, configure no frame-relay end-to-end keepalive event-window send under the Frame Relay map class.


Monitoring and Verifying Frame Relay End-to-End Keepalive

This section uses a configuration example to demonstrate the Cisco IOS show and debug commands for monitoring and maintaining Frame Relay End-to-End Keepalive status on a Cisco router. For this purpose, the network depicted in Figure 7-3 is set up.

Figure 7-3. Simple Network to Illustrate Frame Relay End-to-End Keepalive Operation

The configuration files of the routers used in the setup are shown in Example 7-1.

Example 7-1. Running Configuration of the Routers in Figure 7-1
! R1:
<output omitted>
interface Serial2/1
 no ip address
 encapsulation frame-relay
 frame-relay lmi-type cisco
!
interface Serial2/1.100 point-to-point
 ip address 10.1.1.1 255.255.255.0
 frame-relay interface-dlci 100
  class fr_eek
!
map-class frame-relay fr_eek
 frame-relay end-to-end keepalive mode bi-directional
! R2:
<output omitted>
frame-relay switching
!
interface Serial1/1
 no ip address
 encapsulation frame-relay
 frame-relay lmi-type ansi
 frame-relay intf-type nni
 clockrate 64000
 frame-relay route 200 interface Serial4/1 100
 !
interface Serial4/1
 no ip address
 encapsulation frame-relay
 frame-relay lmi-type cisco
 frame-relay intf-type dce
 clockrate 64000
 frame-relay route 100 interface Serial1/1 200
! R3:
<output omitted>
frame-relay switching
!
interface Serial3/1
 no ip address
 encapsulation frame-relay
 frame-relay lmi-type ansi
 frame-relay intf-type nni
 frame-relay route 200 interface Serial4/2 300
 !
interface Serial3/1
 no ip address
 encapsulation frame-relay
 frame-relay lmi-type ansi
 frame-relay intf-type nni
 clockrate 64000
 frame-relay route 200 interface Serial4/2 300
! R4:
<output omitted>
interface Serial1
 no ip address
 encapsulation frame-relay
!
interface Serial1.300 point-to-point
 ip address 10.1.1.8 255.255.255.0
frame-relay interface-dlci 300
class fr_eek
!
map-class frame-relay fr_eek
 frame-relay end-to-end keepalive mode bi-directional

When all the PVCs are UP, a show frame-relay end-to-end keepalive command in the global EXEC mode is performed at R1 to display the Frame Relay End-to-End Keepalive status. This is shown in Example 7-2.

Example 7-2. Output of the show frame-relay end-to-end keepalive Command at R1
R1#show frame-relay end-to-end keepalive

End-to-end Keepalive Statistics for Interface Serial2/1 (Frame Relay DTE)

DLCI = 100, DLCI USAGE = LOCAL, VC STATUS = ACTIVE (EEK UP)

SEND SIDE STATISTICS

Send Sequence Number: 225,      Receive Sequence Number: 222
Configured Event Window: 3,     Configured Error Threshold: 2
Total Observed Events: 228,     Total Observed Errors: 4
Monitored Events: 3,            Monitored Errors: 0
Successive Successes: 3,        End-to-end VC Status: UP

RECEIVE SIDE STATISTICS

Send Sequence Number: 221,      Receive Sequence Number: 220
Configured Event Window: 3,     Configured Error Threshold: 2
Total Observed Events: 226,     Total Observed Errors: 3
Monitored Events: 3,            Monitored Errors: 0
Successive Successes: 3,        End-to-end VC Status: UP

R4#show frame-relay end-to-end keepalive

End-to-end Keepalive Statistics for Interface Serial1 (Frame Relay DTE)

DLCI = 300, DLCI USAGE = LOCAL, VC STATUS = ACTIVE (EEK UP)

SEND SIDE STATISTICS

Send Sequence Number: 220,      Receive Sequence Number: 221
Configured Event Window: 3,     Configured Error Threshold: 2
Total Observed Events: 229,     Total Observed Errors: 6
Monitored Events: 3,            Monitored Errors: 0
Successive Successes: 3,        End-to-end VC Status: UP

RECEIVE SIDE STATISTICS

Send Sequence Number: 222,      Receive Sequence Number: 225
Configured Event Window: 3,     Configured Error Threshold: 2
Total Observed Events: 227,     Total Observed Errors: 3
Monitored Events: 3,            Monitored Errors: 0
Successive Successes: 3,        End-to-end VC Status: UP

In the output from Example 7-2, observe how the send side sequence counter at R1 matches the receive side sequence counter, and vice versa. By default, the send requests are sent out from the send side every 10 seconds, and the receive side expects to receive a request every 15 seconds. The timers can be adjusted by using the frame-relay end-to-end keepalive timer {send | recv} in the Frame Relay map class, but any misconfiguration of the send/recv timers is likely to create a sequence mismatch in the keepalive status and bring down the End-to-End keepalive status. The EEK keyword in the output of the show frame-relay end-to-end keepalive command indicates the End-to-End keepalive status.

When the Frame Relay connection between R3 and R4 is brought down, R1 detects the loss of keepalive packets from R4 and changes the status of DLCI 100 to INACTIVE accordingly. This is illustrated in Example 7-3.

Example 7-3. Status of PVC at R1 After Loss of End-to-End Keepalive Packets from R4
R4#show frame-relay pvc 300

PVC Statistics for interface Serial1 (Frame Relay DTE)

DLCI = 300, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE (EEK DOWN), INTERFACE = Serial1.300

  input pkts 666           output pkts 661          in bytes 24724
  out bytes 21438          dropped pkts 9           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 59        out bcast bytes 16739
pvc create time 00:53:21, last time pvc status changed 00:00:05

R1#show frame-relay pvc 100

PVC Statistics for interface Serial2/1 (Frame Relay DTE)

DLCI = 100, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE (EEK DOWN), INTERFACE = Serial2/1.100

  input pkts 661           output pkts 678          in bytes 23826
  out bytes 23273          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 62        out bcast bytes 18476
pvc create time 01:10:25, last time pvc status changed 00:01:32

Example 7-4 shows the Frame Relay End-to-End Keepalive status at R1 and R4.

Example 7-4. show frame-relay end-to-end keepalive Status After R4's Connection to R3 Has Been Brought Down
R4#show frame-relay end-to-end keepalive

End-to-end Keepalive Statistics for Interface Serial1 (Frame Relay DTE)

DLCI = 300, DLCI USAGE = LOCAL, VC STATUS = ACTIVE (EEK DOWN)

SEND SIDE STATISTICS

Send Sequence Number: 39,       Receive Sequence Number: 41
Configured Event Window: 3,     Configured Error Threshold: 2
Total Observed Events: 330,     Total Observed Errors: 33
Monitored Events: 3,            Monitored Errors: 3
Successive Successes: 0,        End-to-end VC Status: DOWN

RECEIVE SIDE STATISTICS

Send Sequence Number: 42,       Receive Sequence Number: 44
Configured Event Window: 3,     Configured Error Threshold: 2
Total Observed Events: 369,     Total Observed Errors: 71
Monitored Events: 3,            Monitored Errors: 3
Successive Successes: 0,        End-to-end VC Status: DOWN

R1#show frame-relay end-to-end keepalive

End-to-end Keepalive Statistics for Interface Serial2/1 (Frame Relay DTE)

DLCI = 100, DLCI USAGE = LOCAL, VC STATUS = ACTIVE (EEK DOWN)

SEND SIDE STATISTICS

Send Sequence Number: 77,       Receive Sequence Number: 42
Configured Event Window: 3,     Configured Error Threshold: 2
Total Observed Events: 334,     Total Observed Errors: 36
Monitored Events: 3,            Monitored Errors: 3
Successive Successes: 0,        End-to-end VC Status: DOWN

RECEIVE SIDE STATISTICS

Send Sequence Number: 41,       Receive Sequence Number: 39
Configured Event Window: 3,     Configured Error Threshold: 2
Total Observed Events: 322,     Total Observed Errors: 25
Monitored Events: 3,            Monitored Errors: 3
Successive Successes: 0,        End-to-end VC Status: DOWN

Monitoring Broken Connections

The requests sent out by the send side from R1 are unanswered by R4's receive side because of the broken connection at R4. By default, two consecutive success events must be recorded by the Frame Relay End-to-End Keepalive before the status is restored to the UP state. The event window and success event parameters are reconfigured to 10 and 5, respectively, at R1. Example 7-5 shows what happens at R1 after reestablishing the connection at R4.

Example 7-5. End-to-End Keepalive Status at R1 After the Connection Is Reestablished at R4
! R1:
<output omitted>
interface Serial2/1.100 point-to-point
 ip address 10.1.1.1 255.255.255.0
 frame-relay interface-dlci 100
  class fr_eek
!
map-class frame-relay fr_eek
 frame-relay end-to-end keepalive mode bidirectional
 frame-relay end-to-end keepalive event-window send 10
 frame-relay end-to-end keepalive success-events send 5

R1#show frame-relay end-to-end keepalive

End-to-end Keepalive Statistics for Interface Serial2/1 (Frame Relay DTE)

DLCI = 100, DLCI USAGE = LOCAL, VC STATUS = ACTIVE (EEK DOWN)

SEND SIDE STATISTICS

Send Sequence Number: 132,      Receive Sequence Number: 42
Configured Event Window: 10,    Configured Error Threshold: 2
Total Observed Events: 389,     Total Observed Errors: 91
Monitored Events: 10,           Monitored Errors: 10
Successive Successes: 0,        End-to-end VC Status: DOWN

RECEIVE SIDE STATISTICS

Send Sequence Number: 41,       Receive Sequence Number: 39
Configured Event Window: 3,     Configured Error Threshold: 2
Total Observed Events: 358,     Total Observed Errors: 61
Monitored Events: 3,            Monitored Errors: 3
Successive Successes: 0,        End-to-end VC Status: DOWN

After the connection at R4 is reestablished, R1 waits for five consecutive success events to be recorded before changing the end-to-end VC status and resetting the successes counter. Example 7-6 shows the results of the show frame-relay end-to-end keepalive command at router R1 after five consecutive success events are recorded. The output in Example 7-6 indicates the End-to-End Keepalive status at router R1 is in the UP state again.

Example 7-6. End-to-End Keepalive Status at R1 After the Connection Is Reestablished at R4 and After Five Consecutive Success Events Are Recorded
R1#show frame-relay end-to-end keepalive

End-to-end Keepalive Statistics for Interface Serial2/1 (Frame Relay DTE)

DLCI = 100, DLCI USAGE = LOCAL, VC STATUS = ACTIVE (EEK DOWN)

SEND SIDE STATISTICS

Send Sequence Number: 144,      Receive Sequence Number: 43
Configured Event Window: 10,    Configured Error Threshold: 2
Total Observed Events: 402,     Total Observed Errors: 103
Monitored Events: 10,           Monitored Errors: 9
Successive Successes: 1,        End-to-end VC Status: DOWN

RECEIVE SIDE STATISTICS

Send Sequence Number: 42,       Receive Sequence Number: 40
Configured Event Window: 3,     Configured Error Threshold: 2
Total Observed Events: 367,     Total Observed Errors: 69
Monitored Events: 3,            Monitored Errors: 2
Successive Successes: 1,        End-to-end VC Status: DOWN

R1#show frame-relay end-to-end keepalive

End-to-end Keepalive Statistics for Interface Serial2/1 (Frame Relay DTE)

DLCI = 100, DLCI USAGE = LOCAL, VC STATUS = ACTIVE (EEK DOWN)

SEND SIDE STATISTICS

Send Sequence Number: 145,      Receive Sequence Number: 44
Configured Event Window: 10,    Configured Error Threshold: 2
Total Observed Events: 403,     Total Observed Errors: 103
Monitored Events: 10,           Monitored Errors: 8
Successive Successes: 2,        End-to-end VC Status: DOWN

RECEIVE SIDE STATISTICS

Send Sequence Number: 43,       Receive Sequence Number: 41
Configured Event Window: 3,     Configured Error Threshold: 2
Total Observed Events: 368,     Total Observed Errors: 69
Monitored Events: 0,            Monitored Errors: 0
Successive Successes: 0,        End-to-end VC Status: UP

R1#show frame-relay end-to-end keepalive

End-to-end Keepalive Statistics for Interface Serial2/1 (Frame Relay DTE)

DLCI = 100, DLCI USAGE = LOCAL, VC STATUS = ACTIVE (EEK DOWN)

SEND SIDE STATISTICS

Send Sequence Number: 145,      Receive Sequence Number: 44
Configured Event Window: 10,    Configured Error Threshold: 2
Total Observed Events: 403,     Total Observed Errors: 103
Monitored Events: 10,           Monitored Errors: 8
Successive Successes: 3,        End-to-end VC Status: DOWN

RECEIVE SIDE STATISTICS

Send Sequence Number: 43,       Receive Sequence Number: 41
Configured Event Window: 3,     Configured Error Threshold: 2
Total Observed Events: 368,     Total Observed Errors: 69
Monitored Events: 0,            Monitored Errors: 0
Successive Successes: 0,        End-to-end VC Status: UP

R1#show frame-relay end-to-end keepalive

End-to-end Keepalive Statistics for Interface Serial2/1 (Frame Relay DTE)

DLCI = 100, DLCI USAGE = LOCAL, VC STATUS = ACTIVE (EEK DOWN)

SEND SIDE STATISTICS

Send Sequence Number: 147,      Receive Sequence Number: 46
Configured Event Window: 10,    Configured Error Threshold: 2
Total Observed Events: 405,     Total Observed Errors: 103
Monitored Events: 10,           Monitored Errors: 6
Successive Successes: 4,        End-to-end VC Status: DOWN

RECEIVE SIDE STATISTICS

Send Sequence Number: 45,       Receive Sequence Number: 43
Configured Event Window: 3,     Configured Error Threshold: 2
Total Observed Events: 370,     Total Observed Errors: 69
Monitored Events: 2,            Monitored Errors: 0
Successive Successes: 2,        End-to-end VC Status: UP

R1#show frame-relay end-to-end keepalive

End-to-end Keepalive Statistics for Interface Serial2/1 (Frame Relay DTE)

DLCI = 100, DLCI USAGE = LOCAL, VC STATUS = ACTIVE (EEK UP)

SEND SIDE STATISTICS

Send Sequence Number: 148,      Receive Sequence Number: 47
Configured Event Window: 10,    Configured Error Threshold: 2
Total Observed Events: 406,     Total Observed Errors: 103
Monitored Events: 0,            Monitored Errors: 0
Successive Successes: 0,        End-to-end VC Status: UP

RECEIVE SIDE STATISTICS

Send Sequence Number: 46,       Receive Sequence Number: 44
Configured Event Window: 3,     Configured Error Threshold: 2
Total Observed Events: 371,     Total Observed Errors: 69
Monitored Events: 3,            Monitored Errors: 0
Successive Successes: 3,        End-to-end VC Status: UP

Example 7-7 shows the output of the show frame-relay end-to-end keepalive command when the request, reply, and passive-reply modes are configured.

Example 7-7. show frame-relay end-to-end keepalive Output for Request, Reply, and Passive-Reply Modes
! Request mode:

R4#show frame-relay end-to-end keepalive

End-to-end Keepalive Statistics for Interface Serial1 (Frame Relay DTE)

DLCI = 300, DLCI USAGE = LOCAL, VC STATUS = ACTIVE (EEK UP)

SEND SIDE STATISTICS

Send Sequence Number: 255,      Receive Sequence Number: 255
Configured Event Window: 3,     Configured Error Threshold: 2
Total Observed Events: 1,       Total Observed Errors: 0
Monitored Events: 0,            Monitored Errors: 0
Successive Successes: 0,        End-to-end VC Status: UP

! Reply mode:

R4#show frame-relay end-to-end keepalive

End-to-end Keepalive Statistics for Interface Serial1 (Frame Relay DTE)

DLCI = 300, DLCI USAGE = LOCAL, VC STATUS = ACTIVE (EEK UP)

RECEIVE SIDE STATISTICS

Send Sequence Number: 0,        Receive Sequence Number: 0
Configured Event Window: 3,     Configured Error Threshold: 2
Total Observed Events: 0,       Total Observed Errors: 0
Monitored Events: 0,            Monitored Errors: 0
Successive Successes: 0,        End-to-end VC Status: UP

! Passive-reply mode:

R4#show frame-relay end-to-end keepalive

End-to-end Keepalive Statistics for Interface Serial1 (Frame Relay DTE)

DLCI = 400, DLCI USAGE = LOCAL, VC STATUS = ACTIVE (EEK UP)

RECEIVE SIDE STATISTICS

Send Sequence Number: 255,      Receive Sequence Number: 230
Configured Event Window: 0,     Configured Error Threshold: 0
Total Observed Events: 0,       Total Observed Errors: 0
Monitored Events: 0,            Monitored Errors: 0
Successive Successes: 0,        End-to-end VC Status: UP

Troubleshooting Frame Relay End-to-End Keepalive Connections

The debug frame-relay end-to-end keepalive {event | packet} command can be used to display the debug messages of the Frame Relay End-to-End Keepalive feature. The event and packet options of the debug frame-relay end-to-end keepalive command display different information for users. This command is useful for troubleshooting or maintaining the Frame Relay connection with the Frame Relay End-to-End Keepalive feature. Example 7-8 shows the output of the debug frame-relay end-to-end keepalive command with the packet option.

Example 7-8. Output of the debug frame-relay end-to-end keepalive packet Command on Router R1 in Figure 7-3
1w5d: EEK (o, Serial2/1.100 DLCI 100): 1 1 1 3 2 255 254
1w5d: EEK (i, Serial2/1.100 DLCI 100): 1 1 2 3 2 1 255
1w5d: EEK (i, Serial2/1.100 DLCI 100): 1 1 1 3 2 1 1
1w5d: EEK (o, Serial2/1.100 DLCI 100): 1 1 2 3 2 2 1

In Example 7-8, the first debug output message indicates that router R1 has sent out a Frame Relay End-to-End Keepalive request to router R4 on its local DLCI 100. This message presents the outgoing request. Then the second debug message in Example 7-8 describes an incoming reply. The seven number fields displayed in each debug output message have different significances. Table 7-3 explains the values of the number fields displayed in the first highlighted debug output message in Example 7-8:

EEK (o, Serial2/1.100 DLCI 100): 1 1 1 3 2 255 254

Table 7-3. Representations of the Number Fields in the debug frame-relay end-to-end keepalive packet Command

Field

Description

First field (1)

Information Element (IE)_type

Second field (1)

IE length

Third field (1)

Report ID. 1 = request, 2 = reply

Fourth field (3)

Next IE type. 3 = LIV ID (Keepalive ID)

Fifth field (2)

IE length (Keepalive IE)

Sixth field (255)

Send sequence number

Seventh field (254)

Receive sequence number

Example 7-9 shows the output of the debug frame-relay end-to-end keepalive event command on Router R1 in Figure 7-3.

Example 7-9. Output of the debug frame-relay end-to-end keepalive event Command on Router R1 in Figure 7-3
1w5d: EEK SUCCESS (request, Serial2/1.100 DLCI 100)
1w5d: EEK SUCCESS (reply, Serial2/1.100 DLCI 100)
1w5d: EEK SUCCESS (request, Serial2/1.100 DLCI 100)
1w5d: EEK receiver timeout (Serial2/1.100 DLCI 100)
1w5d: EEK stopped (Serial2/1.100 DLCI 100)

In Example 7-9, the debug frame-relay end-to-end keepalive event command displays the status of the Frame Relay End-to-End Keepalive between the local Frame Relay router and the far end Frame Relay router. When both end-to-end routers are functional and communicating, the EEK SUCCESS message indicates the successful exchange of Frame Relay End-to-End Keepalive packets. Router R1 has detected the far end router R4 has gone down after the serial interface (serial 1) of router R4 is shut down.


Summary

This chapter covered the use of the Cisco Frame Relay End-to-End Keepalive feature on Cisco routers. This feature enables Cisco routers to monitor the status of Frame Relay PVC connections for the purpose of network management or backup applications. This feature is supported only on Cisco devices. The Frame Relay End-to-End Keepalive protocol offers a function similar to the standard Frame Relay LMI protocol, but Frame Relay End-to-End Keepalive operates entirely on the data channel rather than on the signaling channel. The Frame Relay End-to-End Keepalive feature maintains two internal timers and supports four modes of operation.

This chapter also explained the configuration tasks and commands required to enable the Frame Relay End-to-End Keepalive feature on a Cisco router. In addition, this chapter illustrated the relevant Cisco IOS show and debug commands for monitoring and troubleshooting the feature. In the case study section of this chapter, a comparison between the standard Frame Relay LMI and the Cisco Frame Relay End-to-End Keepalive feature is made. A comparison chart highlighting the differences between Frame Relay LMI and Frame Relay End-to-End Keepalive is depicted in Table 7-4.

Table 7-4. Comparison Chart Between LMI and Frame Relay End-to-End Keepalive

Frame Relay Circuit Management Mechanism

Advantages

Disadvantages

LMI

LMI is an open standard supported by many vendors.

Does not reflect true end-to-end status of a PVC.

All intermediate nodes in the Frame Relay network have to implement NNI LMI and synchronize to exchange status messages.

Not easy to implement a backup mechanism to respond to VC status changes reported via LMI.

Frame Relay End-to-End Keepalive

Reflects true end-to-end status of the PVC, ensuring consistency of information between end hosts.

Does not depend on NNI LMI to propagate status changes.

Frame Relay End-to-End Keepalive provides better management of VCs and handling of congestion situations.

Cisco proprietary and supported only on Cisco devices.

The next chapter discusses the Cisco Frame Relay to ATM Interworking feature. The Cisco Frame Relay to ATM Interworking feature allows dissimilar ATM and Frame Relay networks to exchange information.


Review Questions

1: | Name the possible problems that can be averted by using Frame Relay End-to-End Keepalive instead of the NNI LMI for switch-to-switch communication.
2: | What is the use of the event window parameter?
3: | What are the common applications of the Frame Relay End-to-End Keepalive feature?
4: | What are the likely consequences when the time intervals for the send and receive timers are misconfigured?


Reference

Cisco IOS 12.0(5)T WAN Configuration Guide:http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/120newft/120t/120t5/frkeep.htm


Case Study: Using LMI and Frame Relay End-to-End Keepalive

In this section, a test is conducted to study the different characteristics between using LMI protocol and Frame Relay End-to-End Keepalive for network monitoring in a Frame Relay network. The network topology shown in Figure 7-4 is used for this purpose.

Figure 7-4. Verifying Differences Between Using LMI and End-to-End Keepalive for Network Status Monitoring

The configuration files of the routers in Figure 7-4 are shown in Example 7-10.

Example 7-10. Configuration of the Routers in Figure 7-4
! R1:
<output omitted>
!
ip routing
!
interface Serial2/1
 no ip address
 encapsulation frame-relay
 frame-relay lmi-type cisco
!
interface Serial2/1.100 point-to-point
 ip address 10.1.1.1 255.255.255.0
 frame-relay interface-dlci 100

! FRswitch1:
<output omitted>
!
frame-relay switching
!
interface Serial1/1
 no ip address
 encapsulation frame-relay
 clockrate 64000
 frame-relay lmi-type ansi
 frame-relay intf-type nni
 frame-relay route 200 interface Serial4/1 100
 !
interface Serial4/1
 no ip address
 encapsulation frame-relay
 clockrate 64000
 frame-relay lmi-type cisco
 frame-relay intf-type dce
 frame-relay route 100 interface Serial1/1 200

! Frswitch2:
<output omitted>
!
frame-relay switching
!
interface Serial3/1
 no ip address
 encapsulation frame-relay
 clockrate 64000
 frame-relay lmi-type ansi
 frame-relay intf-type nni
 frame-relay route 200 interface Serial4/2 300
 !
interface Serial4/2
 no ip address
 encapsulation frame-relay
 clockrate 64000
 frame-relay lmi-type q933a
 frame-relay intf-type nni
 frame-relay route 300 interface Serial3/1 200

! Frswitch3:
<output omitted>
!
frame-relay switching
!
interface Serial0
 no ip address
 encapsulation frame-relay
 clockrate 64000
 frame-relay lmi-type q933a
 frame-relay intf-type nni
 frame-relay route 300 interface Serial1 400
!
interface Serial1
 no ip address
 encapsulation frame-relay
 clockrate 64000
 frame-relay intf-type dce
 frame-relay route 400 interface Serial0 300

! R2:
<output omitted>
!
ip routing
!
interface Serial1
 no ip address
 encapsulation frame-relay
!
interface Serial1.400 point-to-point
 ip address 10.1.1.8 255.255.255.0
 frame relay interface-dlci 400

Example 7-11 displays the statuses of the Frame Relay PVC connections configured on the routers in Figure 7-4.

Example 7-11. PVC Statuses of the Routers in Figure 7-4
R1#show frame-relay pvc

PVC Statistics for interface Serial2/1 (Frame Relay DTE)

              Active     Inactive      Deleted       Static
  Local          1            0            0            0
  Switched       0            0            0            0
  Unused         0            0            0            0

DLCI = 100, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial2/1.100

  input pkts 39236         output pkts 33891        in bytes 1992947
  out bytes 262457         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 85        out bcast bytes 25330
pvc create time 3d20h, last time pvc status changed 00:00:41

FRswitch1#show frame-relay pvc

PVC Statistics for interface Serial1/1 (Frame Relay NNI)

              Active     Inactive      Deleted       Static
  Local          0            0            0            0
  Switched       1            0            0            0
  Unused         0            0            0            0

DLCI = 200, DLCI USAGE = SWITCHED, PVC STATUS = ACTIVE, INTERFACE = Serial1/1
LOCAL PVC STATUS = ACTIVE, NNI PVC STATUS = ACTIVE

  input pkts 39247         output pkts 33899        in bytes 1996170
  out bytes 400045         dropped pkts 0           in pkts dropped 0
  out pkts dropped 0                out bytes dropped 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 39247
  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 3d20h, last time pvc status changed 3d20h

PVC Statistics for interface Serial4/1 (Frame Relay DCE)

              Active     Inactive      Deleted       Static
  Local          0            0            0            0
  Switched       1            0            0            0
  Unused         0            0            0            0

DLCI = 100, DLCI USAGE = SWITCHED, PVC STATUS = ACTIVE, INTERFACE = Serial4/1

  input pkts 33902         output pkts 39247        in bytes 400939
  out bytes 1996170        dropped pkts 0           in pkts dropped 0
  out pkts dropped 0                out bytes dropped 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 33899
  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 3d20h, last time pvc status changed 3d20h

FRswitch2#show frame-relay pvc

PVC Statistics for interface Serial3/1 (Frame Relay NNI)

              Active     Inactive      Deleted       Static
  Local          0            0            0            0
  Switched       1            0            0            0
  Unused         0            0            0            0

DLCI = 200, DLCI USAGE = SWITCHED, PVC STATUS = ACTIVE, INTERFACE = Serial3/1
LOCAL PVC STATUS = ACTIVE, NNI PVC STATUS = ACTIVE

  input pkts 33901         output pkts 39249        in bytes 400641
  out bytes 1996756        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 33901
  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 3d20h, last time pvc status changed 3d20h

PVC Statistics for interface Serial4/2 (Frame Relay NNI)

              Active     Inactive      Deleted       Static
  Local          0            0            0            0
  Switched       1            0            0            0
  Unused         0            0            0            0

DLCI = 300, DLCI USAGE = SWITCHED, PVC STATUS = ACTIVE, INTERFACE = Serial4/2
LOCAL PVC STATUS = ACTIVE, NNI PVC STATUS = ACTIVE

  input pkts 39249         output pkts 33901        in bytes 1996756
  out bytes 400641         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 39249
  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 3d20h, last time pvc status changed 3d20h

FRswitch3#show frame-relay pvc

PVC Statistics for interface Serial0 (Frame Relay NNI)

              Active     Inactive      Deleted       Static
  Local          0            0            0            0
  Switched       1            0            0            0
  Unused         0            0            0            0

DLCI = 300, DLCI USAGE = SWITCHED, PVC STATUS = ACTIVE, INTERFACE = Serial0
LOCAL PVC STATUS = ACTIVE, NNI PVC STATUS = ACTIVE

  input pkts 33904         output pkts 39252        in bytes 401535
  out bytes 1997635        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 33904
  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 3d21h, last time pvc status changed 3d20h

PVC Statistics for interface Serial1 (Frame Relay DCE)

              Active     Inactive      Deleted       Static
  Local          0            0            0            0
  Switched       1            0            0            0
  Unused         0            0            0            0

DLCI = 400, DLCI USAGE = SWITCHED, PVC STATUS = ACTIVE, INTERFACE = Serial1

  input pkts 39253         output pkts 33905        in bytes 1997928
  out bytes 401833         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 39253
  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 3d20h, last time pvc status changed 3d20h

R2show frame-relay pvc

PVC Statistics for interface Serial1 (Frame Relay DTE)

              Active     Inactive      Deleted       Static
  Local          1            0            0            0
  Switched       0            0            0            0
  Unused         0            0            0            0

DLCI = 400, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial1.400

  input pkts 33907         output pkts 39255        in bytes 402429
  out bytes 1863738        dropped pkts 105         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 5556      out bcast bytes 1627360
pvc create time 3d20h, last time pvc status changed 3d19h

Network Connection Failures

In this test, the line between the FRswitch3 and R2 router is shut down to simulate a network connection failure in the network. This section looks at how fast the status change at one end can be propagated to the R1 router at the other end of the circuit by using either LMI or Frame Relay End-to-End Keepalive. The routers in the network are initially configured to use LMI. The routers are then reconfigured to use Frame Relay End-to-End Keepalive. In Example 7-12, the line between FRswitch3 and R2 is brought down and the time it takes for R1 to detect the status changes is measured.

Example 7-12. Detecting the Status Change at R1 via LMI After the Network Failure Simulation
R2#config terminal
R2(config)#interface serial1
R2(config-if)#shutdown

R1#show frame-relay pvc

PVC Statistics for interface Serial2/1 (Frame Relay DTE)

              Active     Inactive      Deleted       Static
  Local          0            1            0            0
  Switched       0            0            0            0
  Unused         0            0            0            0

DLCI = 100, DLCI USAGE = LOCAL, PVC STATUS = INACTIVE, INTERFACE = Serial2/1.100

  input pkts 39269         output pkts 33927        in bytes 2000553
  out bytes 271633         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 113       out bcast bytes 33674
pvc create time 3d21h, last time pvc status changed 00:01:09

In the measurement for LMI, it takes approximately 30 to 35 seconds for LMI to propagate the status change from R2 through the Frame Relay switches to R1.

R1 and R2 are now reconfigured to use Frame Relay End-to-End Keepalive. Both R1 and R2 are configured with bidirectional mode, and the default values for the timer, the event window, the success event, and the error threshold are used.

NOTE

You do not have to disable LMI on the end routers in order to use Frame Relay End-to-End Keepalive. When a Frame Relay map class configured with Frame Relay End-to-End Keepalive is applied to a DLCI, the DLCI automatically uses End-to-End Keepalive as the preferred mode of communication with the end device.

The configuration changes are shown in Example 7-13.

Example 7-13. Reconfiguring R1 and R2 to Use Frame Relay End-to-End Keepalive
! R1:
interface Serial2/1
 no ip address
 encapsulation frame-relay
 clockrate 64000
 frame-relay lmi-type cisco
!
interface Serial2/1.100 point-to-point
 ip address 10.1.1.1 255.255.255.0
 no ip route-cache
 frame-relay interface-dlci 100
  class fr_eek
!
map-class frame-relay fr_eek
 frame-relay end-to-end keepalive mode bidirectional

! R2:
interface Serial1
 no ip address
 encapsulation frame-relay
!
interface Serial1.400 point-to-point
 ip address 10.1.1.8 255.255.255.0
 no ip route-cache
 frame-relay interface-dlci 400
class fr_eek
!
map-class frame-relay fr_eek
 frame-relay end-to-end keepalive mode bi-directional

R1#show frame-relay end-to-end keepalive

End-to-end Keepalive Statistics for Interface Serial2/1 (Frame Relay DTE)

DLCI = 100, DLCI USAGE = LOCAL, VC STATUS = ACTIVE (EEK UP)

SEND SIDE STATISTICS

Send Sequence Number: 1,        Receive Sequence Number: 2
Configured Event Window: 3,     Configured Error Threshold: 2
Total Observed Events: 4,       Total Observed Errors: 0
Monitored Events: 3,            Monitored Errors: 0
Successive Successes: 3,        End-to-end VC Status: UP

RECEIVE SIDE STATISTICS

Send Sequence Number: 1,        Receive Sequence Number: 255
Configured Event Window: 3,     Configured Error Threshold: 2
Total Observed Events: 3,       Total Observed Errors: 0
Monitored Events: 2,            Monitored Errors: 0
Successive Successes: 2,        End-to-end VC Status: UP

R2#show frame-relay end-to-end keepalive

End-to-end Keepalive Statistics for Interface Serial1 (Frame Relay DTE)

DLCI = 400, DLCI USAGE = LOCAL, VC STATUS = ACTIVE (EEK UP)

SEND SIDE STATISTICS

Send Sequence Number: 8,        Receive Sequence Number: 9
Configured Event Window: 3,     Configured Error Threshold: 2
Total Observed Events: 13,      Total Observed Errors: 2
Monitored Events: 3,            Monitored Errors: 0
Successive Successes: 3,        End-to-end VC Status: UP

RECEIVE SIDE STATISTICS

Send Sequence Number: 9,        Receive Sequence Number: 8
Configured Event Window: 3,     Configured Error Threshold: 2
Total Observed Events: 12,      Total Observed Errors: 1
Monitored Events: 3,            Monitored Errors: 0
Successive Successes: 3,        End-to-end VC Status: UP

Again, the line between FRswitch3 and R2 router is brought down, but this time, observe how rapidly Frame Relay End-to-End Keepalive can detect the status changes at R1. This is shown in Example 7-14.

Example 7-14. Detecting the Status Change Via End-to-End Keepalive at R1 Router
R2#config terminal
R2(config)#interface serial1
R2(config-if)#shutdown

R1#show frame-relay pvc

PVC Statistics for interface Serial2/1 (Frame Relay DTE)

              Active     Inactive      Deleted       Static
  Local          0            1            0            0
  Switched       0            0            0            0
  Unused         0            0            0            0

DLCI = 100, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE (EEK DOWN), INTERFACE = Serial2/1.100

  input pkts 39344         output pkts 34004        in bytes 2003916
  out bytes 274500         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 121       out bcast bytes 36058
  pvc create time 3d21h, last time pvc status changed 00:00:01

Using Frame Relay End-to-End Keepalive with the default values, it takes approximately 20 seconds for R1 to detect the PVC status change at R2. The default values for the timer, the event window, and the error threshold can be configured accordingly to provide a faster response.


Part III. Cisco Frame Relay Solutions for Traffic Management

Previous Page
Next Page

Part III: Cisco Frame Relay Solutions for Traffic Management

Chapter 8 Frame Relay to ATM Interworking

Chapter 9 Adaptive Frame Relay Traffic Shaping for Interface Congestion

Chapter 10 Point-to-Point Protocol (PPP) over Frame Relay

Chapter 11 Frame Relay Switched Virtual Circuit (SVC)

Chapter 12 X.25 over Frame Relay: Using the Annex G Feature

Chapter 13 Frame Relay Enhanced Local Management Interface (ELMI)

Chapter 14 Multilink Frame Relay (FRF.16)

Chapter 15 Compression over Frame Relay

Chapter 16 Frame Relay Fragmentation


Chapter 8. Frame Relay to ATM Interworking

Frame Relay has enjoyed much success with end users primarily because of its increased performance and reduced cost. Asynchronous Transfer Mode (ATM), commonly known as cell relay, is a popular WAN technology broadly deployed on high-speed networks. ATM delivers higher availability and speed over Frame Relay and is the most widely deployed backbone technology. Both Frame Relay and ATM networks are widespread today. Each protocol is unique in its own way, and each has its own advantages. This chapter explains Cisco's implementation of the Frame Relay to ATM Interworking feature, which provides the functionalities to allow disparate Frame Relay and ATM networks to communicate and exchange information despite their dissimilar network protocols.

This chapter explains the main reasons for connecting Frame Relay networks with ATM networks. This chapter focuses on the Frame Relay Forum Implementation Agreements Document Number FRF.5 and Document Number FRF.8.1, largely the basis for Cisco Frame Relay to ATM Interworking feature. The key differences between FRF.5 and FRF.8.1 will be discussed. Then, this chapter introduces the Cisco router products capable of supporting both methods of implementation. Subsequently, this chapter explains the configuration tasks and the Cisco IOS commands for configuring FRF.5 and FRF.8.1 on the supported Cisco platforms. Finally, this chapter demonstrates the relevant Cisco IOS show and debug commands for monitoring and troubleshooting FRF.5 and FRF.8.1 on Cisco routers.

NOTE

The Frame Relay Forum Implementation Agreements FRF.5 and FRF.8.1 can be downloaded from http://www.mplsforum.org/frame/Approved/FRF.5/frf.5.pdf. and http://www.mplsforum.org/frame/Approved/FRF.8/FRF.8.1.pdf.

This chapter begins with a brief overview of the fundamentals of the ATM technology. Because this book focuses on Frame Relay, a basic understanding of the ATM technology is assumed, and this chapter does not go extensively into explaining how the ATM protocol works. ATM technology and the Cisco ATM features are well explained in Cisco Press's Cisco ATM Solutions by Galina Diker Pildush (ISBN: 1578702135). Alternatively, a beginner's guide on ATM can be downloaded from the ATM Forum (http://www.atmforum.com/aboutatm/guide.html).

The topics and questions that this chapter addresses include the following:

  • A brief overview of ATM technology

  • The requirements for Frame Relay and ATM Interworking

  • Frame Relay Forum Implementation Agreement FRF.5

  • Frame Relay Forum Implementation Agreement FRF.8.1

  • Configuring FRF.5 and FRF.8.1 on Cisco routers

  • Monitoring and maintaining FRF.5 and FRF.8.1 on Cisco routers

After completing this chapter, readers will understand ATM as a reliable high-speed backbone technology. Readers will recognize the benefits of interworking Frame Relay with ATM networks by converging the two completely different data link layer protocols. Readers will become familiar with the basic operations of the two implementation agreements that are defined by the Frame Relay Forum: FRF.5 and FRF.8.1. Readers will also become familiar with the tasks and the Cisco IOS commands required to configure FRF.5 and FRF.8.1 on Cisco routers. Finally, readers will be able to monitor and maintain FRF.5 and FRF.8.1 configurations on Cisco routers using Cisco IOS show and debug commands.


ATM Technology

ATM is a reliable and high-speed data link layer technology that guarantees a certain or predefined quality of service for voice, video, or data traffic. The history of the ATM technology dates back to 1980. At that time, the high demand for fast speed and reliable access over long distances led the ITU-T and other standards groups to establish an industry standard for Broadband Integrated Services Digital Network (B-ISDN). The new generation of networks defined by the B-ISDN standard would offer bandwidth greater than those provided by the Narrowband Integrated Services Digital Networks (N-ISDN). By 1990, ATM technology provided B-ISDN with the capability to offer subscribers a large variety of high speed services at variable data rates.

Today, ATM is a broadband technology commonly deployed within core backbone networks over optical infrastructures to switch voice, video, or data packets at ultrahigh speeds. ATM is easy to manage and provides sophisticated Quality of Service (QoS) features in the different layers of the ATM protocol. These features make ATM extremely robust and suitable for supporting multimedia traffic. ATM is designed to support high-speed networks at data rates greater than those of Frame Relay, such as OC-192 (10 Gbps). Moreover, ATM requires dedicated hardware built on Application Specific Integrated Circuit (ASIC), which enables faster processing on the interface.

Like Frame Relay, ATM transports data via virtual circuits (VCs), either permanent (PVCs) or switched (SVCs), which are used to switch users' data from the source to the destination.

Comparing ATM to Frame Relay Protocol

Unlike the Frame Relay protocol, which uses a variable-length frame, ATM employs a fixed-length packet format of 53 bytes, most commonly referred to as a cell. ATM uses the segmentation and reassembly (SAR) function in the ATM Adaptation Layer (AAL) to divide information handed down from the upper layers into these 53-byte cells. Out of the 53 bytes in the ATM cell, 5 bytes are reserved for the ATM header, and the remaining 48 bytes make up the payload. These fixed-length cells are sent into the ATM network to their destination, where they are reassembled by the remote ATM equipment. A cyclic redundancy check (CRC), known as the Header Error Control (HEC), is computed in the ATM headers to allow the destination ATM device to detect bit errors, loss of cells, or cells that are out of sequence.

Figure 8-1 illustrates a standard ATM cell comprised of a 5-byte header and a 48-byte information field. Inside the ATM cell header, there is a 12-bit virtual path identifier (VPI) field, which is used to identify the virtual path in the ATM circuit. The 16-bit virtual circuit identifier (VCI) field is used to identify the VC within a virtual path. In many situations, the virtual path can be thought of as a bundle or collection of VCs. The function of the VCI is similar to the role played by the DLCI in Frame Relay.

Figure 8-1. Standard ATM Cell Format (NNI)

NOTE

On Cisco routers, it is possible to change the value of the VCI in the virtual path configurations to increase the range of the VPI.

The 3-bit payload type (PT) field is used to indicate whether the ATM cell consists of user or control data. The 1-bit cell loss priority (CLP) functions very much like the discard eligibility (DE) bit in the standard Frame Relay headers. It is used to indicate whether the cell should be discarded if it encounters extreme congestion as it moves through the ATM network. Then the 8-bit HEC field is used to calculate the checksum of the headers. Finally, the information field makes up the remaining 48 bytes to create the entire 53-byte ATM cell.


Interworking Frame Relay with ATM

Frame Relay has became immensely popular because it is an efficient and simple protocol designed to transport data traffic effectively up to the data rates of T3/E3 without incurring the excessive overheads commonly present in WAN protocols such as X.25. The resultant popularity of Frame Relay services has led to a rapid growth of high concentrations of low-speed remote Frame Relay connections. However, because of Frame Relay's simplicity, the basic Frame Relay protocol lacks the necessary features, such as differentiated classes of service, QoS, and class of service, to support multiservice networks. On the contrary, ATM is able to make up for what Frame Relay can't deliver. ATM is designed to support a wide range of service requirements and to provide different QoS service levels at very high speeds: OC-3 (155 Mbps), OC-12 (655 Mbps), OC-48 (2.4 Gbps), or higher. For this reason, Frame Relay and ATM technologies complement each other perfectly.

Figure 8-2 shows a converged hybrid network where Frame Relay service users running at speeds lower than T3/E3 are connecting to the higher-speed ATM backbone running at DS3 (44Mbps) or faster. Service providers recognize the benefits of connecting lower-speed Frame Relay networks to the high-speed ATM backbones to improve economies of scale and network scalability. The ATM backbone is used as an alternative to a leased line and provides cost savings over leased lines. With Frame Relay to ATM Interworking, end users can adopt the technology best suited to their needs at their location and ensure optimization of price and performance. Moreover, a hybrid network helps to smooth evolution between different emerging technologies and lowers the overall cost of network ownership.

Figure 8-2. Hybrid Network of Frame Relay and ATM

Previous Page
Next Page


Frame Relay Forum Implementation Agreement Document Number FRF.5

The functional specifications of network interworking between Frame Relay and ATM are defined in the Frame Relay Forum Implementation Agreement Document Number FRF.5. FRF.5 describes the implementation agreement on PVC network interworking between Frame Relay and ATM protocols, jointly agreed upon by the Frame Relay Forum and the ATM Forum. The complete FRF.5 documentation can be downloaded from the Frame Relay Forum's web site address at http://www.mplsforum.org/frame/Approved/FRF.5/frf.5.pdf.

FRF.5, also known as Frame Relay/ATM PVC Network Interworking, allows two Frame Relay peer devices to communicate with each other via an interworking function over an ATM network supporting FRF.5. As you shall see later in the "Frame Relay Forum Implementation Agreement Document Number FRF.8.1" section on FRF.8.1, FRF.5 is in contrast with FRF.8.1 service interworking. In the latter case, a Frame Relay service user interoperates directly with an ATM service user.

The interworking function can be a part of the Frame Relay or ATM device, or it can be a standalone device that interfaces directly between the Frame Relay and ATM networks. The specifications in FRF.5 do not indicate where the interworking function needs to be placed.

Figure 8-3 illustrates the possible locations for the interworking function.

Figure 8-3. Example of Equivalent Interworking Function

As shown in Figure 8-3, there are three possible configurations where the interworking function can be placed. The main purpose of the network interworking function is to translate between the Frame Relay and ATM protocol stacks connecting the Frame Relay and ATM networks.

A user's applications have no knowledge of the interworking function taking place at the network edge. Data from the upper layers is transported over Frame Relay, over ATM, and then over Frame Relay again at the final destination. The network interworking function is totally transparent to the Frame Relay end devices, meaning the Frame Relay service users have no knowledge that they are connected to each other over an ATM network. Figure 8-4 illustrates a typical diagram of an FRF.5 network, whereby the interworking function performs the protocol translation process between the Frame Relay and ATM protocol stacks.

Figure 8-4. FRF.5 Frame Relay to ATM Network Interworking

In this section, note the new terms observed in the ATM protocol stacks: Frame Relay Service Specific Convergence Sublayer (FR-SSCS) and Common Part Convergence Sublayer (CPCS). These terms are used often in the discussion of Frame Relay to ATM interworking. Recall from Chapter 1, "Introduction to Frame Relay," that the standard Q.922 Frame Relay basic header structure consists of a 2-byte address field. The standard Frame Relay frame is revisited in Figure 8-5.

Figure 8-5. Standard Frame Relay Frame with Q.922H Headers (2-byte Address Field)

Compare the format of the Q.922 Frame Relay headers in Figure 8-5 with the format of the FR-SSCS protocol data unit (PDU) in the next figure (Figure 8-6). The FR-SSCS uses a PDU format almost identical to the Q.922 Frame Relay headers (both are 2 bytes long) but without the FCS and flags. The FRF.5 implementation agreement specifies a default FR-SSCS format with a 2-byte address field. The use of a 4-byte address field is specified, but its implementation is optional. The 3-byte address field format is not used presently. Cisco's implementation only supports the default FR-SSCS format.

Figure 8-6. The Default FR-SSCS PDU with a 2-byte Address Field

Frame Relay Frame Entering an ATM Network

When a Frame Relay frame enters an ATM network, the interworking function translates the protocol by creating a FR-SSCS frame out of the standard Frame Relay frame. The resultant FR-SSCS frame is placed in a CPCS PDU and is handed to the ATM protocol stacks. In fact, this process involves a direct mapping from the address field in the Q.922 Frame Relay header to the address field in the FR-SSCS.

Then the CPCS sublayer adds an 8-byte trailer to the frame that includes a 32-bit CRC checksum computed across the entire PDU to provide error detection over the FR-SSCS PDU. In addition, a length field and padding bits are added in the trailer to ensure that the CPCS-PDU has a size that is an integral multiple of 48 bytes. This becomes the payload of the ATM cells. There are two 1-byte fields in the trailers that are unused: Common Part Indicator (CPI) and CPCS User-to-User notification (CPCS-UU). After the CPCS-PDU is constructed, the CPCS sublayer hands the CPCS PDU to the SAR function.

The step performed by the CPCS sublayer to insert padding bits into the PDU is vital to the SAR function. The CPCS function allows the SAR sublayer to segment the CPCS PDU equally into 48-byte blocks. Then the ATM layer places each 48-byte block into the payload field of an ATM cell. The 5-byte ATM headers are appended to each 48-byte payload field to construct a 53-byte ATM cell ready for transmission. The functions performed by CPCS and SAR sublayers are collectively known as ATM adaptation layer 5 (AAL5).

Cisco's implementation of FRF.5 allows a single VC or multiple (many-to-one) Frame Relay VCs from the same interface to be mapped to a single ATM VC. Many-to-one multiplexing is done by mapping the DLCI address field in the FR-SSCS PDU to the ATM VPI/VCI value of the outgoing ATM VC. Both one-to-one and many-to-one multiplexing methods are supported by Cisco. Figure 8-7 illustrates the state when multiple DLCIs are multiplexed to a single ATM VC.

Figure 8-7. Multiplexing Multiple DLCIs to a Single ATM VC

In Figure 8-7, a frame is delivered from a host to the router performing the interworking function on DLCI 200. Because the router is configured to map DLCI 200 to VPI/VCI 2/10, the router sends the frame received on DLCI 200 from the Frame Relay network to its remote destination over the ATM network on VPI/VCI 2/10. At the destination, the end router performing the interworking function strips off the ATM headers and inspects the FR-SSCS address field. The address field indicates a destination DLCI of 200, and the end router delivers the frame on DLCI 200 to its destination host.

Figure 8-8 illustrates how the fields in the FR-SSCS PDU are mapped to the relevant fields in an ATM cell to allow multiplexing of multiple Frame Relay VCs to one ATM VC.

Figure 8-8. Many-to-One Multiplexing Using Frame Relay DLCI to ATM VPI/VCI Mappings

Referring to Figure 8-8, it is evident that both Frame Relay DLCI and the ATM VPI/VCI pair have an equivalent purpose; they are fields used in their respective protocol headers to identify a VC. During Frame Relay frame to ATM cell multiplexing, the value of the Frame Relay DLCI is mapped to the corresponding ATM VPI/VCI fields to identify a VC on the ATM network. Next, the congestion notification fields in the Frame Relay headers (FECN, DE bits) are mapped to the corresponding fields in the ATM headers (CLP, EFCI). This allows the network to preserve the congestion information across the Frame Relay and ATM boundary.

Therefore, using the FR-SSCS to ATM VPI/VCI mapping, it is possible to multiplex multiple Frame Relay DLCIs to a single ATM VC. The same approach is used to demultiplex the ATM VPI/VCI to the Frame Relay DLCIs at the destination.

NOTE

For one-to-one connections, the default FR-SSCS DLCI value of 1022 is used. The FR-SSCS value is user-configurable in the IOS and is in the range of 16 to 991.

If you decide not to use the default FR-SSCS value of 1022 when configuring multiplexing between multiple Frame Relay VCs to one ATM VC, you must ensure that the interworking functions at both legs of the network are referring to the common FR-SSCS value. Otherwise, the interworking function receiving the ATM cells would not be able to map the DLCI field in the FR-SSCS to the DLCI in the Q.922 headers correctly. This will be emphasized later in the configuration section.

Frame Relay Discard Eligibility and ATM Cell Loss Priority

The 1-bit CLP field in the ATM headers performs a function almost identical to the DE bit in the Frame Relay headers. The CLP field indicates the drop-priority of the cell if it encounters extreme congestion as it moves through the ATM network. The value of 0 indicates higher priority, and the value of 1 indicates lower priority. In other words, setting the CLP bit to 1 lowers the priority of the cells and increases the likelihood that the cell will be dropped when the ATM network experiences congestion on the physical lines or buffer queues.

NOTE

Take note that not all ATM carriers provide QoS based on the Frame Relay DE bit or ATM CLP bit for all types of traffic. This is largely dependent on the differentiated service categories supplied by the carriers.

Both FRF.5 and FRF.8.1 implementation agreements outline several options for supporting the Frame Relay DE bit to the ATM CLP bit mapping. Cisco's Frame Relay to ATM interworking implementation supports all of the options stipulated in FRF.5 and FRF.8.1 regarding DE to CLP bit mapping.

DE to CLP Bit Mapping in the Frame Relay to ATM Direction for FRF.5

Two modes are available to network providers when mapping the Frame Relay DE bit to the ATM CLP bit for all traffic in the Frame Relay to ATM direction. Both of these modes, and the specifications for the Frame Relay to ATM direction stated in FRF.5, are given in Table 8-1.

Table 8-1. DE to CLP Mapping for Frame Relay to ATM Direction for FRF.5

Mode 1

The Discard Eligibility field in the Q.922 frame shall be mapped unchanged into the DE field in the FR-SSCS PDU header and mapped to the ATM CLP bit of every ATM cell generated by the segmentation process of that frame.

Mode 2

The Discard Eligibility field in the Q.922 frame shall be mapped unchanged into the DE field in the FR-SSCS PDU header, and the ATM CLP bit of every ATM cell generated by the segmentation process of that frame shall be set to a constant value (0 or 1), as determined by the user at setup.

All Cisco platforms that support FRF.5 allow both modes of operation explained in Table 8-1 to be configured. Mode 1 is the default behavior when FRF.5 is configured on Cisco platforms. Alternatively, the user can set the CLP bit in the ATM cell header to a constant 0 or 1 as outlined in mode 2. Example 8-1 makes use of the network setup depicted in Figure 8-4 to demonstrate the default behavior described in mode 1 for FRF.5.

In Example 8-1, R1 sends out 10 packets (payload size 100 bytes) with the DE bits marked to the destination R4 over its Frame Relay PVC connected to R2. This can be easily done by configuring frame-relay de-list at R1 and applying it to the outgoing interface with the frame-relay de-group interface configuration command.

R2 is the router performing the FRF.5 network interworking function between Frame Relay and ATM. The show frame-relay pvc command performed at R2 indicates that 10 frames are received with the DE bit set. By the default behavior expressed in mode 1, R2 maps the DE bit to the ATM CLP bit for every ATM cell generated into the ATM network. The show atm vc interface {interface name} {vpi} {vci} command performed at the ATM LS1010 switch reveals that 30 ATM cells with the CLP bit set are received. Notice that the LS1010 switch has received 30 ATM cells for the 10 Frame Relay frames R1 has sent. This ratio is normal. Recall that the ATM AAL5 layer divides the payloads into equal blocks of 48 bytes. Because the average size of every packet sent is roughly 124 bytes (100 bytes payload plus 4 bytes Frame Relay headers plus 20 bytes IP header), this works out to a ratio of about three ATM cells generated to one Frame Relay frame received.

Example 8-1. DE Bit to CLP Bit Mapping in the Frame Relay to ATM Direction
R2#show frame-relay pvc 16

PVC Statistics for interface Serial1/3 (Frame Relay DCE)

DLCI = 16, DLCI USAGE = FRF.5, PVC STATUS = ACTIVE, INTERFACE = Serial1/3

  input pkts 11            output pkts 11           in bytes 1403
  out bytes 1378           dropped pkts 0           in pkts dropped 0
  out pkts dropped 0                out bytes dropped 0
  in FECN pkts 0           in BECN pkts 0           out FECN pkts 0
  out BECN pkts 0          in DE pkts 10            out DE pkts  0
  out bcast pkts 0         out bcast bytes 0
  switched pkts 11
  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 16:19:42, last time pvc status changed 16:17:11

LS1010#show atm vc interface atm4/0/0 1 32

Interface: ATM4/0/0, Type: t1suni
VPI = 1  VCI = 32
Status: UP
Time-since-last-status-change: 00:00:26
Connection-type: PVC
Cast-type: point-to-point
Packet-discard-option: disabled
Usage-Parameter-Control (UPC): pass
Wrr weight: 2
Number of OAM-configured connections: 0
OAM-configuration: disabled
OAM-states:  Not-applicable
Cross-connect-interface: ATM1/1/0, Type: oc3suni
Cross-connect-VPI = 1
Cross-connect-VCI = 32
Cross-connect-UPC: pass
Cross-connect OAM-configuration: disabled
Cross-connect OAM-state:  Not-applicable
Threshold Group: 5, Cells queued: 0
Rx cells: 38, Tx cells: 46
Tx Clp0:16,  Tx Clp1: 30
Rx Clp0:8,  Rx Clp1: 30
Rx Upc Violations:0, Rx cell drops:0
Rx Clp0 q full drops:0, Rx Clp1 qthresh drops:0
Rx connection-traffic-table-index: 1
Rx service-category: UBR (Unspecified Bit Rate)
Rx pcr-clp01: 7113539
Rx scr-clp01: none
Rx mcr-clp01: none
Rx      cdvt: 1024 (from default for interface)
Rx       mbs: none
Tx connection-traffic-table-index: 1
Tx service-category: UBR (Unspecified Bit Rate)
Tx pcr-clp01: 7113539
Tx scr-clp01: none
Tx mcr-clp01: none
Tx      cdvt: none
Tx       mbs: none

CLP to DE Bit Mapping in the ATM to Frame Relay Direction for FRF.5

Similar to the Frame Relay to ATM direction, two modes of operation are specified in FRF.5 for CLP bit to FR DE bit mapping for all traffic in the ATM to Frame Relay direction. Cisco's implementation of FRF.5 supports both.

Table 8-2. CLP to DE Bit Mapping for ATM to Frame Relay Direction for FRF.5

Mode 1

If one or more ATM cells belonging to a frame has its CLP field set to 1, or if the DE field of the FR-SSCS PDU is set to 1, the interworking function shall set the DE field of the Q.922 frame.

Mode 2

No mapping is performed from the ATM layer to Q.922 layer. The FR-SSCS PDU DE field is copied unchanged to the Q.922 core frame DE field, independent of the CLP indications received at the ATM layer.

For CLP to DE bit mapping of all traffic traveling in the ATM to Frame Relay direction, the behavior described in mode 1 is the default.

Example 8-2 shows that mode 1 is the default action when ATM cells are reassembled back to Frame Relay frames by the destination FRF.5 router, which is R3 in this setup. The show frame-relay pvc command performed at R3 indicates that 10 frames with the DE bit marked are sent to R4. This is because all the ATM cells received by R3 have the CLP bit set to 1. In fact, R3 sets the DE bit in the Frame Relay headers as long as it sees the CLP bit set in only one ATM cell belonging to the frame.

Example 8-2. CLP Bit to DE Bit Mapping in the ATM to Frame Relay Direction
R3#show frame-relay pvc 26

PVC Statistics for interface Serial1 (Frame Relay DCE)

DLCI = 26, DLCI USAGE = FRF.5, PVC STATUS = ACTIVE, INTERFACE = Serial1

  input pkts 26            output pkts 26           in bytes 6448
  out bytes 6848           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 10
  out bcast pkts 0          out bcast bytes 0            Num Pkts Switched 26
pvc create time 16:22:18, last time pvc status changed 16:22:03

The configuration commands for enabling the Frame Relay DE bit to ATM CLP bit mapping are shown in the "Configuring FRF.5 Network Interworking" section later on in this chapter.

Congestion Indication Support in FRF.5

Both Frame Relay and ATM have congestion indication mechanisms designed as part of the protocols. For Frame Relay, the BECN and FECN bits in the headers are the means by which Frame Relay notifies the network about congested conditions. On the other hand, ATM uses the Explicit Forward Congestion Indication (EFCI) in the cell headers to communicate the congested condition in the forward direction. The function of EFCI is identical to FECN. However, ATM does not have anything that mirrors the role of BECN in Frame Relay.

In the Frame Relay to ATM direction, FRF.5 itself does not support the mapping of FECN to EFCI, nor does Cisco's implementation of FRF.5. However, the mapping of EFCI bit in the ATM cell to FECN bit in the frame headers is supported.

Cisco's implementation of network interworking supports the majority of the specifications defined in FRF.5. The remaining sections and subsections of FRF.5 are supported as follows:

  • 4.5.2.1 BECN Field in FR-SSCS PDU The BECN field in FR-SSCS PDU is copied unchanged into the BECN field of the Q.922 frame.

  • 4.5.2.2 Frame Relay to B-ISDN Direction Backward congestion indication is not supported.

  • 5.1 Traffic Management There is no direct mapping between Frame Relay and ATM traffic parameters; these parameters are configured independently.

  • 5.2 PVC Management PVC management is not supported.

  • 5.3 Description of Upper Layer User Protocol Encapsulation Methods This section applies only to terminal equipment and is not supported. However, this is used by FRF.8.1 operating in the translation mode.

  • 5.4.1 Operations for the Common Part of the AAL Type 5 The error counters mentioned in this section are reset at startup and are counted until they are reset.

The complete Frame Relay Forum Implementation Agreement Document Number FRF.5 can be downloaded from the Frame Relay Forum's public web site at http://www.mplsforum.org/frame/Approved/FRF.5/frf.5.pdf.


Frame Relay Forum Implementation Agreement Document Number FRF.8.1

A couple of years after the Frame Relay Implementation Agreement Document Number FRF.5 was introduced, the Frame Relay Forum and ATM Forum outlined the Frame Relay to ATM Service Interworking specifications. These are defined in the Frame Relay Forum Implementation Agreement Document Number FRF.8.1. The complete FRF.8.1 documentation can be downloaded from the Frame Relay Forum's public web site at http://www.mplsforum.org/frame/Approved/FRF.8/FRF.8.1.pdf.

The new FRF.8.1 implementation agreement allows a Frame Relay service user to interwork with an ATM service user without requiring either user to perform any interworking functions.

The traffic is translated by an interworking function acting as a protocol translator between Frame Relay and ATM equipment. In contrast to FRF.5, FRF.8.1 does not require the ATM service user to perform Frame Relay-specific functions in the FR-SSCS within the AAL5. With FRF.8.1, the Frame Relay service user has no knowledge that the distant device is an ATM service user. Figure 8-9 gives you an idea where the interworking function is most commonly located when FRF.8.1 is used. Compare Figure 8-9 with FRF.5's diagram in Figure 8-2. Observe that when FRF.5 is used, two interworking functions are required to allow two Frame Relay service users to communicate over an ATM network. In FRF.8.1, one interworking function translates between the Frame Relay and ATM service users.

Figure 8-9. Interworking Function in FRF.8.1 Service Interworking

FRF.8.1 does not preserve the Frame Relay information from the Q.922 headers inside the FR-SSCS field of the ATM cell because the peer device is an ATM end user. The interworking function performs service interworking for the connected ATM and Frame Relay service users.

Compared with the functionalities offered by FRF.5, FRF.8.1 gives greater flexibility to the users by allowing a Frame Relay service user to communicate directly with an ATM service user. Also note that the FRF.8.1 specifications only support one-to-one mapping of Frame Relay service user to the ATM service user. Many-to-one mapping, as in the case of FRF.5, is not supported.

Some commonalities between FRF.5 and FRF.8.1 exist. Both FRF.5 and FRF.8.1 allow a Frame Relay network to connect to a disparate ATM network via an interworking function. FRF.5 and FRF.8.1 both provide congestion indication (DE to CLP mapping, FECN to EFCI mapping support), traffic management, and PVC management interworking.

Figure 8-10 illustrates the protocol stack when FRF.8.1 service interworking is deployed between Frame Relay and ATM service users.

Figure 8-10. Service Interworking Between Frame Relay and ATM Services

The first thing to notice in Figure 8-10 is that a Null SSCS field has now replaced the FR-SSCS field in the ATM protocol stack. In the Frame Relay to ATM service interworking function, this Null SSCS provides an interface to Q.922 on the Frame Relay side and an interface to AAL5 CPCS on the ATM side. FRF.8.1 supports two modes of operation, translation and transparent, which are selected at configuration time. Cisco supports both modes of operation.

Using either mode of operation, when data is transported from Frame Relay to ATM direction, the Frame Relay payload is simply copied into the CPCS-PDU payload. The Frame Relay frame's flags, inserted zero bits, and the CRC-16 checksum fields are all removed. The Q.922 Frame Relay headers are removed, and the relevant fields are mapped into the ATM cell headers. AAL5 adds frame delineation to indicate the frame boundaries and computes a 32-bit CRC checksum for error detection. Conversely, in the opposite ATM to Frame Relay direction, the service interworking function uses the message delineation provided by AAL5 to identify frame boundaries to add the zero bit insertion, flags, and 16-bit CRC checksum to construct the Frame Relay frame.

If translation mode is used, the service interworking function inspects the NLPID field of the RFC 1490 encapsulated payload and translates it into the corresponding fields of the RFC 2684 encapsulated payload.

If transparent mode is used, this step is not performed by the service interworking function.

FRF.8.1 Translation Mode

With FRF.8.1 operating in translation mode, the service interworking function translates Frame Relay PDU into ATM AAL5 CPCS-PDU without preserving any Frame Relay-specific information inside the FR-SSCS field, unlike in the FRF.5 case. For this reason, the Null SSCS field replaces the FR-SSCS field in the AAL5 CPSC headers when FRF.8.1 translation mode is used. Using FRF.8.1, the translation interworking function allows bidirectional protocol translation between Frame Relay and ATM. The translation mode maps between Frame Relay and ATM encapsulation, and none of the Frame Relay Q.922 headers information is preserved during the translation process. FRF.8.1 translation mode should be used when the encapsulation types of the end terminal equipment are not compatible with each other and require the FRF.8.1 translation interworking function to translate between them.

Translation mode supports interworking of routed and bridged protocols. When routed protocols are translated, FRF.8.1 translates between RFC 1490 for the Frame Relay and RFC 2684 for ATM. The service interworking function translates the Frame Relay NLPID values to ATM logical link control (LLC) or Subnetwork Access Protocol (SNAP), conforming to RFC 2684. RFC 2684 outlines the specifications for multiprotocol encapsulations over ATM AAL5 and is in many ways similar to RFC 1490 for Frame Relay (RFC 2684 supercedes RFC 1483), which was discussed in Chapter 2, "Cisco Frame Relay Devices and Network Implementation." For more information on RFC 2684 and RFC 1483, please visit http://www.ietf.org/rfc.

Referring to the network diagram in Figure 8-10, the debug frame-relay packets and debug atm packets commands are enabled at R1 and R3, respectively, to verify the translation that takes place at R2. In addition, the debug ip packet command is turned on at router R3 to validate that the network layer IP packets are sent from the source Frame Relay interface serial0/0.16 on router R1 with IP address 172.16.1.1/24 and received by the destination ATM interface ATM0.1 with IP address 172.16.1.2/24. Without router R2 performing the ATM to Frame Relay translation between the two different protocols, the end-to-end ping would not be successful. The NLPID (type IP, 0x3CC) in the encapsulated payload of the Frame Relay frame is translated to ATM cells with SNAP encapsulation of type IP (0800) by R2.

Example 8-3. FRF.8.1 Translation Mode Between Frame Relay and ATM When R1 Sends Five IP Packets to R3
[View full width]
Show running configuration at R1:
<output omitted>

interface Serial0/0
 no ip address
 encapsulation frame-relay IETF
!
interface Serial0/0.16 point-to-point
 ip address 172.16.1.1 255.255.255.0
 frame-relay interface-dlci 16

Show logging at R1 to display the output of debug frame-relay packet:

R1#debug frame-relay packet
R1#show logging
<output omitted>
!
*Aug 16 01:50:59.557: Serial0/0.16(o): dlci 16(0x403), NLPID 0x3CC(IP), datagramsize 104
    NLPID 0x3CC(IP) indicates an IP packet is transmitted on the Frame Relay DLCI 16 at R1.
*Aug 16 01:50:59.617: Serial0/0(i): dlci 16(0x401), NLPID 0x3CC(IP), datagramsize 104
*Aug 16 01:50:59.617: Serial0/0.16(o): dlci 16(0x403), NLPID 0x3CC(IP), datagramsize 104
*Aug 16 01:50:59.677: Serial0/0(i): dlci 16(0x401), NLPID 0x3CC(IP), datagramsize 104
*Aug 16 01:50:59.677: Serial0/0.16(o): dlci 16(0x403), NLPID 0x3CC(IP), datagramsize 104
*Aug 16 01:50:59.737: Serial0/0(i): dlci 16(0x401), NLPID 0x3CC(IP), datagramsize 104
*Aug 16 01:50:59.737: Serial0/0.16(o): dlci 16(0x403), NLPID 0x3CC(IP), datagramsize 104
*Aug 16 01:50:59.797: Serial0/0(i): dlci 16(0x401), NLPID 0x3CC(IP), datagramsize 104
*Aug 16 01:50:59.797: Serial0/0.16(o): dlci 16(0x403), NLPID 0x3CC(IP), datagramsize 104
*Aug 16 01:50:59.857: Serial0/0(i): dlci 16(0x401), NLPID 0x3CC(IP), datagramsize 104

Show running configuration at R3:
<output omitted>
!
interface ATM0
 no ip address
 no atm ilmi-keepalive
!
interface ATM0.1 multipoint
 ip address 172.16.1.2 255.255.255.0
 pvc 1/32
  protocol ip 172.16.1.1 broadcast
  encapsulation aal5snap

Show logging at R3 to display the output of debug atm packet:

R3#debug atm packet
R3#debug ip packet
R3#show logging
<output omitted>
!
1d00h: ATM0.1(I):
VCD:0x7 VPI:0x1 VCI:0x20 Type:0x0 SAP:AAAA CTL:03 OUI:000000 TYPE:0800 Length:0x70
   TYPE:0800 indicates an IP packet is received on PVC 1/32 at R3.
1d00h: 4500 0064 0201 0000 FE01 6074 AC10 0101 AC10 0102 0800 E413 25B2 1810 0000
1d00h: 0000 2EE8 2D8C ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD
1d00h: ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD
1d00h: ABCD ABCD ABCD ABCD ABCD
1d00h:
1d00h: IP: s=172.16.1.1 (ATM0.1), d=172.16.1.2 (ATM0.1), len 100, rcvd 3  this
   indicates an IP packet is received by the ATM interface from the source 172.16.1.1/24
  (Frame Relay router R1)
1d00h: IP: s=172.16.1.2 (local), d=172.16.1.1 (ATM0.1), len 100, sending
1d00h: ATM0.1(O):
VCD:0x7 VPI:0x1 VCI:0x20 DM:0x100 SAP:AAAA CTL:03 OUI:000000 TYPE:0800 Length:0x70
1d00h: 4500 0064 0201 0000 FF01 5F74 AC10 0102 AC10 0101 0000 EC13 25B2 1810 0000
1d00h: 0000 2EE8 2D8C ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD
1d00h: ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD
1d00h: ABCD ABCD ABCD ABCD ABCD
1d00h:
1d00h: ATM0.1(I):
VCD:0x7 VPI:0x1 VCI:0x20 Type:0x0 SAP:AAAA CTL:03 OUI:000000 TYPE:0800 Length:0x70
1d00h: 4500 0064 0202 0000 FE01 6073 AC10 0101 AC10 0102 0800 E3D6 25B3 1810 0000
1d00h: 0000 2EE8 2DC8 ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD
1d00h: ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD
1d00h: ABCD ABCD ABCD ABCD ABCD
1d00h:
1d00h: IP: s=172.16.1.1 (ATM0.1), d=172.16.1.2 (ATM0.1), len 100, rcvd 3
1d00h: IP: s=172.16.1.2 (local), d=172.16.1.1 (ATM0.1), len 100, sending
1d00h: ATM0.1(O):
VCD:0x7 VPI:0x1 VCI:0x20 DM:0x100 SAP:AAAA CTL:03 OUI:000000 TYPE:0800 Length:0x70
1d00h: 4500 0064 0203 0000 FF01 5F72 AC10 0102 AC10 0101 0000 EB99 25B4 1810 0000
1d00h: 0000 2EE8 2E04 ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD
1d00h: ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD
1d00h: ABCD ABCD ABCD ABCD ABCD
1d00h:
1d00h: ATM0.1(I):
VCD:0x7 VPI:0x1 VCI:0x20 Type:0x0 SAP:AAAA CTL:03 OUI:000000 TYPE:0800 Length:0x70
1d00h: 4500 0064 0204 0000 FE01 6071 AC10 0101 AC10 0102 0800 E35C 25B5 1810 0000
1d00h: 0000 2EE8 2E40 ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD
1d00h: ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD
1d00h: ABCD ABCD ABCD ABCD ABCD
1d00h:
1d00h: IP: s=172.16.1.1 (ATM0.1), d=172.16.1.2 (ATM0.1), len 100, rcvd 3
1d00h: IP: s=172.16.1.2 (local), d=172.16.1.1 (ATM0.1), len 100, sending
1d00h: ATM0.1(O):
VCD:0x7 VPI:0x1 VCI:0x20 DM:0x100 SAP:AAAA CTL:03 OUI:000000 TYPE:0800 Length:0x70
1d00h: 4500 0064 0204 0000 FF01 5F71 AC10 0102 AC10 0101 0000 EB5C 25B5 1810 0000
1d00h: 0000 2EE8 2E40 ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD
1d00h: ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD
1d00h: ABCD ABCD ABCD ABCD ABCD
1d00h:
1d00h: ATM0.1(I):
VCD:0x7 VPI:0x1 VCI:0x20 Type:0x0 SAP:AAAA CTL:03 OUI:000000 TYPE:0800 Length:0x70
1d00h: 4500 0064 0205 0000 FE01 6070 AC10 0101 AC10 0102 0800 E31F 25B6 1810 0000
1d00h: 0000 2EE8 2E7C ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD
1d00h: ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD
1d00h: ABCD ABCD ABCD ABCD ABCD
1d00h:
1d00h: IP: s=172.16.1.1 (ATM0.1), d=172.16.1.2 (ATM0.1), len 100, rcvd 3
1d00h: IP: s=172.16.1.2 (local), d=172.16.1.1 (ATM0.1), len 100, sending
1d00h: ATM0.1(O):
VCD:0x7 VPI:0x1 VCI:0x20 DM:0x100 SAP:AAAA CTL:03 OUI:000000 TYPE:0800 Length:0x70
1d00h: 4500 0064 0205 0000 FF01 5F70 AC10 0102 AC10 0101 0000 EB1F 25B6 1810 0000
1d00h: 0000 2EE8 2E7C ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD
1d00h: ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD
1d00h: ABCD ABCD ABCD ABCD ABCD
1d00h:
1d00h: ATM0.1(I):
VCD:0x7 VPI:0x1 VCI:0x20 Type:0x0 SAP:AAAA CTL:03 OUI:000000 TYPE:0800 Length:0x70
1d00h: 4500 0064 0205 0000 FE01 6070 AC10 0101 AC10 0102 0800 E31F 25B6 1810 0000
1d00h: 0000 2EE8 2E7C ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD
1d00h: ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD
1d00h: ABCD ABCD ABCD ABCD ABCD
1d00h:
1d00h: IP: s=172.16.1.1 (ATM0.1), d=172.16.1.2 (ATM0.1), len 100, rcvd 3
1d00h: IP: s=172.16.1.2 (local), d=172.16.1.1 (ATM0.1), len 100, sending
1d00h: ATM0.1(O):
VCD:0x7 VPI:0x1 VCI:0x20 DM:0x100 SAP:AAAA CTL:03 OUI:000000 TYPE:0800 Length:0x70
1d00h: 4500 0064 0205 0000 FF01 5F70 AC10 0102 AC10 0101 0000 EB1F 25B6 1810 0000
1d00h: 0000 2EE8 2E7C ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD
1d00h: ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD
1d00h: ABCD ABCD ABCD ABCD ABCD

FRF.8.1 Transparent Mode

FRF.8.1 operating in transparent mode does not perform any protocol translation, but it forwards the encapsulations unaltered. The FRF.8.1 transparent mode is applicable when the encapsulation types used by the end terminal equipment do not conform to the standards specified by FRF.8.1 translation mode but are fully compatible with each other. In addition, FRF.8.1 transparent mode does not perform mapping, fragmentation, or reassembly.

This section demonstrates the FRF.8.1 service transparent interworking using the same setup as in Example 8-3. At router R2, translation mode is disabled with the no service translation command. The no service translation command turns off the default translation mode and allows transparent mode to be used. In Example 8-4, the debug atm packet and debug atm error commands are enabled at R3. R3 is now unable to interpret the ATM cells received from R2, because R3 is still using the AAL5 SNAP encapsulation on VPI/VCI 1/32. It looks for the destination service-assess point (DSAP) and source service-assess point (SSAP) values of the SNAP header. In other words, the encapsulation types used by the two end terminal equipment (routers R1 and R3) are incompatible with each other.

Example 8-4. Common Problems Encountered When End Service Users Are Using Different Encapsulation Methods FRF 8.1 Transparent Mode
[View full width]
R3#debug atm packet
R3#show logging
!
<output omitted>
!
1d22h: ATM0.1(I):
VCD:0x7 VPI:0x1 VCI:0x20 Type:0x0 SAP:03CC CTL:45  Length:0x6A
1d22h: 0000 6402 0F00 00FF 015F 66AC 1001 01AC 1001 0208 008A 671A 960B 1400 0000
1d22h: 0033 C09A 78AB CDAB CDAB CDAB CDAB CDAB CDAB CDAB CDAB CDAB CDAB CDAB CDAB
1d22h: CDAB CDAB CDAB CDAB CDAB CDAB CDAB CDAB CDAB CDAB CDAB CDAB CDAB CDAB CDAB
1d22h: CDAB CDAB CDAB CDAB CD00
1d22h:
1d22h: ATM(ATM0.1): VC(7) Bad SAP received 03CC  this indicates R3 is unable to
   comprehend the encapsulation types of the frames it receives from R1.

The encapsulation type on Router R3 has been changed to ATM AAL5 NPLID encapsulation so that it is using the same encapsulation type as R1. After the change, R3 can communicate successfully with R1. Example 8-5 shows the output of the debug atm packet command at router R3, which confirms that R3 is no longer reporting bad encapsulation type received.

Example 8-5. Successful Communication after the Matching the Encapsulation Method R3 when Using FRF 8.1 Transparent Mode
[View full width]
R3#debug atm packet
R3#show logging
!
<output omitted>
!
1d22h: ATM0.1(I):
VCD:0x7 VPI:0x1 VCI:0x20 Type:0x2 NLPID:0x03CC Length:0x6A
1d22h: 4500 0064 0214 0000 FE01 6061 AC10 0101 AC10 0102 0800 8093 050A 0F05 0000
1d22h: 0000 33C3 B5E4 ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD
1d22h: ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD
1d22h: ABCD ABCD ABCD ABCD ABCD
1d22h:
1d22h: ATM0.1(O):
VCD:0x7 VPI:0x1 VCI:0x20 DM:0x100 NLPID:0x03CC Length:0x6A
1d22h: 4500 0064 0214 0000 FF01 5F61 AC10 0102 AC10 0101 0000 8893 050A 0F05 0000
1d22h: 0000 33C3 B5E4 ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD
1d22h: ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD
1d22h: ABCD ABCD ABCD ABCD ABCD  there is no more bad SAP message indicating
   incompatible encapsulation types on R3.
1d22h:

DE to CLP Bit Mapping in the Frame Relay to ATM Direction for FRF.8.1

Similar to FRF.5, two modes of operations are available to network providers when mapping DE to CLP bits for all traffic in the Frame Relay to ATM direction for FRF.8.1. Cisco supports both modes as specified for the Frame Relay to ATM direction, documented in section 4.2.1 of FRF.8.1. Section 4.2.1 of FRF.8.1 is summarized in Table 8-3.

Table 8-3. DE to CLP Mapping for Frame Relay to ATM Direction for FRF.8.1

Mode 1

The Discard Eligibility field in the Q.922 frame shall be mapped to the ATM CLP bit of every ATM cell generated by the segmentation process of the AAL5 PDU containing information of that frame.

Mode 2

The ATM CLP bit of every ATM cell generated by the segmentation process of the AAL5 PDU containing information of that frame shall be set to a constant value (0 or 1), as determined by the user at setup.

The DE to CLP bit mapping action for all traffic in the Frame Relay to ATM direction described in mode 1 of Table 8-3 is the default behavior for all Cisco routers running FRF.8.1. Based on the network setup illustrated in Figure 8-10, Example 8-3 shows the default mapping action on router R2, the FRF.8.1 router performing service translation between R1 and the ATM network. The running configurations for enabling FRF.8.1 on R2 are shown in Example 8-6. The show frame-relay pvc command performed at the end Frame Relay router R1 indicates 10 DE bit marked frames are sent out on the Frame Relay PVC to R2, the FRF.8.1 performing interworking translation. At the ATM LS1010 switch, 30 ATM cells with the CLP bit set are received from R2.

Example 8-6. DE to CLP Bit Mapping in the Frame Relay to ATM Direction for FRF.8.1
! R2:
connect frf.8 Serial1/3 16 ATM3/0 1/32 service-interworking
!

R1#show frame-relay pvc 16

PVC Statistics for interface Serial0/0 (Frame Relay DTE)

DLCI = 16, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/0.16

  input pkts 10            output pkts 11           in bytes 1040
  out bytes 1398           dropped pkts 0           in pkts dropped 0
  out pkts dropped 0                out bytes dropped 0
  in FECN pkts 0           in BECN pkts 0           out FECN pkts 0
  out BECN pkts 0          in DE pkts 0             out DE pkts 10
  out bcast pkts 1         out bcast bytes 358
  5 minute input rate 0 bits/sec, 1 packets/sec
  5 minute output rate 1000 bits/sec, 1 packets/sec
pvc create time 20:56:07, last time pvc status changed 20:56:07

LS1010#show atm vc inter atm4/0/0 1 32

Interface: ATM4/0/0, Type: t1suni
VPI = 1  VCI = 32
Status: UP
Time-since-last-status-change: 04:40:13
Connection-type: PVC
Cast-type: point-to-point
Packet-discard-option: disabled
Usage-Parameter-Control (UPC): pass
Wrr weight: 2
Number of OAM-configured connections: 0
OAM-configuration: disabled
OAM-states:  Not-applicable
Cross-connect-interface: ATM1/1/0, Type: oc3suni
Cross-connect-VPI = 1
Cross-connect-VCI = 32
Cross-connect-UPC: pass
Cross-connect OAM-configuration: disabled
Cross-connect OAM-state:  Not-applicable
Threshold Group: 5, Cells queued: 0
Rx cells: 4381, Tx cells: 4517
Tx Clp0:4352,  Tx Clp1: 165
Rx Clp0:4351,  Rx Clp1: 30
Rx Upc Violations:0, Rx cell drops:0
Rx Clp0 q full drops:0, Rx Clp1 qthresh drops:0
Rx connection-traffic-table-index: 1
Rx service-category: UBR (Unspecified Bit Rate)
Rx pcr-clp01: 7113539
Rx scr-clp01: none
Rx mcr-clp01: none
Rx      cdvt: 1024 (from default for interface)
Rx       mbs: none
Tx connection-traffic-table-index: 1
Tx service-category: UBR (Unspecified Bit Rate)
Tx pcr-clp01: 7113539
Tx scr-clp01: none
Tx mcr-clp01: none
Tx      cdvt: none
Tx       mbs: none

This simple test shows that by default, R2 maps the DE bit in the Q.922 headers to the CLP field for every ATM cell that it generates.

CLP to DE Bit Mapping in the ATM to Frame Relay Direction for FRF.8.1

Two modes of operation are specified in FRF.8.1 for CLP bit to FR DE bit mapping for all traffic in the ATM to Frame Relay direction. Cisco's implementation of FRF.8.1 supports both options.

Mode 1 described in Table 8-4 is the default behavior on all Cisco routers supporting FRF.8.1 for all traffic in the ATM to Frame Relay direction. In Example 8-7, based on Figure 8-10, R3 sends out some CLP bit-marked traffic into the ATM network with R1 as the destination. This example shows that when the CLP bit-marked ATM traffic destined for R1 is received by R2, R2 applies the default behavior and maps the CLP bit in the ATM cell headers to the DE bit in the Frame Relay headers. Eventually, R1 receives Frame Relay frames with the DE bit marked.

Example 8-7. CLP to DE Bit Mapping in the ATM to Frame Relay Direction for FRF.8.1
LS1010#show atm vc inter atm1/1/0 1 32

Interface: ATM1/1/0, Type: oc3suni
VPI = 1  VCI = 32
Status: UP
Time-since-last-status-change: 05:10:05
Connection-type: PVC
Cast-type: point-to-point
Packet-discard-option: disabled
Usage-Parameter-Control (UPC): pass
Wrr weight: 2
Number of OAM-configured connections: 0
OAM-configuration: disabled
OAM-states:  Not-applicable
Cross-connect-interface: ATM4/0/0, Type: t1suni
Cross-connect-VPI = 1
Cross-connect-VCI = 32
Cross-connect-UPC: pass
Cross-connect OAM-configuration: disabled
Cross-connect OAM-state:  Not-applicable
Threshold Group: 5, Cells queued: 0
Rx cells: 4802, Tx cells: 4426
Tx Clp0:4396,  Tx Clp1: 30
Rx Clp0:4592,  Rx Clp1: 210
Rx Upc Violations:0, Rx cell drops:0
Rx Clp0 q full drops:0, Rx Clp1 qthresh drops:0
Rx connection-traffic-table-index: 1
Rx service-category: UBR (Unspecified Bit Rate)
Rx pcr-clp01: 7113539
Rx scr-clp01: none
Rx mcr-clp01: none
Rx      cdvt: 1024 (from default for interface)
Rx       mbs: none
Tx connection-traffic-table-index: 1
Tx service-category: UBR (Unspecified Bit Rate)
Tx pcr-clp01: 7113539
Tx scr-clp01: none
Tx mcr-clp01: none
Tx      cdvt: none
Tx       mbs: none

R1#show frame-relay pvc 16

PVC Statistics for interface Serial1/3 (Frame Relay DCE)

DLCI = 16, DLCI USAGE = FRF.8, PVC STATUS = ACTIVE, INTERFACE = Serial0/0.16

  input pkts 112           output pkts 60           in bytes 24992
  out bytes 6240           dropped pkts 0           in pkts dropped 0
  out pkts dropped 0                out bytes dropped 0
  in FECN pkts 0           in BECN pkts 0           out FECN pkts 0
  out BECN pkts 0          in DE pkts 60            out DE pkts 0
  out bcast pkts 0         out bcast bytes 0
  switched pkts 112
  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 00:52:11, last time pvc status changed 00:52:09

Table 8-4. CLP to DE Bit Mapping for ATM to Frame Relay Direction for FRF.8.1

Mode 1

If one or more ATM cells belonging to a frame has its CLP field set to 1, the interworking function shall set the DE field of the Q.922 frame.

Mode 2

The DE field of the Q.922 frame is set to a constant value of 1 or 0, configured by the user at setup.


Congestion Indication Support in FRF.8.1

For FRF.8.1, Cisco supports the bidirectional mapping of FECN and EFCI bits outlined in Table 8-5.

Table 8-5. EFCI and FECN Mapping for FRF.8.1

Frame Relay to ATM Direction

Default

The EFCI field in the ATM cell header is set to 1 if the FECN field in the Frame Relay headers is set.

User configurable

The EFCI field in the ATM cell header is set to a constant 0.

ATM to Frame Relay Direction

Default

The FECN field in the Frame Relay header is set to 1 if the EFCI field in the last cell of the segmented frame is set.

User configurable

The EFCI field in the ATM cell header is set to a constant 0.

The remaining sections and subsections of FRF.8.1 are supported as follows on Cisco platforms:

  • 5.1 Traffic Management There is no direct mapping between the Frame Relay and ATM traffic parameters; these parameters are configured independently.

  • 5.2 Frame Relay PVC Management Procedures The procedures for the asynchronous status message defined in Q.933 Annex-A are not supported.

  • 5.3.1.4 Fragmentation and Reassembly Fragmentation and reassembly are not supported.

  • 5.4 Address Resolution The IP and IPX protocols are supported.

  • 6.0 Operations for the Common Part of the AAL Type 5 The error counters mentioned in this section are reset at startup and are counted until they are reset.


Supported Cisco Platforms for Frame Relay to ATM Interworking

This section presents an overview of the Cisco router platforms that support the Frame Relay to ATM Interworking feature. During the early development stage, not all Cisco router platforms offer the support for the Frame Relay to ATM interworking function. The early supported router platforms include the Cisco MC3810, the Cisco 2600 series, the Cisco 3600 series, and the Cisco 7200 series.

For Cisco IOS software support, the Frame Relay to ATM Interworking feature is available in Cisco IOS Software Release 12.1(2)T or later. With the correct Cisco IOS software release, the Frame Relay to ATM Interworking feature is supported on the following list of router platforms discussed in this section.

Cisco MC3810

The Cisco MC3810 platform originated from Cisco's acquisition of Ardent Communication Corporation in 1997. The Cisco MC3810 (see Figure 8-11) is a compact, low-cost, multiservice access concentrator. The MC3810 provides integration of video, voice, and data onto public or private Frame Relay, ATM, leased-line, or IP networks. The MC3810 supports the Frame Relay to ATM Internetworking (FRF.5 and FRF.8.1) feature with its T1/E1 ATM interface. It permits remote sites using Frame Relay access to work directly with ATM at larger sites.

Figure 8-11. Cisco MC3810

Cisco's early development of the Frame Relay to ATM Interworking feature was based largely on the MC3810 platform. However, as of the date that this book was written, Cisco has officially announced the end of sales of the MC3810 series, and this platform and its components will no longer be available. Nonetheless, the configuration tasks in the Cisco IOS software for the Frame Relay to ATM Interworking feature are independent across all supported platforms and the MC3810 platform is used in the discussion in the configuration commands section.

Cisco 2600 Series Routers

The Cisco 2600 series (see Figure 8-12) is a family of modular multiservice access branch office routers suitable for a wide range of business requirements. The Cisco 2600 series router supports the Frame Relay to ATM Interworking feature with its ATM OC-3 and Inverse Multiplexing over ATM (IMA) network modules.

Figure 8-12. Cisco 2600 Series Routers

Cisco 3600 Series Routers

The Cisco 3600 series (see Figure 8-13) is a family of modular multiservice access platforms for medium and large-sized offices and smaller Internet service providers. It supports more than 70 modular interface options to meet data, voice, video, dial access, VPN, and multiprotocol data routing requirements. The Cisco 3600 series router supports Frame Relay to ATM Interworking with the ATM OC-3 and inverse multiplexing over ATM (IMA) network modules. Both the Cisco 2600 and Cisco 3600 series routers can share the same modular interfaces.

Figure 8-13. Cisco 3600 Series Routers

Cisco 7200 Series Routers

The Cisco 7200 Series router (see Figure 8-14) is a scalable and modular high performance router that can address a wide range of service requirements. The Cisco 7200 series router supports the Frame Relay to ATM Interworking feature on all ATM interface types.

Figure 8-14. Cisco 7200 Series Routers

Previous Page
Next Page


Configuring FRF.5 Network Interworking

This section discusses the configuration tasks required to enable Frame Relay network interworking (FRF.5) on the Cisco router. The network, consisting of four routers and an ATM LS1010 switch, is depicted in Figure 8-15 and is used to illustrate the configuration examples in this section. Note that R2 and R3 belong to the supported Cisco platforms required for Frame Relay to ATM Interworking.

Figure 8-15. Simple Network to Illustrate the Configuration Examples for FRF.5

R2 and R3 in Figure 8-15 are the routers performing the FRF.5 network interworking function between the Frame Relay and the ATM networks. To enable FRF.5 on R2 or R3 using one-to-one multiplexing, follow the configuration steps listed below:

Step 1. | Enter the interface configuration mode of the serial interface connected to the Frame Relay network with the interface serial number command and enable Frame Relay encapsulation with the encapsulation frame-relay command.
Step 2. | If the incoming Frame Relay PVC is a switched VC, identify it with the frame-relay interface-dlci dlci switched interface configuration command. If the incoming Frame Relay PVC is a terminated VC, this step is not required.
Step 3. | Configure the ATM interface connected to the ATM network and enter the interface configuration mode with the interface atm number command.
Step 4. | Create the ATM PVC with the VPI/VCI pair using pvc [pvc-name] vpi/vci interface configuration command. The ATM PVC can be identified using a pvc-name but it is optional. The VPI/VCI value is usually assigned by the provider and configured on the ATM switch.
Step 5. | Configure the ATM adaptation layer and encapsulation type for the ATM PVC with the encapsulation aal5mux frame-relay command. The aal5mux encapsulation has slightly less overhead compared with the default aal5snap encapsulation. The aal5mux encapsulation is usually used to dedicate the specified PVC to only a single protocol.
Step 6. | Create a connection to connect the Frame Relay DLCI to the ATM PVC using the connect connection-name FR-interface FR-DLCI ATM-interface ATM-PVC network-interworking global configuration command. The network-interworking option is specified to indicate that FRF.5 is to be used.
Step 7. | (optional) Under the FRF.5 mode, set the ATM CLP bit for traffic in the Frame Relay to ATM direction using the clp-bit {0 | 1 | map-de} command. As you saw earlier, the default configuration is clp-bit map-de. (Note that this command is presently available on Cisco MC3810, 2600, and 3600 series routers only.)
Step 8. | (optional) Under the FRF.5 mode, set the DE bit for traffic in the ATM to Frame Relay direction using the de-bit map-clp command. This is the default. Use the no form of the command to disable CLP bit to DE bit mapping. (Note that this command is presently available on Cisco MC3810, 2600, and 3600 series routers only.)
Step 9. | To enable the FRF.5 network interworking connection, perform no shutdown. Use the shutdown command to disconnect the FRF.5 network interworking connection.

Example 8-8 below shows the complete FRF.5 configuration on routers R2 and R3.

Example 8-8. Configuration on R2 and R3 (One-to-One Connection)
! R2:
<output omitted>
!
interface Serial1/3
 no ip address
 encapsulation frame-relay
 frame-relay interface-dlci 16 switched
 !
interface ATM3/0
 no ip address
 no ip route-cache
 no atm ilmi-keepalive
 pvc 1/32
encapsulation aal5mux frame-relay
!
connect frf5 Serial1/3 16 ATM3/0 1/32 network-interworking
clp-bit map-de

! R3
<output omitted>
!
interface Serial1
 no ip address
 encapsulation frame-relay
 frame-relay interface-dlci 26 switched
!
interface ATM0
 no ip address
 no atm ilmi-keepalive
 pvc 1/32
encapsulation aal5mux frame-relay
!
connect frf5 Serial1 26 ATM0 1/32 network-interworking
de-bit map-clp

This section looks at how many-to-one multiplexing is configured for FRF.5 network interworking. In Figure 8-15, two Frame Relay PVCs are provisioned on each service user at each of the Frame Relay networks. A vc-group command has to be created to assign multiple Frame Relay DLCIs to one ATM VC. The configuration tasks required for enabling many-to-one multiplexing are almost the same as the one-to-one case presented previously. As such, only the additional configuration commands necessary for configuring many-to-one multiplexing are explained.

Step 1. | Configure a VC group to assign multiple Frame Relay DLCIs to a single ATM VC using the vc-group group-name global configuration command.
Step 2. | In the vc-group configuration mode, specify the Frame Relay DLCIs and map them to the Frame Relay SSCS DLCIs using the FR-interface FR-DLCI FR-SSCS-DLCI vc-group configuration command. Note that both the FR-DLCI and FR-SSCS-DLCI are required.
Step 3. | Create a connection to connect the VC group to the ATM PVC using connect connection-name vc-group group-name ATM-interface ATM-PVC network-interworking global configuration command.


Verifying FRF.5 Configuration

Two show commands applicable to the Frame Relay to ATM interworking feature can be used to verify its correct operation.

Use the show connection global EXEC command to verify the status of the FRF.5 connection. The all option is used with the show connection command to display all existing connections created on the router. The id option can be used with the command to view more detailed information of the specified id connection. Note that the router sequentially allocates the connection id when the interworking connection is provisioned. The connection id is not reset when the interworking connection is shut down or removed but only when the router is reloaded. Example 8-9 shows the two variations of the show connection command executed on router R2. The possible state or status of the connection can be UP, DOWN, or ADMIN DOWN.

Example 8-9. Display Output of the show connection Command at R2
R2#show connection all

ID   Name               Segment 1            Segment 2           State
========================================================================
6    frf5              Serial1/3 16         ATM3/0 1/32          UP

R2#show connection id 6

FR/ATM Network Interworking Connection: frf5
  Status    - UP
  Segment 1 - Serial1/3 DLCI 16
  Segment 2 - ATM3/0 VPI 1 VCI 32
  Interworking Parameters -
    fr-sscs-dlci 1022
    de-bit map-clp
clp-bit map-de

The first thing to notice in Example 8-9 is the State. The State indicates the FRF.5 connection is up and running properly. The more detailed display by the show connection id command shows the interworking parameters configured. Observe that the FR-SSCS DLCI used is 1022, which is the default if it is not configured under the vc-group. The show frame-relay pvc command and the show atm pvc command can be used at R2 to verify the status of the Frame Relay DLCI and ATM PVC respectively, as shown in Example 8-10. Notice in Example 8-10, the DLCI usage now reflects that the Frame Relay PVC is being configured for FRF.5. The output of the show atm pvc command displays the ATM PVC statistics, and the encapsulation used is for Frame Relay to ATM interworking.

Example 8-10. Output of the show frame-relay pvc Command at R2
R2#show frame-relay pvc 16

PVC Statistics for interface Serial1/3 (Frame Relay DCE)

DLCI = 16, DLCI USAGE = FRF.5, PVC STATUS = ACTIVE, INTERFACE = Serial1/3

  input pkts 13            output pkts 10           in bytes 4407
  out bytes 3290           dropped pkts 0           in pkts dropped 0
  out pkts dropped 0                out bytes dropped 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 13
  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 00:09:53, last time pvc status changed 00:09:52

R2#show atm pvc
           VCD /                                        Peak  Avg/Min Burst
Interface  Name         VPI   VCI  Type   Encaps   SC   Kbps   Kbps   Cells  Sts
3/0        5              1    32  PVC    FR-ATM   UBR  155000                UP

Example 8-11 checks out the connectivity between the end stations R1 and R4.

Example 8-11. R1 Is Able to Reach R4 Over the ATM Network Supporting FRF.5
R1#ping 172.16.1.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.1.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 68/68/68 ms

The next example verifies the configuration for FRF.5 connection using many-to-one multiplexing. R2 and R3 are reconfigured for a many-to-one connection, and Example 8-12 shows the configuration changes at R2 and R3. Most noticeably, a vc-group is created at each FRF.5 router to map multiple Frame Relay DLCIs to FR-SSCS DLCIs. The FR-SSCS DLCIs configured between R2 and R3 must match, otherwise the FRF.5 router is not able to match the correct frame sent from its peer. Example 8-13 shows the output displayed by the show connection id and show vc-group commands after the configuration changes are applied.

Example 8-12. Configuration Changes at R2 and R3 to Enable Many-to-One Multiplexing
R2#show running
<output omitted>
!
connect frf5 vc-group many-to-one ATM3/0 1/32
 !
!
vc-group many-to-one
 Serial1/3 16 100
 Serial1/3 17 101

R3#show running
<output omitted>
!
connect frf5 vc-group many-to-one ATM0 1/32
 !
!
vc-group many-to-one
 Serial1 26 100
 Serial1 27 101

Example 8-13. Shows the Output of the show connection id Command and the show vc-group Command Executed at R2 and R3
! R2

R2#show connection id 7

FR/ATM Network Interworking Connection: frf5
  Status    - UP
  Segment 1 - VC-Group many-to-one
  Segment 2 - ATM3/0 VPI 1 VCI 32
  Interworking Parameters -
    de-bit map-clp
    clp-bit map-de

R2#show vc-group many-to-one
VC Group: many-to-one, Number of VCs: 2
======================================================
 Serial1/3 DLCI 16, FR-SSCS DLCI 100
 Serial1/3 DLCI 17, FR-SSCS DLCI 101

! R3

R3#show connection id 8

FR/ATM Network Interworking Connection: frf5
  Status    - UP
  Segment 1 - VC-Group many-to-one
  Segment 2 - ATM0 VPI 1 VCI 32
  Interworking Parameters -
    de-bit map-clp
clp-bit map-de

R3#show vc-group many-to-one
VC Group: many-to-one, Number of VCs: 2
======================================================
 Serial1 DLCI 26, FR-SSCS DLCI 100
 Serial1 DLCI 27, FR-SSCS DLCI 101

Example 8-14 demonstrates the router R1 is now able to reach router R4 over the ATM networking supporting FRF.5.

Example 8-14. R1 Is Able to Reach R4 over the ATM Network Supporting FRF.5 via Both 172.16.1.0/30 and 172.16.2.0/30
R1#ping 172.16.1.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.1.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 68/68/68 ms

R1#ping 172.16.2.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.2.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 68/68/68 ms


Configuring FRF.8.1 Service Interworking

To understand the configuration commands needed to enable FRF.8.1 service interworking, refer to the network depicted in Figure 8-16 for illustration.

Figure 8-16. Network for Configuring FRF.8.1 Commands

In Figure 8-16, R2 is the FRF.8.1 router that performs the service interworking function between the Frame Relay and the ATM networks. To enable FRF.8.1 on R2, follow the configuration steps listed below:

Step 1. | Enter the interface configuration mode of the serial interface connected to the Frame Relay network with the interface serial number command and enable Frame Relay encapsulation with the encapsulation frame-relay command.
Step 2. | If the incoming Frame Relay PVC is an SVC, identify it with the frame-relay interface-dlci dlci switched interface configuration command. If the incoming Frame Relay PVC is a terminated VC, this step is not required.
Step 3. | Configure the ATM interface connected to the ATM network and enter the interface configuration mode with the interface atm number command.
Step 4. | Create the ATM PVC with the VPI/VCI pair using the pvc [pvc-name] vpi/vci interface configuration command. The ATM PVC can be identified using a pvc-name but it is optional. The VPI/VCI value is usually assigned by the provider and configured on the ATM switch.
Step 5. | Configure the ATM adaptation layer and encapsulation type for the ATM PVC with the encapsulation aal5mux fr-atm-srv command. The aal5mux encapsulation has slightly less overhead compared with the default aal5snap encapsulation. The aal5mux encapsulation is usually used to dedicate the specified PVC to only a single protocol.
Step 6. | Create a connection to connect the Frame Relay DLCI to the ATM PVC using connect connection-name FR-interface FR-DLCI ATM-interface ATM-PVC service-interworking global configuration command. The service-interworking option specifies that FRF.8.1 is used.
Step 7. | (optional) Under the FRF.8.1 configuration mode, set the ATM CLP bit for traffic in the Frame Relay to ATM direction using the clp-bit {0 | 1 | map-de} command. As we have seen earlier, the default configuration is clp-bit map-de. (Note that this command is presently available on Cisco MC3810, 2600, and 3600 series routers only.)
Step 8. | (optional) Under the FRF.8.1 configuration mode, set the DE bit for traffic in the ATM to Frame Relay direction using the de-bit {0 | 1 | map-clp} command. This is the default. Use the no form of the command to disable CLP bit to DE bit mapping. (Note that this command is presently available on Cisco MC3810, 2600, and 3600 series routers only.)
Step 9. | (optional) Under the FRF.8.1 configuration mode, use the efci-bit {0 | map-fecn} command to set the EFCI bit in the ATM cell header to 0 or specify that the EFCI is to be mapped from the FECN bit for traffic in the Frame Relay to ATM direction. (Note that this command is presently available on Cisco MC3810, 2600, and 3600 series routers only.)
Step 10. | (optional) Select FRF.8.1 to use transparent or translation mode with the service translation command under frf8 configuration mode. The default is service translation.
Step 11. | To enable the FRF.8.1 service interworking connection, perform no shutdown. Use the shutdown command to disconnect the FRF.5 service interworking connection.

The configuration commands required to enable the FRF.8.1 service interworking function at R2 are shown in Example 8-15.

Example 8-15. Configuration Examples of Routers R1, R2, and R3 in Figure 8-16 for Setting Up FRF.8.1 Service Interworking
R1#show running
<output omitted>
!
interface Serial0/0.16 point-to-point
 ip address 172.16.1.1 255.255.255.0
 frame-relay interface-dlci 16

R2#show running
<output omitted>
!
interface Serial1/3
 no ip address
 encapsulation frame-relay
 frame-relay interface-dlci 16 switched
!
interface ATM3/0
 no ip address
 no ip route-cache
 no atm ilmi-keepalive
 pvc 1/32
encapsulation aal5mux fr-atm-srv
!
connect frf8 Serial1/3 16 ATM3/0 1/32 service-interworking

R3#show running
<output omitted>
!
interface ATM0.1 multipoint
 ip address 172.16.1.2 255.255.255.0
 pvc 1/32
  protocol ip 172.16.1.1 broadcast
encapsulation aal5snap

The next example in Example 8-16 shows the output displayed by the show connection id, show frame-relay pvc and the show atm pvc commands performed at router R2.

Example 8-16. Output of the show connection id, show frame-relay pvc, and show atm pvc Commands Executed at R2
R2#show connection id 8

FR/ATM Service Interworking Connection: frf8
  Status    - UP
  Segment 1 - Serial1/3 DLCI 16
  Segment 2 - ATM3/0 VPI 1 VCI 32
Interworking Parameters -
    service translation
    efci-bit 0
    de-bit map-clp
clp-bit map-de

R2#show frame-relay pvc 16

PVC Statistics for interface Serial1/3 (Frame Relay DCE)

DLCI = 16, DLCI USAGE = FRF.8, PVC STATUS = ACTIVE, INTERFACE = Serial1/3

  input pkts 2             output pkts 0            in bytes 674
  out bytes 0              dropped pkts 0           in pkts dropped 0
  out pkts dropped 0                out bytes dropped 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 2
  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 00:07:32, last time pvc status changed 00:07:24

R2#show atm pvc
           VCD /                                        Peak  Avg/Min Burst
Interface  Name         VPI   VCI  Type   Encaps   SC   Kbps   Kbps   Cells Sts
3/0        5              1    32  PVC    FRATMSRV UBR  155000               UP

Example 8-17 validates router R1 is now able to exchange packets with router R3 due to the FRF.8.1 Service Interworking Function performed by router R2.

Example 8-17. R1 Is Able to Exchange Packets with R3 via the FRF.8.1 Service Interworking Function at R2
R1#ping 172.16.1.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.1.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 36/37/40 ms


Summary

In this chapter, you learned about the ATM WAN protocol and how this emerging technology can complement Frame Relay to improve the economics of scale and network scalability for service providers.

The Frame Relay Forum and the ATM Forum outlined two Frame Relay to ATM interworking implementation agreement documents to support Frame Relay to ATM Interworking: network interworking (FRF.5) and service interworking (FRF.8.1). Cisco's implementation of the Frame Relay to ATM Interworking feature supports both FRF.5 and FRF.8.1.

The Frame Relay to ATM Interworking function has gained popularity in the market because of the emergence of high-speed and affordable access technologies such as Digital Subscriber Line (DSL). In some of the most popular applications, a Frame Relay end user uses DSL technology to gain high-speed access to the core ATM backbone. The FRF.8.1 service interworking function performs the frame-to-cell translation to allow the Frame Relay traffic to be carried into an ATM network.

FRF.5, or networking interworking, allows two similar Frame Relay service users to communicate with each other over an ATM network that supports FRF.5.

FRF.8.1, or service interworking, allows a Frame Relay service user to interoperate directly with an ATM service user. FRF.8.1 supports two modes of operation, transparent and translation. Translation mode performs protocol translation between the supported protocol stacks, whereas transparent mode forwards the payload unaltered.

Both FRF.5 and FRF.8.1 support functionalities to allow native congestion indication mechanisms in Frame Relay and ATM protocols to be mapped over to each other.

This chapter demonstrated the configuration tasks necessary to configure FRF.5 and FRF.8.1 on a Cisco router. This chapter showed the relevant Cisco IOS configuration commands for FRF.5 and FRF.8.1 using practical configuration examples. Furthermore, this chapter discussed the Cisco IOS show and debug commands for monitoring and maintaining the FRF.5 and FRF.8.1 configurations on a Cisco router.

The next chapter discusses the Adaptive Frame Relay Traffic Shaping for Interface Congestion feature.


Review Questions

1: | How do ATM and Frame Relay technologies compare?
2: | What is the purpose of Frame Relay to ATM Interworking?
3: | How do FRF.5 network interworking and FRF.8.1 service interworking compare?
4: | How do FRF.8.1 translation and transparent modes compare?
5: | What happens when FRF.8.1 service interworking in the transparent mode is deployed between two pieces of terminal equipment with dissimilar encapsulation types?
6: | What is the FRF.8.1 bidirectional congestion indication support?
7: | What is ATM equivalent to Frame Relay's DE bit?


References

This chapter is based on the following documentation:

  • Frame Relay Forum Implementation Agreement FRF.5: Frame Relay/ATM PVC Networking Interworking, December 1994: http://www.mplsforum.org/frame/Approved/FRF.5/frf.5.pdf

  • Frame Relay Forum Implementation Agreement FRF.8.1: Frame Relay/ATM PVC Service Interworking, February 2000: http://www.mplsforum.org/frame/Approved/FRF.8/FRF.8.1.pdf

  • Cisco IOS Release 12.1(2)T: Frame Relay-to-ATM Network Interworking (FRF.5): http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121newft/121t/121t2/dtfratm5.htm

  • Cisco IOS Release 12.1(2)T: Frame Relay-to-ATM Service Interworking (FRF.8): http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121newft/121t/121t2/dtfratm8.htm


Chapter 9. Adaptive Frame Relay Traffic Shaping for Interface Congestion

Chapter 5, "Frame Relay Traffic Shaping," introduced the principal congestion control mechanism for managing Frame Relay traffic on Cisco routers. This chapter discusses the Adaptive Frame Relay Traffic Shaping for Interface Congestion feature, which is essentially an enhancement feature to the Frame Relay Traffic Shaping functionality. This chapter explains the purpose of the feature and its benefits and introduces the Cisco IOS configuration and monitoring commands in a case study.

The topics and questions that this chapter addresses include the following:

  • Overview of the Adaptive Frame Relay Traffic Shaping for Interface Congestion feature

  • The benefits of the Adaptive Frame Relay Traffic Shaping for Interface Congestion feature

  • Configuring Adaptive Frame Relay Traffic Shaping for Interface Congestion on a Cisco router

  • Verifying Adaptive Frame Relay Traffic Shaping for Interface Congestion configurations on a Cisco router

  • Case studies on the Adaptive Frame Relay Traffic Shaping for Interface Congestion feature

After completing this chapter, readers will be able to recognize the benefits of the Adaptive Frame Relay Traffic Shaping for Interface Congestion feature. Readers will become familiar with how the feature works and how it controls congestion at the interface level. Readers will learn how to configure the feature on a Cisco router. Readers will be able to use Cisco IOS show commands to monitor and maintain the configurations of the feature on a Cisco router.


Current Issues

This section describes the requirements and the purpose of the Adaptive Frame Relay Traffic Shaping for Interface Congestion feature. But first, it is important to understand fully the queuing mechanisms employed by Frame Relay interfaces configured on Cisco routers to appreciate the benefits of the Adaptive Frame Relay Traffic Shaping for Interface Congestion feature.

When Frame Relay encapsulation is configured on a Cisco router interface, a hierarchical queuing mechanism involving two different levels is set up: one at the virtual circuit (VC) and another at the interface level. When congestion builds up in the Frame Relay network, outgoing Frame Relay packets waiting to be transmitted by the router can be queued up in the two different levels of queues before they are eventually sent out from the egress interface onto the wire.

As explained in Chapter 5, the queuing methods supported by the Frame Relay Traffic Shaping feature are custom, priority, or default First-In-First-Out (FIFO) queuing. They are applied at the VC level by configuring a Frame Relay map-class. The configured Frame Relay map class is then applied to a DLCI using the frame-relay class class-name or class class-name command. The frame-relay class class-name command can be used to associate a Frame Relay map class with a physical serial interface or a multipoint Frame Relay subinterface. Once associated, all Frame Relay PVCs created on the physical serial interface or multipoint subinterface inherit the configuration parameters configured in the map class. On the other hand, the class class-name command under the DLCI configuration mode should be used when associating a Frame Relay map class directly with a DLCI.

NOTE

The latest Cisco IOS software releases now allow Frame Relay Traffic Shaping to support advanced queuing mechanisms such as Class-Based Weighted Fair Queuing (CBWFQ) and Low Latency Queuing (LLQ). CBWFQ and other advanced queuing strategies are discussed in Part IV, "Cisco Frame Relay Solutions for Congestion Management," later in this book.

Congestion in the Frame Relay Network

When congestion occurs in the Frame Relay network, outgoing Frame Relay packets waiting for delivery on a DLCI are queued on the VC level queues that are applied to the particular DLCI. Subsequently, the queued Frame Relay packets are removed from the VC level queues and sent to the egress interface for transmission. If the egress interface buffer is temporarily full and unable to handle the transmission of packets, the packets are further held up in the interface level queues waiting for their turn or are eventually dropped. This process is illustrated in Figure 9-1.

Figure 9-1. VC Queuing and Interface Queuing on a Frame Relay Interface

The Frame Relay Traffic Shaping feature is applied only at the main interface level of a Cisco router. The use of the Frame Relay Traffic Shaping feature forbids other queuing mechanisms from being used at the interface level. When Frame Relay Traffic Shaping is enabled, the queuing strategy at the interface has to be strictly FIFO. FIFO queuing, as its name implies, removes packets from a queue based on their order of arrival.

With oversubscription of bandwidth, the congestion level built up can cause the interface queue to be speedily filled. This happens when the sum of the committed information rate (CIR) of each VC under the Frame Relay interface exceeds the actual interface physical rate. When this condition is prolonged, the interface queue starts to drop packets. Because the packets dropped at the interface level might have been queued according to user-defined priority levels using priority queuing (PQ) applied at the DLCI level, dropping packets at the interface level results in a waste of the queuing efforts performed earlier. Therefore, it becomes necessary to shape the VC to a CIR lower than the access rate so that user data is queued and dropped at the DLCI level if necessary.


Solutions for Current Issues

The Adaptive Frame Relay Traffic Shaping for Interface Congestion feature handles congestion at the physical serial interface level. Adaptive Frame Relay Traffic Shaping for Interface Congestion is one of the effective Frame Relay solutions that are used to alleviate congestion built up at the interface. Cisco developed the Adaptive Frame Relay Traffic Shaping for Interface Congestion feature as an enhancement to the Frame Relay Traffic Shaping feature discussed in Chapter 5. The main purpose of Adaptive Frame Relay Traffic Shaping for Interface Congestion is to dynamically throttle the VC egress rate when congestion is detected at the interface queue. When congestion eases, it dynamically adjusts the VC egress rate on the VC based on the congestion level in the interface queue. When the interface experiences congestion, Adaptive Frame Relay Traffic Shaping for Interface Congestion helps to ensure packet drops occur early at the VC queues, rather than being delayed or dropped eventually at the interface queue.

NOTE

The Adaptive Frame Relay Traffic Shaping for Interface Congestion feature is a Cisco-specific feature and it is available in Cisco IOS Release 12.2(4)T and later.

When the feature is enabled, the traffic shaping mechanism actively monitors the congestion condition in the interface queue. This feature complements the Frame Relay Traffic Shaping feature by reducing the output rates of all the VCs to their MINCIR (Minimum CIR) value when the congestion level in the interface queue exceeds a configured threshold, known as the queue depth. When the congestion level in the interface queue is above the configured queue depth, Adaptive Frame Relay Traffic Shaping for Interface Congestion throttles the VC egress rate from CIR to MINCIR. When the congestion level in the interface queue falls below the queue depth, the traffic shaping mechanism increases the output rate of all the VCs back to their CIR rate.

This process serves many benefits. First, it guarantees the MINCIR for all VCs on the interface during sustained periods of congestions. Second, it reduces packet drops taking place at the interface queue by throttling down the output rates of the VCs when there is a sign of the interface queues getting congested (via the user configured queue depth). Finally, before the release of this feature, Frame Relay packets fragmented by FRF.12 function were susceptible to packet drops at the interface queue. FRF.12 belongs to the Frame Relay Forum's Implementation Agreement for the fragmentation of Frame Relay frames. Any dropped fragment resulted in the whole frame being unusable and the end stations having to retransmit the entire frame. When the feature is used together with FRF.12 Frame Relay Fragmentation (applicable at the DLCI level), it ensures that packet drops occur early in the VC queues before any fragmentation occurs.

NOTE

This feature requires the sum of the MINCIR values (default to 56 kbps) for all VCs on the interface to be lower than the interface bandwidth.

Using map-class

The Adaptive Frame Relay Traffic Shaping feature is configured with a Frame Relay map class, and the default behavior for the feature is disabled. If a VC does not have a Frame Relay map class associated with it, or the map class attached to the DLCI does not have interface congestion configured, the PVC does not react to the congestion level marked by the queue depth in the interface queue.

The size of the queue depth is user-configurable, and the acceptable value for queue depth ranges from 0 to 40. If the queue depth is not configured, it defaults to 0, which essentially means all the VCs associated with the map class always send at their configured MINCIR values.

After the feature is fully enabled (by configuring the map class and associating it with the DLCI), the shaping mechanism actively measures the queue depth of the interface queue and drops the output rate of the VC to its MINCIR once the queue depth is exceeded. When the number of packets in the interface queue drops below the configured queue depth, the shaping mechanism allows the VC to send at its CIR again. Compared with the slow start mechanism in adaptive traffic shaping to BECN or ForeSight, this swiftly avoids any underutilization of the link.

The feature allows interoperability with adaptive shaping to BECN or ForeSight functionality. If interface congestion exceeds the queue depth when Adaptive Frame Relay Traffic Shaping for Interface Congestion is enabled together with adaptive shaping to BECN or ForeSight, the PVC output rate is reduced to its MINCIR value. When the interface congestion drops below the configured queue depth, the PVC output rate reacts to adaptive shaping to BECN or ForeSight and is adjusted according to BECN tagged packets or ForeSight messages received.

The flow diagram for the Adaptive Frame Relay Traffic Shaping for Interface Congestion feature is depicted in Figure 9-2.

Figure 9-2. Flow Diagram for Adaptive Frame Relay Traffic Shaping for Interface Congestion

NOTE

The Adaptive Frame Relay Traffic Shaping for Interface Congestion feature is supported on terminated and switched PVCs only. Switched virtual circuits (SVCs) are not supported by the feature. In addition, the current supported Cisco router platforms are the c2500, c2600, c3600, and c7200 series routers.


Configuring Adaptive Frame Relay Traffic Shaping for Interface Congestion

The Frame Relay Traffic Shaping feature must be enabled on the interface in order to use Adaptive Frame Relay Traffic Shaping for Interface Congestion. Refer to Chapter 5 for the configuration tasks required to enable Frame Relay Traffic Shaping.

To configure Adaptive Frame Relay Traffic Shaping for Interface Congestion, perform the configuration steps listed below:

Step 1. | Enter the interface configuration mode of the serial interface and enable Frame Relay encapsulation with the encapsulation frame-relay command.
Step 2. | Enable Frame Relay traffic shaping on the main interface with the frame-relay traffic-shaping interface configuration command.
Step 3. | Configure a Frame Relay map class using the frame-relay map-class map-class-name global configuration command.
Step 4. | Enable Adaptive Frame Relay Traffic Shaping for Interface Congestion and set the queue depth with the frame-relay adaptive-shaping interface-congestion [queue-depth]. The valid range for queue-depth is 0 to 40. If queue-depth is not specified, the default value is 0.

A configuration example of Adaptive Frame Relay Traffic Shaping for Interface Congestion is shown in Example 9-1. Examples are based on the topology diagram shown in Figure 9-3 to explain the configuration commands and the functionalities of the feature.

Example 9-1. Sample Configurations of Adaptive Frame Relay Traffic Shaping for Interface Congestion Based on Figure 9-3
! R1
interface Serial3
 no ip address
 encapsulation frame-relay
 clockrate 128000
!
interface Serial3.100 point-to-point
 ip address 192.168.1.1 255.255.255.0
 no ip route-cache
 frame-relay interface-dlci 100

!R2
frame-relay switching
!
interface Serial3/3
 no ip address
 encapsulation frame-relay
 frame-relay interface-dlci 100 switched
  load-interval 30
 frame-relay intf-type dce
!
interface Serial3/1
 no ip address
 encapsulation frame-relay
 no fair-queue
 frame-relay traffic-shaping
 frame-relay interface-dlci 200 switched
  class FRTS
  load-interval 30
 frame-relay intf-type dce
!
map-class frame-relay FRTS
 frame-relay cir 112000
 frame-relay bc 14000
 frame-relay mincir 56000
 frame-relay adaptive-shaping interface-congestion 10
connect FRTS Serial3/3 100 Serial3/1 200

!R3
interface Serial1/1
 no ip address
 encapsulation frame-relay
 clockrate 128000
!
interface Serial1/1.200 point-to-point
 ip address 192.168.1.2 255.255.255.0
 frame-relay interface-dlci 200

Figure 9-3. Topology for Verifying Adaptive Frame Relay Traffic Shaping for Interface Congestion

Previous Page
Next Page


Verifying Adaptive Frame Relay Traffic Shaping for Interface Congestion

In Example 9-1, the frame-relay adaptive-shaping interface-congestion 10 map-class configuration command is configured under the Frame Relay map class named FRTS on R2. The map class FRTS is attached to switched DLCI 200 under interface serial3/1. The queue depth is chosen to be 10 packets.

The show frame-relay pvc command can be used to verify that Adaptive Frame Relay Traffic Shaping for Interface Congestion is enabled for the DLCI. This is shown in Example 9-2.

Example 9-2. Sample Output of show frame-relay pvc Command at R2
R2#show frame-relay pvc 200

PVC Statistics for interface Serial3/1 (Frame Relay DCE)

DLCI = 200, DLCI USAGE = SWITCHED, PVC STATUS = ACTIVE, INTERFACE = Serial3/1

  input pkts 102           output pkts 65           in bytes 10561
  out bytes 7740           dropped pkts 0           in pkts dropped 0
  out pkts dropped 0                out bytes dropped 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
  30 second input rate 0 bits/sec, 0 packets/sec
  30 second output rate 0 bits/sec, 0 packets/sec
  switched pkts 102
  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 00:17:58, last time pvc status changed 00:17:19
  cir 112000    bc 14000     be 0         byte limit 1750   interval 125
  mincir 56000     byte increment 1750  Adaptive Shaping IF_CONG
  pkts 66        bytes 8037      pkts delayed 0         bytes delayed 0
  shaping inactive
  traffic shaping drops 0
  Queueing strategy: fifo
Output queue 0/40, 0 drop, 0 dequeued

In Example 9-2, observe the keyword Adaptive Shaping IF_CONG in the show frame-relay pvc 200 output. The output tells you that Adaptive Frame Relay Traffic Shaping for Interface Congestion has been enabled for DLCI 200. Also notice that "shaping inactive" is in the show frame-relay pvc 200 output. This indicates that the frame-relay traffic-shaping command has been enabled on the main interface serial3/1, but shaping is currently inactive due to the absence of traffic.

Using show interface serial Command as an Alternative

The show interface serial type/number global EXEC command can also be used to verify that Adaptive Frame Relay Traffic Shaping for Interface Congestion is working properly. If the feature is functioning correctly, the number of packets in the output queue should be equal to or close to the configured queue depth.

Example 9-3. Sample Output of show interface Command
R2#show inter serial3/1
Serial3/1 is up, line protocol is up
  Hardware is M4T
  MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec,
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation FRAME-RELAY, crc 16, loopback not set
  Keepalive set (10 sec)
  Restart-Delay is 0 secs
  LMI enq sent  0, LMI stat recvd 0, LMI upd recvd 0
  LMI enq recvd 159, LMI stat sent  159, LMI upd sent  0, DCE LMI up
  LMI DLCI 1023  LMI type is CISCO  frame relay DCE
  FR SVC disabled, LAPF state down
  Broadcast queue 0/64, broadcasts sent/dropped 0/0, interface      broadcasts 0
  Last input 00:00:00, output 00:00:00, output hang never
  Last clearing of "show interface" counters 00:27:34
  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
  Queueing strategy: fifo
  Output queue :0/40 (size/max)
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
     270 packets input, 16165 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
     234 packets output, 13001 bytes, 0 underruns
     0 output errors, 0 collisions, 2 interface resets
     0 output buffer failures, 0 output buffers swapped out
     5 carrier transitions     DCD=up  DSR=up  DTR=up  RTS=up  CTS=up


Summary

This chapter presented the Adaptive Frame Relay Traffic Shaping for Interface Congestion enhancement feature. This feature is an improvement to the Frame Relay Traffic Shaping feature, allowing Frame Relay users who oversubscribe their Frame Relay connections to effectively manage congestion and packet drops at the routers' interface level. The feature provides an early warning by detecting the congestion condition in the interface queue and ensuring that packets are dropped early at the VC queues in times of congestion. In a Frame Relay network, this feature is useful with Frame Relay Traffic Shaping if congestion or oversubscription is fairly common on the network.

This chapter explained the configuration tasks and the Cisco IOS configuration commands involved in configuring the Adaptive Frame Relay Traffic Shaping for Interface Congestion feature on a Cisco router. In addition, this chapter presented the useful Cisco IOS show commands for monitoring and maintaining the feature. Finally, the case study sections in this chapter present an example of an application for the Adaptive Frame Relay Traffic Shaping for Interface Congestion feature.

The next chapter discusses the Point-to-Point Protocol over Frame Relay feature.


Review Questions

1: | What is the main use of the Adaptive Frame Relay Traffic Shaping for Interface Congestion feature?
2: | What is the difference between the frame-relay class class-name and class class-name commands?
3: | What is the default queue depth for Frame Relay Adaptive Shaping for Interface Congestion?
4: | What is the default queuing strategy at the interface level when Frame Relay Traffic Shaping is configured?
5: | Describe the actions when the current queue size exceeds the configured queue depth of the interface queue when Adaptive Frame Relay Traffic Shaping for Interface Congestion feature is enabled.
6: | Describe the actions when the current queue size falls below the configured queue depth of the interface queue when Adaptive Frame Relay Traffic Shaping for Interface Congestion feature is enabled.


Reference

Cisco IOS Release 12.2(4)T - Adaptive Frame Relay Traffic Shaping for Interface Congestion: http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122newft/122t/122t4/ft_afrts.htm


Case Study: Without Adaptive Frame Relay Traffic Shaping for Interface Congestion

This section uses the configuration setup in Example 9-1 to demonstrate the interface congestion condition at R2 when Adaptive Frame Relay Traffic Shaping for Interface Congestion is not enabled. The difference in performance with and without enabling Adaptive Frame Relay Traffic Shaping for Interface Congestion is compared. The contrast in performance is between intelligent packet drops occurring at the VC level and packet drops happening at the interface level.

R1 is configured to send a continuous stream of traffic to R3 via R2 at a rate of 128 kbps. R2 is set up with a CIR of 112 kbps. Notice that the upstream DLCI 100 has twice the bandwidth capacity compared with the downstream DLCI 200. This simulates a bandwidth mismatch commonly seen in a hub-and-spoke topology. It is used to create a bottleneck so that congestion can build up at R2. The configured traffic rate of 128 kbps is sufficient to generate a congestion condition in R2's outgoing interface along the data path.

Example 9-4 shows the configuration file of R2. Notice that the frame-relay adaptive-shaping interface-congestion 10 command configured in the map class earlier has been omitted.

Example 9-4. Configuration of R2 Without Adaptive Frame Relay Traffic Shaping for Interface Congestion
frame-relay switching
!
interface Serial3/3
 no ip address
 encapsulation frame-relay
 frame-relay interface-dlci 100 switched
  load-interval 30
 frame-relay intf-type dce
!
interface Serial3/1
 no ip address
 encapsulation frame-relay
 no fair-queue
 frame-relay traffic-shaping
 frame-relay interface-dlci 200 switched
  class FRTS
  load-interval 30
 frame-relay intf-type dce
!
map-class frame-relay FRTS
 frame-relay cir 112000
 frame-relay bc 14000
 frame-relay mincir 56000
connect FRTS Serial3/3 100 Serial3/1 200

The traffic stream is sent from R1. Example 9-5 shows the output of the show interface command at R2 after 5 minutes.

Example 9-5. show interface Output of R2 Without Enabling Adaptive Frame Relay Traffic Shaping for Interface Congestion
R2#show interface s3/1
Serial3/1 is up, line protocol is up
  Hardware is M4T
  MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec,
     reliability 255/255, txload 11/255, rxload 1/255
  Encapsulation FRAME-RELAY, crc 16, loopback not set
  Keepalive set (10 sec)
  Restart-Delay is 0 secs
  LMI enq sent  0, LMI stat recvd 0, LMI upd recvd 0
  LMI enq recvd 12, LMI stat sent  12, LMI upd sent  0, DCE LMI up
  LMI DLCI 1023  LMI type is CISCO  frame relay DCE
  FR SVC disabled, LAPF state down
  Broadcast queue 0/64, broadcasts sent/dropped 0/0, interface broadcasts 0
  Last input 00:00:04, output 00:00:00, output hang never
  Last clearing of "show interface" counters 00:02:04
  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 700
  Queueing strategy: fifo
  Output queue :40/40 (size/max)
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute output rate 72000 bits/sec, 9 packets/sec
     14 packets input, 942 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
     1156 packets output, 1143469 bytes, 0 underruns
     0 output errors, 0 collisions, 0 interface resets
     0 output buffer failures, 0 output buffers swapped out
0 carrier transitions     DCD=up  DSR=up  DTR=up  RTS=up  CTS=up

Example 9-6 depicts the output of the show frame-relay pvc 200 command on router R2, which does not have Adaptive Frame Relay Traffic Shaping for Interface Congestion enabled.

Example 9-6. show frame-relay pvc Output Without Enabling Adaptive Frame Relay Traffic Shaping for Interface Congestion
R2#show frame-relay pvc 200

PVC Statistics for interface Serial3/1 (Frame Relay DCE)

DLCI = 200, DLCI USAGE = SWITCHED, PVC STATUS = ACTIVE, INTERFACE = Serial3/1

  input pkts 4             output pkts 3023         in bytes 1572
  out bytes 3021594        dropped pkts 327         in pkts dropped 0
  out pkts dropped 327              out bytes dropped 326297
  late-dropped out pkts 327         late-dropped out bytes 326297
  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
  30 second input rate 0 bits/sec, 0 packets/sec
  30 second output rate 111000 bits/sec, 14 packets/sec
  switched pkts 4
  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 327       pkt above DE 0           policing drop 0
  pvc create time 04:13:25, last time pvc status changed 04:08:55
  cir 112000    bc 112000    be 0         byte limit 1750   interval 125
  mincir 32000     byte increment 1750  Adaptive Shaping none
  pkts 2998      bytes 2996594   pkts delayed 2988      bytes delayed 2986594
  shaping active
  traffic shaping drops 0
  Queueing strategy: fifo
  Output queue 39/40, 331 drop, 3002 dequeued

The results clearly indicate that without Adaptive Frame Relay Traffic Shaping for Interface Congestion, the Frame Relay router is unable to control packet drops occurring at the interface level. Although Frame Relay Traffic Shaping is able to perform rate limiting and to control the output rate at the CIR value, it is unable to prevent congestion from taking place at the queues. This is particularly true when the Frame Relay network is heavily oversubscribed.

Although Adaptive Frame Relay Traffic Shaping with BECN or ForeSight is effective, it depends on the ability of the Frame Relay switch or network to respond to the congestion and send BECN tagged packets or ForeSight messages.


Case Study: With Adaptive Frame Relay Traffic Shaping for Interface Congestion

The frame-relay adaptive-shaping interface-congestion 10 command is now configured under the Frame Relay map-class associated with DLCI 200. Example 9-7 shows the condition at R2's outgoing serial interface after 5 minutes of traffic is sent from R1.

Example 9-7. show interface Output at R2
Upstream interface at R2:

R2#show interface serial3/3
Serial3/3 is up, line protocol is up
  Hardware is M4T
  MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec,
     reliability 255/255, txload 1/255, rxload 20/255
  Encapsulation FRAME-RELAY, crc 16, loopback not set
  Keepalive set (10 sec)
  Restart-Delay is 0 secs
  LMI enq sent  0, LMI stat recvd 0, LMI upd recvd 0
  LMI enq recvd 51, LMI stat sent  51, LMI upd sent  0, DCE LMI up
  LMI DLCI 1023  LMI type is CISCO  frame relay DCE
  FR SVC disabled, LAPF state down
  Broadcast queue 0/64, broadcasts sent/dropped 0/0, interface broadcasts 0
  Last input 00:00:05, output 00:00:05, output hang never
  Last clearing of "show interface" counters 00:08:30
  Input queue: 0/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/1/256 (active/max active/max total)
     Reserved Conversations 0/0 (allocated/max allocated)
     Available Bandwidth 1158 kilobits/sec
  5 minute input rate 124000 bits/sec, 15 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
     7701 packets input, 7644336 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
     59 packets output, 3879 bytes, 0 underruns
     0 output errors, 0 collisions, 0 interface resets
     0 output buffer failures, 0 output buffers swapped out
     0 carrier transitions     DCD=up  DSR=up  DTR=up  RTS=up  CTS=up

Downstream interface at R2:

R2#show interface s3/1
Serial3/1 is up, line protocol is up
  Hardware is M4T
  MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec,
     reliability 255/255, txload 10/255, rxload 1/255
  Encapsulation FRAME-RELAY, crc 16, loopback not set
  Keepalive set (10 sec)
  Restart-Delay is 0 secs
  LMI enq sent  0, LMI stat recvd 0, LMI upd recvd 0
  LMI enq recvd 49, LMI stat sent  49, LMI upd sent  0, DCE LMI up
  LMI DLCI 1023  LMI type is CISCO  frame relay DCE
  FR SVC disabled, LAPF state down
  Broadcast queue 0/64, broadcasts sent/dropped 0/0, interface broadcasts 0
  Last input 00:00:01, output 00:00:00, output hang never
  Last clearing of "show interface" counters 00:08:03
  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 3437
  Queueing strategy: fifo
  Output queue :11/40 (size/max)
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute output rate 64000 bits/sec, 8 packets/sec
     57 packets input, 3781 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
     3785 packets output, 3734592 bytes, 0 underruns
     0 output errors, 0 collisions, 0 interface resets
     0 output buffer failures, 0 output buffers swapped out
0 carrier transitions     DCD=up  DSR=up  DTR=up  RTS=up  CTS=up

In the show interface output of both interfaces at R2 shown in Example 9-7, pay close attention to the downstream serial interface 3/1. The number of packets held up (queued up) in the output interface queue is read as 11 packets. This is because the queue depth configured for Adaptive Frame Relay Traffic Shaping for Interface Congestion in the Frame Relay map class is 10. This verifies that Adaptive Frame Relay Traffic Shaping for Interface Congestion is working correctly. Because the output rate fluctuates between CIR and MINCIR, the actual number of packets in the output interface queue might not be exactly equal to the configured queue depth, but it should be very close to the configured value.

Example 9-8 illustrates the output of the show frame-relay pvc 200 command at R2. It shows that packets are dropped at the VC level.

Example 9-8. show frame-relay pvc Output at R2
R2#show frame-relay pvc 200

PVC Statistics for interface Serial3/1 (Frame Relay DCE)

DLCI = 200, DLCI USAGE = SWITCHED, PVC STATUS = ACTIVE, INTERFACE = Serial3/1

  input pkts 17            output pkts 8095         in bytes 6681
  out bytes 8091485        dropped pkts 7544        in pkts dropped 0
  out pkts dropped 7544             out bytes dropped 7535564
  late-dropped out pkts 7544        late-dropped out bytes 7535564
  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
  30 second input rate 0 bits/sec, 0 packets/sec
  30 second output rate 64000 bits/sec, 8 packets/sec
  switched pkts 17
  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 7544      pkt above DE 0           policing drop 0
  pvc create time 00:33:20, last time pvc status changed 00:28:50
  cir 112000    bc 112000    be 0         byte limit 1750   interval 125
  mincir 56000     byte increment 1750  Adaptive Shaping IF_CONG
  pkts 8063      bytes 8059485   pkts delayed 8052      bytes delayed 8049188
  shaping active
  traffic shaping drops 0
  Queueing strategy: fifo
  Output queue 39/40, 7561 drop, 8061 dequeued

When the interface queue depth has exceeded the configured queue depth in the map class, Adaptive Frame Relay Traffic Shaping for Interface Congestion kicks in and drops the output rate to MINCIR (configured as 56,000 kbps). However, this is not readily observed in the show frame-relay pvc command because the functionality allows the output rate to return immediately to the CIR as soon as the queue depth has dropped below the threshold. The output "yo-yos" between the MINCIR and the CIR, but the average output rate should be maintained pretty close to the allowed CIR rate or the physical access rate.

The queue depth value can be adjusted dynamically when the feature is enabled and while traffic is traversing the PVC. The Adaptive Frame Relay Traffic Shaping for Interface Congestion mechanism automatically detects the new threshold and adjusts the output rate accordingly. This is shown in Example 9-9.

Example 9-9. Adjusting the queue-depth Value Dynamically
R2#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
dtwa13(config)#map-class frame-relay FRTS
dtwa13(config-map-class)#frame-relay adaptive-shaping interface-congestion 15

R2#show interface serial3/1
Serial3/1 is up, line protocol is up
  Hardware is M4T
  MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec,
     reliability 255/255, txload 11/255, rxload 1/255
  Encapsulation FRAME-RELAY, crc 16, loopback not set
  Keepalive set (10 sec)
  Restart-Delay is 0 secs
  LMI enq sent  0, LMI stat recvd 0, LMI upd recvd 0
  LMI enq recvd 177, LMI stat sent  177, LMI upd sent  0, DCE LMI up
  LMI DLCI 1023  LMI type is CISCO  frame relay DCE
  FR SVC disabled, LAPF state down
  Broadcast queue 0/64, broadcasts sent/dropped 0/0, interface broadcasts 0
  Last input 00:00:06, output 00:00:00, output hang never
  Last clearing of "show interface" counters 00:29:28
  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 12816
  Queueing strategy: fifo
  Output queue :16/40 (size/max)
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute output rate 72000 bits/sec, 9 packets/sec
     206 packets input, 13698 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
     14540 packets output, 14358511 bytes, 0 underruns
     0 output errors, 0 collisions, 0 interface resets
     0 output buffer failures, 0 output buffers swapped out
     2 carrier transitions     DCD=up  DSR=up  DTR=up  RTS=up  CTS=up


Chapter 10. Point-to-Point Protocol (PPP) over Frame Relay

The Point-to-Point Protocol (PPP) specifies a standard method for transporting different network layer or routed protocols, such as IP, IPX, and SNA, across a physical point-to-point link. This chapter highlights the Cisco PPP over Frame Relay feature, a Cisco Frame Relay solution that allows an end-to-end PPP session to be established over a Frame Relay permanent virtual circuit (PVC). IP traffic can be transported over the PPP link using RFC 1973 compliant Frame Relay framing and encapsulation specifications. The RFC 1973 document is available at http://www.faqs.org/rfcs/rfc1973.html. This chapter features examples that use IOS configuration and debug commands for monitoring PPP over Frame Relay sessions.

The topics and questions that this chapter addresses include the following:

  • Overview of PPP over Frame Relay

  • PPP over Frame Relay frame format

  • Configuring PPP over Frame Relay on a Cisco router

  • Monitoring and maintaining PPP over Frame Relay configurations on a Cisco router

After completing this chapter, readers will understand how PPP over Frame Relay works and how it is related to PPP as defined by RFC 1661. Readers will become familiar with the tasks and Cisco IOS commands required to configure PPP over Frame Relay on a Cisco router. Furthermore, readers will learn the Cisco IOS show and debug commands for monitoring and maintaining PPP over Frame Relay configurations on a Cisco router.


Requirements for PPP over Frame Relay

The Request for Comments (RFC) document number 1661 (known as RFC 1661) outlines PPP as an industry standard protocol that supports router-to-router or host-to-network connections between point-to-point links. As a successor to the Serial Line Internet Protocol (SLIP), PPP was designed to work with several different network layer protocols, such as IP, IPX, and SNA. Unlike PPP, the legacy SLIP only supports IP.

PPP has added security features, such as Challenge Handshake Authentication Protocol (CHAP) and Password Authentication Protocol (PAP), that provide a secured connection via authentication of peers during the establishment phase of the link. To transport the different network layer protocols over PPP, PPP uses the Link Control Protocol (LCP) and Network Control Protocol (NCP) groups of protocols to manage the specified needs of each supported network layer protocol.

PPP is vast, and providing a comprehensive technical coverage of PPP is out of the scope of this book. RFC 1661 outlines the original PPP specifications. The RFC 1661 document is available at http://www.faqs.org/rfcs/rfc1661.html.

With the emergence of fast and affordable access technology such as xDSL, it is important to provide PPP support over Frame Relay virtual circuits (VCs) with PPP in Frame Relay encapsulation. The PPP over Frame Relay feature is required to allow an end-to-end PPP connection to be established over a Frame Relay network. This feature enables remote users using PPP protocol to access their corporate network over a Frame Relay connection.


RFC 1973 and Cisco Implementation of PPP over Frame Relay

RFC 1661 defines the standard PPP specifications, whereas a separate RFC document, RFC 1973, describes a standard method for transporting PPP over a Frame Relay VC connection. Cisco's implementation of the PPP over Frame Relay feature is based on the RFC 1973 specifications. A Cisco router supporting the PPP over Frame Relay feature is able to establish an end-to-end PPP session over an active Frame Relay PVC.

NOTE

Note that Cisco's implementation of RFC 1973 to support PPP over Frame Relay is essential to its support of other PPP-related advanced Frame Relay features, such as Link Fragmentation and Interleaving (LFI). For example, LFI depends on the setup of PPP multilink bundles. LFI is discussed and explained in Chapter 20, "Link Fragmentation and Interleaving (LFI) for Frame Relay Virtual Circuits."

PPP over Frame Relay Development

In 1998, Cisco developed the PPP over Frame Relay feature to supplement its ISDN Digital Subscriber Line (IDSL) solutions for the emerging xDSL (any DSL) market. DSL is a key access technology that offers affordable and high-speed "last mile" access over a low bandwidth line (such as a telephone line) to connect remote customer premises to the service provider network. In turn, the service provider network is connected to the customer's corporate office over a Frame Relay network. The PPP protocol is used to transport the customers' IP traffic between the remote premises and the corporate network. PPP over Frame Relay allows an end-to-end PPP connection to be established between the customer premises equipment (CPE) and the corporate gateway router.

Examples of typical applications that use the PPP over Frame Relay feature are illustrated in Figure 10-1. The next section covers a brief introduction to the IDSL access technology and the Cisco 90i Channel Unit card for transporting IDSL and PPP over Frame Relay.

Figure 10-1. PPP over Frame Relay Application

Cisco 90i IDSL Channel Unit

The Cisco 90i IDSL Channel Unit is a circuit card that is commonly installed in a standard D4 channel bank to provide ISDN access to subscribers. The PPP over Frame Relay feature was developed initially to complement the Cisco 90i product by enabling a Cisco router to act as a home gateway router in the service provider's network. Using the Cisco 90i installations, the service provider routers can handle PPP connections over a Frame Relay PVC, thereby allowing the remote end users to access the corporate office network.

NOTE

IDSL is a cross between ISDN and xDSL. IDSL uses a single wire pair to transmit full-duplex data at the rate of 128 kbps for a maximum distance range of 15,000 to 18,000 feet. IDSL uses the ISDN 2B1Q line code to enable transparent operation through the ISDN "U" interface. Essentially, IDSL is a leased-line ISDN Basic Rate Interface (BRI). In the ISDN 2B1Q definition, 2B1Q represents "2 Binary 1 Quaternary," which is an encoding scheme providing 2 bits per baud, 80k baud per second, and 160 kbps transfer rate. 2B1Q is the most common signaling method for ISDN U interfaces. "B" refers to an ISDN Bearer or B channel and it transports user data. Each B channel is typically 56 kbps or 64 kbps and normally two B channels are available on an ISDN BRI interface.

The "D" in ISDN 2B1D refers to the Signaling D channel, which is used to carry signaling information between a router and an ISDN switch. The D channel usually has a capacity of 16 kbps. Therefore, the aggregate bandwidth of ISDN 2B1D can be up to 144 kbps. Both IDSL and ISDN BRI use the same 2B1Q line modulation.

The Cisco 90i IDSL Channel Unit is part of Cisco's xDSL solutions. The Cisco 90i uses a D4 channel unit that is compatible with existing D4 channel banks with standard common equipment. The Cisco 90i Channel Unit can be used to convert the D4 channel bank digital group from a time-division multiplexing (TDM) unit into a high-performance Frame Relay multiplexer that can support up to four IDSL users running at speeds between 56 and 144 kbps. Each of the four users has access to the full bandwidth on a statistically multiplexed basis, and each user interface supports a standard twisted-pair 2B1Q loop up to a distance of 18,000 feet (5486.4 m).

The Cisco 90i requires a dedicated leased-line ISDN because it does not support switched or dialup ISDN connections. The subscribers' CPE devices, such as the Cisco 700 series routers, can be configured to connect to the Cisco 90i Channel Unit using PPP over IDSL. The PPP packets received by the Cisco 90i are in turn encapsulated in Frame Relay frames and transported over the Frame Relay network to the destination gateway router compliant with RFC 1973. An end-to-end PPP session carrying the users' IP traffic is established between the CPE and the gateway router.

Figure 10-2 shows the use of PPP over Frame Relay with IDSL together with the Cisco 90i Channel Unit card.

Figure 10-2. PPP over Frame Relay Using the Cisco 90i

[View full size image]

As illustrated in Figure 10-2, the Cisco 90i Channel Unit uses PPP over Frame Relay encapsulation to place PPP traffic from the subscriber into a Frame Relay frame and, similarly, extract PPP traffic from the Frame Relay network that is destined for the subscriber. An end-to-end PPP session is maintained between the subscriber and the corporate gateway router.

Information on the Cisco 90i and the Cisco 700 series CPE routers can be found on Cisco Connection Online (CCO): http://www.cisco.com/en/US/products/hw/iad/ps397/ps399/index.html.


PPP over Frame Relay Frame Format

RFC 1973 (PPP in Frame Relay) defines a Frame Relay frame format to encapsulate a PPP encapsulated packet in a Frame Relay frame. Based on RFC 1973, PPP uses Frame Relay as a framing mechanism. The Frame Relay frame format outlined in RFC 1973 closely resembles the Frame Relay frame format defined in RFC 1490 and RFC 2427 (Multiprotocol Interconnect over Frame Relay). Figure 10-3 shows a close comparison between the RFC 1973 PPP over Frame Relay frame format and the RFC 1490/RFC 2427 Frame Relay frame format. RFC 1490 can be found at http://www.faqs.org/rfcs/rfc1490.html, and RFC 2427 can be found at http://www.faqs.org/rfcs/rfc2427.html.

Figure 10-3. PPP over Frame Relay Frame Format

NOTE

The Cisco implementation of the PPP over Frame Relay feature is based closely on the specifications outlined in RFC 1973. The full specifications of RFC 1973 can be found at http://www.faqs.org/rfcs/rfc1973.html.

Table 10-1 explains the respective fields in the PPP over Frame Relay format in Figure 10-2.

Table 10-1. PPP over Frame Relay Fields

Flag

A 1-byte delimiter that identifies the beginning or end of a frame.

Q.922 address

A 2-byte field that indicates the Frame Relay DLCI.

Control

A 1-byte field that calls for transmission of user data. PPP over Frame Relay uses the value of 0x03.

NLPID

A 1-byte field that identifies the network layer protocol ID the Frame is carrying. For PPP over Frame Relay, the value 0xCF uniquely identifies a PPP packet that follows after the Frame Relay header.

PPP protocol header

This 2-byte field identifies the PPP packet type.

The PPP over Frame Relay frame format consists of the 2-byte Q.922 DLCI address combined with a UI control byte (0x03) and a Network Layer Protocol ID (NLPID) byte. The value of 0xCF in the NLPID byte indicates that the PPP encapsulation follows inside the Frame Relay frame.

NOTE

The PPP over Frame Relay feature is supported on Cisco IOS release 11.3 for c7500, c7200, c4000, and c2500 platforms. The 12.0T Release added support for c1600, c2600, and c3600 platforms. PPP over Frame Relay is not supported on switched virtual circuit (SVC) on all Cisco platforms.

A Cisco router configured to set up a PPP session over a Frame Relay circuit verifies that the VC is in an ACTIVE state before establishing the connection. Once the PPP connection is established over a Frame Relay VC, the Frame Relay VC acts as the physical layer transport for PPP. IP information is carried sequentially by the PPP encapsulation over Frame Relay.

NOTE

A Frame Relay VC that is configured to transport PPP sessions can coexist with other Frame Relay VCs using different Frame Relay encapsulation methods, such as Cisco or RFC 1490/RFC 2427. In other words, it is possible to configure a serial interface on a Cisco router for normal IP data transport using Cisco or RFC 1490/RFC 2427 encapsulation on a Frame Relay DLCI, and then use the same interface for transporting PPP sessions using RFC 1973 on a different Frame Relay DLCI. A Frame Relay DLCI that is set up to use either Cisco or RFC 1490/RFC 2427 encapsulations is configured to transport IP over Frame Relay, whereas a Frame Relay DLCI using RFC 1973 encapsulation carries only PPP sessions. Multiple PPP-in-Frame Relay circuits can exist on the same Frame Relay link.

PPP over Frame Relay is configured on a Cisco router using virtual access interfaces cloned from a virtual template interface.

Virtual Template Interfaces and Virtual Access Interfaces

A virtual template interface is a logical interface or entity that can exist on a Cisco router. The virtual template interface involves configuration for a serial interface, but it is not tied to any physical interface. The virtual template is applied dynamically only as needed.

Virtual access interfaces are not directly configurable, but they are cloned from virtual template interfaces. Virtual access interfaces are created, configured dynamically, and then freed from the memory when they are no longer needed. Each virtual access interface requires the same amount of memory as a serial interface. Virtual template interfaces are associated with the virtual access interfaces using the virtual-template keyword.

NOTE

The maximum number of virtual interfaces supported on a Cisco router is platform dependent. Typically, a Cisco router can support up to 25 virtual template interfaces and a maximum of 300 virtual interfaces. Consult your Cisco router platform configuration guide for the maximum number of virtual templates and interfaces supported.

Configuring Virtual Template Interfaces

To configure a virtual template interface on a Cisco router, perform the following configuration tasks, beginning in the global configuration mode:

Step 1. | In the global configuration mode, create a virtual template interface using the interface virtual-template number global configuration command. This creates the virtual template interface with the specified number.
Step 2. | Enter the interface configuration mode of the virtual template interface and enable PPP encapsulation using encapsulation ppp.
Step 3. | Enable IP addressing on the virtual template interface without assigning a specific IP address using the ip unnumbered interface-type/number interface configuration command. Using ip unnumbered saves IP addresses.
Step 4. | Alternatively, an IP address pool can be used to assign IP addresses, or an IP address can be assigned directly to the virtual template interface.
Step 5. | (optional) You can enable other PPP configuration commands on the virtual template interface. An example is PPP authentication.

NOTE

Note that dialer commands cannot be configured on virtual template interfaces.

Example 10-1 shows a configuration example of creating a virtual template interface on a Cisco router. In this example, the ip unnumbered interface command is used to enable IP processing on the virtual template interface without assigning it an explicit IP address. Using ip unnumbered allows conservation of network and address space. The no ip directed-broadcast command is enabled by default. It drops all directed broadcast packets sent to the subnet broadcast address.

Example 10-1. Configuration Example of a Virtual Template Interface
interface loopback0
 ip address 172.16.1.1 255.255.255.252
 !
interface Virtual-Template1
 ip unnumbered Loopback0
 no ip directed-broadcast

 ppp authentication chap

To apply the virtual template interface and configure PPP over Frame Relay on a Cisco router, perform the following configuration tasks, beginning in the global configuration mode:

Step 1. | Go into the interface configuration mode of the main interface on which you want to configure PPP over Frame Relay. Frame Relay encapsulation must be enabled on the specified main interface with the encapsulation frame-relay interface configuration command.
Step 2. | Configure the Frame Relay physical interface with the PVC. Apply a virtual template with PPP encapsulation to the DLCI to which it will apply. This is achieved using the frame-relay interface-dlci dlci [ppp virtual-template-name-string] command.

The sample in Example 10-2 demonstrates a PPP over Frame Relay configuration whereby DLCI 101 over subinterface serial 3/0.1 is associated with virtual template 1.

Example 10-2. Configuration Example of PPP over Frame Relay Applied to DLCI 101
interface serial 3/0
  no ip address
  encapsulation frame-relay
  !
interface serial 3/0.1 point-to-point
  frame-relay interface-dlci 101 ppp virtual-template1
  !
interface Virtual-Template1
  ip unnumbered loopback0
ppp authentication chap
!
interface loopback 0
ip address 172.16.1.1 255.255.255.252


Monitoring PPP over Frame Relay

The PPP over Frame Relay feature is configured between two Cisco routers, as shown in Figure 10-4. This figure is used to explain the show and debug commands for PPP over Frame Relay.

Figure 10-4. PPP over Frame Relay Configuration Between Two Routers

Example 10-3 shows the configuration files of routers R1 and R2.

Example 10-3. Running Configuration of R1 and R2
! R1

<output omitted>
interface Virtual-Template1
 ip address 192.168.1.2 255.255.255.0
 !
interface Serial1
 no ip address
 encapsulation frame-relay
!
interface Serial1.1 point-to-point
 frame-relay interface-dlci 101 ppp Virtual-Template1

! R2

<output omitted>
frame-relay switching
!
interface Virtual-Template1
 ip address 192.168.1.1 255.255.255.0
!
interface Serial1
 no ip address
 encapsulation frame-relay
 clockrate 64000
 frame-relay intf-type dce
!
interface Serial1.1 point-to-point
 frame-relay interface-dlci 101 ppp Virtual-Template1

The show frame-relay pvc global EXEC command can be used to display statistics of the Frame Relay PVC on the configured Frame Relay interfaces. Example 10-4 shows the status of the Frame Relay DLCI 101 under the point-to-point subinterface configured in Example 10-3. The output in Example 10-4 indicates that the Frame Relay PVC is bound to virtual access interface 1, cloned from the virtual template interface 1.

Example 10-4. Sample Output of show frame-relay pvc Command of DLCI 101
[View full width]
R1#show frame-relay pvc 101

PVC Statistics for interface Serial1 (Frame Relay DTE)

DLCI = 101, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial1.1

input pkts 50            output pkts 46           in bytes 2067
out bytes 1387           dropped pkts 0           in pkts dropped 0
out pkts dropped 0                out bytes dropped 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 2         out bcast bytes 582
pvc create time 00:03:37, last time pvc status changed 00:03:37Bound to Virtual-Access1
  (up, cloned from Virtual-Template1)

The debug ppp negotiation command can be used to observe the PPP negotiation process between the PPP peers when the routers attempt to set up a PPP session. An example is shown in Example 10-5.

Example 10-5. Sample Output of debug ppp negotiation Command on R1
PPP:
  PPP protocol negotiation debugging is on
csidtw8#
*Mar  2 00:20:23.669: Vi1 LCP: I CONFREQ [Open] id 34 len 10
*Mar  2 00:20:23.673: Vi1 LCP:    MagicNumber 0x054CD717 (0x0506054CD717)
*Mar  2 00:20:23.677: Vi1 IPCP: State is Closed
*Mar  2 00:20:23.677: Vi1 PPP: Phase is TERMINATING [0 sess, 0 load]
*Mar  2 00:20:23.681: Vi1 PPP: Phase is ESTABLISHING [0 sess, 0 load]
*Mar  2 00:20:23.685: Vi1 LCP: O CONFREQ [Open] id 6 len 10
*Mar  2 00:20:23.689: Vi1 LCP:    MagicNumber 0xE55765B9 (0x0506E55765B9)
*Mar  2 00:20:23.693: Vi1 LCP: O CONFACK [Open] id 34 len 10
*Mar  2 00:20:23.697: Vi1 LCP:    MagicNumber 0x054CD717 (0x0506054CD717)
*Mar  2 00:20:23.701: Vi1 LCP: I CONFACK [ACKsent] id 6 len 10
*Mar  2 00:20:23.705: Vi1 LCP:    MagicNumber 0xE55765B9 (0x0506E55765B9)
*Mar  2 00:20:23.705: Vi1 LCP: State is Open
*Mar  2 00:20:23.709: Vi1 PPP: Phase is UP [0 sess, 0 load]
*Mar  2 00:20:23.713: Vi1 IPCP: O CONFREQ [Closed] id 6 len 10
*Mar  2 00:20:23.717: Vi1 IPCP:    Address 192.168.1.2 (0x0306C0A80102)
*Mar  2 00:20:23.721: Vi1 IPCP: Remove route to 192.168.1.1
*Mar  2 00:20:23.729: Vi1 IPCP: I CONFREQ [REQsent] id 3 len 10
*Mar  2 00:20:23.733: Vi1 IPCP:    Address 192.168.1.1 (0x0306C0A80101)
*Mar  2 00:20:23.737: Vi1 IPCP: O CONFACK [REQsent] id 3 len 10
*Mar  2 00:20:23.741: Vi1 IPCP:    Address 192.168.1.1 (0x0306C0A80101)
*Mar  2 00:20:23.745: Vi1 IPCP: I CONFACK [ACKsent] id 6 len 10
*Mar  2 00:20:23.749: Vi1 IPCP:    Address 192.168.1.2 (0x0306C0A80102)
*Mar  2 00:20:23.749: Vi1 IPCP: State is Open
*Mar  2 00:20:23.757: Vi1 IPCP: Install route to 192.168.1.1

In the debug ppp negotiation output in Example 10-5, observe PPP session negotiation messages being exchanged between the peer routers. Both the LCP and the NCP must be negotiated properly before a PPP session can be set up. In the debug output, the phases "LCP: State is Open" and "PPP: Phase is UP" indicate that the physical layer is working and LCP is properly establishing a connection between the peers. The NCP uses IP Control Protocol (IPCP) to set up and manage IP over the PPP session. The PPP negotiation process on R1 completes by installing a route to R2's virtual access interface (192.168.1.1 is cloned from virtual template interface 1 on R2).

The PPP authentication features are added to the R1 and R2 configurations in Example 10-3. The username/password and ppp authentication chap commands are set up on both R1 and R2, as shown in Example 10-6. Note that both username and password are case-sensitive.

Example 10-6. Adding CHAP Authentication to PPP over Frame Relay
! R1

<output omitted>
username R2 password 0 cisco
!
interface Virtual-Template1
 ip address 192.168.1.2 255.255.255.0
 ppp authentication chap
 !
interface Serial1
 no ip address
 encapsulation frame-relay
!
interface Serial1.1 point-to-point
 frame-relay interface-dlci 101 ppp Virtual-Template1

! R2

<output omitted>
username R1 password 0 cisco
!
frame-relay switching
!
interface Virtual-Template1
 ip address 192.168.1.1 255.255.255.0
 no peer default ip address
 ppp authentication chap
!
interface Serial1
 no ip address
 encapsulation frame-relay
 clockrate 64000
 frame-relay intf-type dce
!
interface Serial1.1 point-to-point
 frame-relay interface-dlci 101 ppp Virtual-Template1

The debug ppp authentication command can be used to display or troubleshoot the PPP CHAP or PAP authentication process between the peer routers, as shown in Example 10-7.

Example 10-7. Sample Output of debug ppp authentication at Router R1
*May 29 11:44:22.889: Vi1 PPP: Treating connection as a dedicated line
*May 29 11:44:22.909: Vi1 CHAP: O CHALLENGE id 6 len 28 from "R1"
*May 29 11:44:22.945: Vi1 CHAP: I CHALLENGE id 6 len 28 from "R2"
*May 29 11:44:22.949: Vi1 CHAP: O RESPONSE id 6 len 28 from "R1"
*May 29 11:44:22.953: Vi1 CHAP: I RESPONSE id 6 len 28 from "R2"
*May 29 11:44:22.957: Vi1 CHAP: O SUCCESS id 6 len 4
*May 29 11:44:22.993: Vi1 CHAP: I SUCCESS id 6 len 4

PPP CHAP implements a three-way handshake process between two authenticating routers. Each side sends out a hash of its username and password instead of transmitting them across insecurely in clear text, as in the PAP case. Referring to the debug ppp authentication output displayed at router R1 in Example 10-7, routers R1 and R2 are involved in a two-way authentication. Both the calling (R2) and the called (R1) parties send out a CHALLENGE message to authenticate each other. Each party replies with a response containing a value calculated using a one-way hash function. Then each router checks the response against its own calculation of the expected hash value. If the response received matches the calculated hash value, the authentication is successful.

The debug frame-relay ppp command can be used to display error messages for link states and LMI status changes for PPP over Frame Relay sessions. Two examples are given in Example 10-8 and 10-9.

Example 10-8. Sample Output of debug frame-relay ppp When PPP over Frame Relay Is Working Properly
*May 29 11:48:17.509: FR-PPP: process on Virtual-Access1, #out-pkts=497
*May 29 11:48:19.509: FR-PPP: process on Virtual-Access1, #out-pkts=498
*May 29 11:48:21.509: FR-PPP: process on Virtual-Access1, #out-pkts=499
*May 29 11:48:23.509: FR-PPP: process on Virtual-Access1, #out-pkts=500
*May 29 11:48:25.509: FR-PPP: process on Virtual-Access1, #out-pkts=501
*May 29 11:48:27.509: FR-PPP: process on Virtual-Access1, #out-pkts=502
*May 29 11:48:28.917: FR-PPP: process on Virtual-Access1, #out-pkts=503

Example 10-9. Sample Output of debug frame-relay ppp When PPP over Frame Relay Failed
*May 29 11:50:41.661: FR-PPP: encaps failed for FR VC 101 on Serial1 down
*May 29 11:50:50.105: FR-PPP: input- Serial1 vc or va down, pak dropped


Summary

This chapter introduced readers to Cisco's implementation of the PPP over Frame Relay feature, based on the specifications defined in RFC 1973 (PPP in Frame Relay). Establishing a PPP session over a Frame Relay VC allows an end-to-end PPP session to be set up and maintained between two Frame Relay peers using RFC 1973. IP information is carried inside PPP packets, which are encapsulated in Frame Relay frames for transport over a Frame Relay VC. The PPP over Frame Relay feature is configured and maintained on Cisco routers with a virtual interface known as virtual access interface, which is cloned from a user-configured virtual template interface.

This chapter covered the configuration tasks and Cisco IOS commands necessary to establish a PPP session between two routers over a Frame Relay VC. Furthermore, this chapter explained the Cisco IOS show and debug commands for maintaining and troubleshooting PPP over Frame Relay on a Cisco router.

This chapter highlighted several optional PPP features, such as authentication and multilink PPP. Both PPP authentication and multilink PPP are supported with PPP over Frame Relay. The Multilink PPP over Frame Relay feature is explained separately in Chapter 14, "Multilink Frame Relay (FRF.16)."

The next chapter covers the use of the Frame Relay SVC feature on Cisco devices.


Review Questions

1: | How do Frame Relay encapsulations using RFC 1490/RFC 2427 and RFC 1973 compare?
2: | How do a Frame Relay DLCI configured to use RFC 1490/RFC 2427 and a Frame Relay DLCI configured with RFC 1973 compare?
3: | What value in the NLPID field indicates that a PPP packet is carried inside the frame?
4: | What are the virtual template interface configurations used for in setting up PPP over Frame Relay?
5: | What protocol in PPP negotiates the authentication process between two peer routers?
6: | What protocol in PPP negotiates the network layer protocol transported by the PPP session?


References

  • Cisco 90i IDSL Customer Premises Equipment: http://www.cisco.com/en/US/products/hw/iad/ps397/ps399/index.html

  • RFC 1490 Multiprotocol Interconnect over Frame Relay: http://www.faqs.org/rfcs/rfc1490.html

  • RFC 1661 The Point-to-Point Protocol: http://www.faqs.org/rfcs/rfc1661.html

  • RFC 1973 PPP in Frame Relay: http://www.faqs.org/rfcs/rfc1973.html

  • RFC 2427 Multiprotocol Interconnect over Frame Relay: http://www.faqs.org/rfcs/rfc2427.html


Case Study: Verifying PPP over Frame Relay

The network diagram in Figure 10-5 is used to verify the PPP over Frame Relay feature by establishing multiple Frame Relay PVC connections that mix normal Frame Relay circuits with PPP over Frame Relay. In this setup, R2 acts as a router that connects a local LAN segment to the corporate gateway router (R3) via PPP over Frame Relay. R3 allocates an IP address to R1 from a local pool that is configured. The use of the Cisco 90i Channel Unit is not demonstrated here.

Figure 10-5. Network Diagram to Illustrate PPP over Frame Relay

A client computer is used to simulate a remote subscriber attempting to connect into the corporate gateway router (R3). The router R1 is used to send routing protocol updates over the Frame Relay network to R3 on a different DLCI but configured under the same Frame Relay physical interface. This verifies that PPP over Frame Relay can coexist with other Frame Relay encapsulations.

The configuration files of R1, R2, and R3 are shown in Example 10-10.

Example 10-10. The show running of R1, R2, and R3 in Figure 10-5
! R1

<output omitted>
interface Ethernet0
 ip address 172.16.1.1 255.255.255.0
 !
router rip
 passive-interface Ethernet0
 network 172.16.0.0
 neighbor 172.16.1.2

! R2

<output omitted>
username R2 password 0 cisco
username R3 password 0 cisco
!
interface Ethernet0
 ip address 172.16.1.2 255.255.255.0
 !
interface Virtual-Template1
 ip address negotiated
 ppp authentication chap
!
interface Serial1
 no ip address
 encapsulation frame-relay
!
interface Serial1.1 point-to-point
 frame-relay interface-dlci 101 ppp Virtual-Template1
!
interface Serial1.2 point-to-point
 ip address 192.168.1.1 255.255.255.252
 frame-relay interface-dlci 100
!
router rip
 passive-interface Ethernet0
 network 172.16.0.0
 network 192.168.1.0
 neighbor 172.16.1.1

! R3

<output omitted>
username R1 password 0 cisco
username R2 password 0 cisco
!
frame-relay switching
!
!
interface Loopback0
 ip address 200.200.200.1 255.255.255.0
 !
interface Virtual-Template1
 ip unnumbered Loopback0
 peer default ip address pool local_pool
 ppp authentication chap
!
interface Serial1
 no ip address
 encapsulation frame-relay
 clockrate 64000
 frame-relay intf-type dce
!
interface Serial1.1 point-to-point
 frame-relay interface-dlci 101 ppp Virtual-Template1
!
interface Serial1.2 point-to-point
 ip address 192.168.1.2 255.255.255.252
 frame-relay interface-dlci 100
 !
router rip
 network 192.168.1.0
!
ip local pool local_pool 200.200.200.2 200.200.200.200

The show frame-relay pvc command is used at R2 and R3 to verify both Frame Relay PVC connections are active, as shown in Example 10-11.

Example 10-11. show frame-relay pvc Output of R2 and R3 in Figure 10-5
R1#show frame-relay pvc

PVC Statistics for interface Serial1 (Frame Relay DTE)

              Active     Inactive      Deleted       Static
  Local          2            0            0            0
  Switched       0            0            0            0
  Unused         0            0            0            0

DLCI = 100, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial1.2

  input pkts 87            output pkts 90           in bytes 14522
  out bytes 10971          dropped pkts 0           in pkts dropped 0
  out pkts dropped 0                out bytes dropped 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 65        out bcast bytes 8575
  pvc create time 00:37:54, last time pvc status changed 00:17:11

DLCI = 101, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial1.1

  input pkts 515           output pkts 694          in bytes 19846
  out bytes 23924          dropped pkts 0           in pkts dropped 0
  out pkts dropped 0                out bytes dropped 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 41        out bcast bytes 11668
  pvc create time 00:37:56, last time pvc status changed 00:17:13
Bound to Virtual-Access1 (up, cloned from Virtual-Template1)

R2#show frame-relay pvc

PVC Statistics for interface Serial1 (Frame Relay DCE)

              Active     Inactive      Deleted       Static
  Local          2            0            0            0
  Switched       0            0            0            0
  Unused         0            0            0            0

DLCI = 100, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial1.2

  input pkts 135           output pkts 126          in bytes 21052
  out bytes 23967          dropped pkts 0           in pkts dropped 0
  out pkts dropped 0                out bytes dropped 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 88        out bcast bytes 20592
  pvc create time 01:05:46, last time pvc status changed 00:15:02

DLCI = 101, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial1.1

  input pkts 1405          output pkts 2039         in bytes 59575
  out bytes 69286          dropped pkts 0           in pkts dropped 0
  out pkts dropped 0                out bytes dropped 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 104       out bcast bytes 31622
  pvc create time 01:47:21, last time pvc status changed 00:15:04
Bound to Virtual-Access1 (up, cloned from Virtual-Template1)

As shown in Example 10-11, both DLCI 100 and DLCI 101 (bound to PPP over Frame Relay) are now in the ACTIVE state. Both Frame Relay PVC connections are configured under the same physical interface. This verifies that PPP over Frame Relay can coexist with Cisco or RFC 1490 encapsulations.

Example 10-12 displays the output of the debug ppp authentication command at router R2, which indicates a successful authentication between routers R2 and R3.

Example 10-12. The debug ppp authentication at Router R1 Indicates that PPP CHAP Authentication Is Successful
3d18h: Vi1 CHAP: O CHALLENGE id 24 len 28 from "R2"
3d18h: Vi1 CHAP: I CHALLENGE id 24 len 28 from "R3"
3d18h: Vi1 CHAP: O RESPONSE id 24 len 28 from "R2"
3d18h: Vi1 CHAP: I RESPONSE id 24 len 28 from "R3"
3d18h: Vi1 CHAP: O SUCCESS id 24 len 4
3d18h: Vi1 CHAP: I SUCCESS id 24 len 4

In the next example, the password on router R2 is deliberately changed to simulate a negative password authentication process between routers R2 and R3. The output of the debug ppp authentication command illustrated in Example 10-13 reveals the failed authentication and errors.

Example 10-13. The debug ppp authentication at Router R1 Indicates PPP CHAP Authentication Failure
3d18h: %LINK-3-UPDOWN: Interface Virtual-Access1, changed state to up
3d18h: Vi1 PPP: Treating connection as a dedicated line
3d18h: Vi1 CHAP: O CHALLENGE id 25 len 28 from "R2"
3d18h: Vi1 CHAP: I CHALLENGE id 25 len 28 from "R3"
3d18h: Vi1 CHAP: O RESPONSE id 25 len 28 from "R2"
3d18h: Vi1 CHAP: I RESPONSE id 25 len 28 from "R3"
3d18h: Vi1 CHAP: O FAILURE id 25 len 25 msg is "MD/DES compare failed"

After restoring the correct password on router R2, the PPP session is reestablished over the Frame Relay connection. This can be verified by sending traffic across Frame Relay DLCI 100 and 101 from R2, as illustrated in Example 10-14.

Example 10-14. The Ping from R2 to R3 over DLCI 100 and DLCI 101 Is Successful
R2#ping 192.168.1.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 32/32/32 ms
R2#ping 200.200.200.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 200.200.200.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 28/31/32 ms

In Example 10-14, take notice that on the 192.168.1.0/30 subnet, IP traffic is transported directly over Frame Relay DLCI 100 using Cisco or RFC 1490/RFC 2427 encapsulation. On the other hand, IP traffic is carried inside PPP packets, which are transported over Frame Relay DLCI 101 by encapsulating the PPP packets within Frame Relay frames.

Example 10-14 shows that router R2 has established network layer connectivity to the loopback interface (200.200.200.1/24) on router R3. After the PPP session is established between routers R2 and R3, R2 is allocated an IP address from the local_pool address pool configured on router R3. Example 10-15 shows the show interface virtual-access number privileged EXEC command is used to verify the IP address allocated to R2's virtual access interface from the local_pool address pool that is set up on router R1. In addition, the show interface virtual-access number command can be used to display the virtual access interface configurations to confirm a good clone of the virtual template.

In this setup, the routers are configured to perform PPP CHAP authentication using a locally configured username and password. On a production network, an AAA Radius server can be added to the network to perform remote Radius PPP authentication. The Radius user files on the Radius server can be set up to allocate an IP address to the PPP peer after a successful authentication.

Example 10-15. The show interface Output of the Virtual Access Interface on R2
R2#sh inter virtual-access 1
Virtual-Access1 is up, line protocol is up
  Hardware is Virtual Access interface
  Internet address is 200.200.200.2/32
  MTU 1500 bytes, BW 100000 Kbit, DLY 100000 usec,
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation PPP, loopback not set
  Keepalive set (10 sec)
  DTR is pulsed for 5 seconds on reset
  LCP Open
  Open: IPCP
  Bound to Serial1.1 DLCI 101, Cloned from Virtual-Template1
  Last input 00:00:44, output never, output hang never
  Last clearing of "show interface" counters 00:42:51
  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
  Queueing strategy: fifo
  Output queue :0/40 (size/max)
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
     515 packets input, 9174 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
     517 packets output, 8474 bytes, 0 underruns
     0 output errors, 0 collisions, 0 interface resets
     0 output buffer failures, 0 output buffers swapped out
0 carrier transitions

RIP is configured on all three routers to verify that routing protocol updates can be propagated over the Frame Relay PVC connections. After DLCI 101 is brought up, the network statement 200.200.200.0 is added to the RIP routing process on R2 and R3. Example 10-16 shows that R3 can reach the Ethernet segment on R1 via two equal cost paths: one via DLCI 100 running conventional Frame Relay PVC, and the second via DLCI 101 running PPP over Frame Relay.

Example 10-16. The IP Routing Tables of R1, R2, and R3
R1#show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
       i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
       * - candidate default, U - per-user static route, o - ODR
       P - periodic downloaded static route

Gateway of last resort is not set

R    200.200.200.0/24 [120/1] via 172.16.1.2, 00:00:13, Ethernet0
     172.16.0.0/24 is subnetted, 1 subnets
C       172.16.1.0 is directly connected, Ethernet0
R    192.168.1.0/24 [120/1] via 172.16.1.2, 00:00:13, Ethernet0

R2##show ip route
1d01h: %SYS-5-CONFIG_I: Configured from console by console
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
       i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
       * - candidate default, U - per-user static route, o - ODR
       P - periodic downloaded static route

Gateway of last resort is not set

     200.200.200.0/32 is subnetted, 2 subnets
C       200.200.200.1 is directly connected, Virtual-Access1
C       200.200.200.2 is directly connected, Virtual-Access1
     172.16.0.0/24 is subnetted, 1 subnets
C       172.16.1.0 is directly connected, Ethernet0
     192.168.1.0/30 is subnetted, 1 subnets
C       192.168.1.0 is directly connected, Serial1.2

R3#show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
       i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
       * - candidate default, U - per-user static route, o - ODR
       P - periodic downloaded static route

Gateway of last resort is not set

     200.200.200.0/24 is variably subnetted, 2 subnets, 2 masks
C       200.200.200.0/24 is directly connected, Loopback0
C       200.200.200.2/32 is directly connected, Virtual-Access1
R    172.16.0.0/16 [120/1] via 192.168.1.1, 00:00:08, Serial1.2
                   [120/1] via 200.200.200.2, 00:00:08, Virtual-Access1
     192.168.1.0/30 is subnetted, 1 subnets
C       192.168.1.0 is directly connected, Serial1.2
     150.1.0.0/24 is subnetted, 1 subnets
C       150.1.28.0 is directly connected, Ethernet1

The client PC on the Ethernet segment is configured with a default route to R1. A ping from the PC to the loopback address on R3 is successful, as shown in Example 10-17.

Example 10-17. A Standard Ping from the Client PC to R3 Is Successful
Microsoft Windows 2000 [Version 5.00.2195]
 Copyright 1985-2000 Microsoft Corp.

C:\>ping 200.200.200.1

Pinging 200.200.200.1 with 32 bytes of data:

Reply from 200.200.200.1: bytes=32 time=180ms TTL=254
Reply from 200.200.200.1: bytes=32 time=170ms TTL=254
Reply from 200.200.200.1: bytes=32 time=170ms TTL=254
Reply from 200.200.200.1: bytes=32 time=171ms TTL=254

Ping statistics for 200.200.200.1:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 170ms, Maximum =  180ms, Average =  172ms

NOTE

The return path traffic from R3 is load-balanced between the two equal cost paths to 172.16.1.0/24.

The case study in this section shows the successful establishment of a PPP session over a Frame Relay network between two Cisco routers. Moreover, a PPP over Frame Relay session between two routers can be configured to optionally support authentication. The case study also verified that a Frame Relay VC configured to support PPP over Frame Relay can coexist with other Frame Relay VCs using the Cisco or RFC 1490/RFC 2427 encapsulations.


Chapter 11. Frame Relay Switched Virtual Circuit (SVC)

This chapter presents an overview of Frame Relay switched virtual circuits (SVCs) in Frame Relay networks. The chapter begins with an introduction of Frame Relay SVC, focusing on configuring a Cisco router as a User to Network Interface (UNI) device for enabling Frame Relay SVC service. This chapter discusses the main differences between Frame Relay Permanent Virtual Circuits (PVCs) and SVCs and illustrates how Frame Relay PVCs and SVCs complement each other in a modern Frame Relay network. This chapter explains the configuration tasks required to configure Frame Relay SVC on a Cisco router. Basic configuration examples of Frame Relay SVC on a Cisco router are given. Finally, the relevant Cisco IOS show commands for monitoring and maintaining Frame Relay SVC on a Cisco router are presented.

The topics and questions that this chapter addresses include the following:

  • Overview of Frame Relay SVCs

  • Benefits of Frame Relay SVCs

  • Frame Relay SVC operation

  • Cisco's implementation of Frame Relay SVC

  • Configuring Frame Relay SVCs on a Cisco router

  • Maintaining and troubleshooting Frame Relay SVC

After completing this chapter, readers will recognize the flexibility, scalability, and benefits that Frame Relay SVCs offer over Frame Relay PVCs. Readers will become familiar with the operation and application of Frame Relay SVC. Readers will learn the tasks and Cisco IOS commands required to configure a Frame Relay SVC on a Cisco router. Finally, readers will know how to use the relevant Cisco IOS show commands to monitor and maintain Frame Relay SVC configurations on a Cisco router.


Introduction to Frame Relay SVC

Frame Relay SVC is defined in the early development of Frame Relay. However, Frame Relay SVCs were not widely implemented by the majority of Frame Relay service providers largely because of its complexities and low user demands. Nevertheless, Frame Relay SVC provides any-to-any network connectivity and can offer potential cost savings, flexibility, and scalability to Frame Relay users. The following sections discuss the general differences between Frame Relay PVCs and SVCs, the applications and benefits of SVCs, and the basic operation of Frame Relay SVCs. This chapter also discusses Cisco's implementation of Frame Relay SVC and explains the Cisco IOS configuration and troubleshooting tasks.

Comparing SVC to PVC

Both Frame Relay SVC and PVC provide similar services, transporting users' traffic between two different locations of a Frame Relay network. Fundamental differences between PVCs and SVCs affect the type of virtual circuit network that operators and their customers choose.

Generally, Frame Relay PVCs are virtual circuit connections set up permanently between two locations. In contrast, Frame Relay SVCs are virtual circuit connections between two locations that are set up and torn down based on the duration data is being sent onto the network. Frame Relay PVCs require a one-time initial setup between the router and the Frame Relay switch. On the other hand, Frame Relay SVCs are set up or torn down based on traffic patterns and demand. Frame Relay PVCs are well suited for partially meshed networks designed to imitate leased line topologies. Frame Relay SVCs serve better on Frame Relay networks that require any-to-any connectivity and dynamic VC setup.


Current Issues

Today, a majority of virtual circuits deployed in service providers' Frame Relay networks are PVCs. The use of a Frame Relay PVC between two different locations requires the Frame Relay network operator to perform a one-time initial setup of the virtual circuit between the router and the Frame Relay switch. On a hub-and-spoke topology, Frame Relay PVCs are popularly used to mimic physical leased line connections to provide full direct access between all sites. On a partially meshed Frame Relay network with n sites, and assuming each site is connected to the Frame Relay network, n(n-1)/2 Frame Relay PVCs must be provisioned on the Frame Relay switch to provide fully meshed connectivity between n sites. Hence, using Frame Relay PVCs is cumbersome and costly if many sites on the Frame Relay network only require any-to-any connectivity.

Frame Relay PVC serves well for certain types of user application and traffic patterns. For instance, when the traffic between sites is consistent and recurring, PVC serves well because PVC does not entail the overhead of constant circuit setup and tear down. However, in situations where the traffic pattern is not consistent and is more sporadic in nature, PVC can constitute a waste of resources if the allocated bandwidth is not fully utilized. In these situations, the use of SVC becomes a more cost-effective alternative to the traditional PVC by offering a flexible, bandwidth-on-demand solution. SVC also lifts the restriction imposed by the need to configure fully meshed Frame Relay PVC circuits for enabling any-to-any connectivity.


Solutions for Current Issues

Frame Relay SVCs are virtual circuits that allow Frame Relay users to access a Frame Relay network on a call-by-call basis. Frame Relay PVCs, by contrast, are fixed paths. Users are billed for the dedicated virtual circuit connection even though their circuits might be largely underutilized. Using Frame Relay SVCs, the virtual circuits are established only for the duration while data is being sent or upon demand from the user to send data. Hence, Frame Relay SVC users are billed according to the amount of service or usage.

The bandwidth required by the SVC is also negotiated and provisioned during the call setup. After a user has completed transmission, the service provider tears down the SVC to prevent the circuit from becoming idle. After the call is completed, the user is usually billed only for the duration of the call. This is very much like an ISDN dial-on-demand circuit, except that SVC offers greater flexibility by allowing user specified parameters (such as bandwidth) to be negotiated during the call setup.

In all, SVC provides a bandwidth advantage and monetary savings to the low-volume user. On Enterprise Frame Relay networks which observe high volume of traffic during their peak operating hours, on-demand SVC can be provisioned to complement the existing dedicated PVCs by providing the extra bandwidth. Therefore, the flexibility associated with Frame Relay SVC makes it an attractive solution to customers.

Any-to-Any Connectivity Between Remote Sites

Frame Relay SVC offers the user on-demand, any-to-any connectivity between geographically dispersed sites. Compared with Frame Relay PVC, SVC does not require the network resources or bandwidth to be allocated permanently for every site that needs to be connected. For PVC, the network resources are permanently assigned to the circuit regardless of whether the user is sending traffic over it. To achieve the same any-to-any connection state with PVC, the Frame Relay network has to be fully meshed.

For service providers, a Frame Relay network using SVCs is comparatively less expensive to build and maintain than its PVC counterparts.

Bandwidth-on-Demand and Backup for PVC

Using Frame Relay SVC, service providers can offer Frame Relay customers on-demand services. Frame Relay users and service providers can negotiate the committed information rate (CIR) and burst size during call negotiation. The bandwidth allocation can be carefully planned based on calculated or estimated usage by the network applications and network conditions. For example, Frame Relay users can request for a higher bandwidth SVC to be negotiated when delay-sensitive traffic, such as video, is scheduled for transmission. On the contrary, a low-bandwidth SVC connection would be able to satisfy the requirements of non-mission-critical traffic, such as data services FTP or Telnet.

SVC allows the capability for CIR configuration on a call-by-call basis. Because many service providers price their Frame Relay service on CIR usage, customers can request lower CIR circuits for non-critical applications. This presents more flexibility in managing network resources and helps to lower cost. Quality of Service (QoS) elements can be specified on call-by-call basis to request network resources.

For regular high-volume traffic users that require dedicated Frame Relay PVCs between their main sites, SVC can be used to provide a reliable and effective backup for the main connection. User traffic can dynamically failover to the SVC when a network outage occurs on the main connection. For instance, in a hybrid private/public network, the private network can be backed up over the public network using SVC on an on-demand basis. Figure 11-1 illustrates an example of this setup.

Figure 11-1. Using SVC to Back Up PVC Sites in a Frame Relay Network

Comparing SVC and PVC Usage for Different Network Applications

As mentioned, using Frame Relay PVC is most efficient and cost-effective when the network requires consistent bandwidth demand and the users' traffic pattern on the network is very predictable. An example of a service where Frame Relay PVC is the most suitable is LAN-to-LAN connectivity between remote sites. In general, Frame Relay PVC is well suited for Frame Relay sites that have medium to high traffic volume with a consistent and recurring pattern. On the contrary, Frame Relay SVC should be used on networks whose traffic is sporadic and the traffic pattern unpredictable. As illustrated in Figure 11-1, Frame Relay SVC is useful for providing any-to-any connectivity between remote sites and for backing up a dedicated PVC connection. Another factor that affects some Frame Relay users' choice is the ease of configuration. Generally, configuring Frame Relay SVC is a more complex task than setting up a Frame Relay PVC. The next section addresses Frame Relay SVC operation.


Setting Up an SVC Operation

For both Frame Relay PVC and SVC, access to a Frame Relay network is generally made through private leased lines at various speeds ranging from 56 kbps to 45 Mbps. From the Frame Relay user's perspective, the leased line terminates at the Frame Relay service providers' Frame Relay switch.

When SVC is employed, the service provider does not provision a dedicated virtual circuit between the end points of the connection. A SVC through a Frame Relay network is set up to the destination endpoint only when the user requires the connection.

NOTE

The service provider's Frame Relay switch must be capable of supporting SVC operation before you can use SVC. Check with your local service provider regarding support for Frame Relay SVC. In order to access the Frame Relay network, a leased line or dedicated line must exist between the customer's router and the service provider's Frame Relay switch. This is commonly known as the local loop or the "last mile" access. Take note that Frame Relay SVC must be supported at both ends of the SVC connection.

SVC operation and signaling requires that the data link layer be set up and running ITU-T Q.922 Link Access Procedures to Frame (LAPF) mode bearer services. When both the physical line and the line protocol of the interface are in the UP state, Layer 2 is established immediately after SVC support is enabled on the interface. When the SVCs are configured and demand for a connection path occurs, the Q.933 signaling sequence is started. Data transfer can proceed once the SVC is set up.

Q.922 provides a reliable link layer for Q.933 operation. All Q.933 call control information is transmitted over the reserved DLCI 0. DLCI 0 is also used for the management protocols specified in ANSI T1.617 Annex D or Q.933 Annex A.

SVC Signaling Operation

This section describes the SVC signaling operation. The connection control messages are shown in Table 11-1.

Table 11-1. Frame Mode Connection Setup and Control Messages

Control Message

Purpose

SETUP

Sent by the calling user to the network and by the network to the called user to initiate a call.

CALL PROCEEDING

Sent by the called user to the network and by the network to the calling user to indicate that the requested call establishment has been initiated and that no more call establishment will be accepted.

CONNECT

Sent by the called user to the network and by the network to the calling user to indicate call acceptance by the called user.

DISCONNECT

Sent by the user to request the network to clear the call or is sent by the network to indicate that the call is cleared.

RELEASE

Sent by the user or the network to indicate that the equipment sending the message has disconnected the call and intends to release the associated DLCI and the call reference. Indicates that the receiving equipment should release the DLCI and prepare to release the call reference after sending RELEASE COMPLETE.

RELEASE COMPLETE

Sent by the user or the network to indicate that the equipment sending the message has released the call reference. The receiving equipment shall then release the call reference.

STATUS

Sent by the user or the network in response to a STATUS ENQUIRY message or at any time during a call to report error condition.

STATUS ENQUIRY

Sent by the user or the network to solicit a STATUS message from the peer Layer 3 entity. Sending a STATUS message in response to a STATUS ENQUIRY is mandatory.

SVC User Call States

The SVC specifications outline a Layer 3 call state for SVC call setup. The SVC user call states are described in Table 11-2.

Table 11-2. SVC User-Side Call States

Call States

Description

Null State

No call exists.

Call Initiated

User has requested call establishment from the network.

Outgoing Call Proceeding

User has received confirmation from the network that the network has received call information necessary to effect call establishment.

Call Present

User has received a call establishment request but has not responded yet.

Incoming Call Proceeding

An incoming call when the user has sent acknowledgement that the user has received all call information necessary to effect call establishment.

Active

Called side: Network indicates that the calling user has been awarded the call. Calling Side: When the remote user answers the call.

Disconnect Request

User has requested the network to clear the end-to-end call and is waiting for response.

Disconnect Indication

The user has received an invitation to disconnect because the network has disconnected the connection.

Release Request

The user has requested the network to release and is waiting for a response.

SVC Addressing PlanE.164 and X.121

Most Frame Relay SVC devices support both the X.121 and E.164 addressing schemes. Both the ITU-T E.164 and the X.121 numbering plans are applicable for Frame Relay SVC. Cisco routers configured as a Frame Relay SVC access device support both X.121 and E.164. The type of numbering plan used depends largely on the service provider's choice.

The E.164 addressing scheme is an international standard defined by the International Telecommunication Union-Telecommunication Standardization Sector (ITU-T). The E.164 addresses are usually represented in decimal format and can be up to 15 digits long. The E.164 addressing scheme is widely supported by Frame Relay networks. The complete list of E.164 country codes can be found at Defense Information Systems Agency (DISA):http://www-comm.itsi.disa.mil/itu/e164.html#top.

X.121 addresses are up to 14 digits long and are also usually represented in decimal format. The first four digits of the X.121 address indicate the globally unique data network ID code. For example, 310 through 316 represents the United States. The remaining 8 to 10 or 11 digits represent the network terminal number normally assigned by a service provider. Many service providers providing X.25 services employ X.121 addressing. Using X.121 addressing schemes, service providers are also able to migrate easily from X.25 networks to Frame Relay networks. The list of known global X.121 data network ID codes can be found at DISA's web site at http://www-comm.itsi.disa.mil/itu/dnic.html.

Each SVC device on the Frame Relay network must be assigned a unique E.164 or X.121 address by the service provider.


Cisco Implementation of Frame Relay SVC

Frame Relay SVC is supported on all Cisco routers running Cisco IOS Release 11.2 or later. Frame Relay SVC is supported on serial and HSSI interfaces. On all Cisco routers, Frame Relay SVC is only supported in the data terminal equipment (DTE) mode. The Cisco Frame Relay switching feature currently does not support SVC. A dedicated commercial Frame Relay switch capable of deploying SVC is required to support Frame Relay SVC in the Data Circuit-terminating Equipment (DCE) mode.

On Cisco routers, the Frame Relay SVC feature (DTE mode) supports the following functionalities:

  • Any-to-any Frame Relay connectivity between multiple sites at various connection speeds, such as 56 kbps, 128 kbps, 384 kbps, or T1.

  • Static and dynamic routings are supported over Frame Relay SVC. Frame Relay Inverse Address Resolution Protocol (ARP) is also supported.

  • Ability to support multiprotocol traffic over a SVC. RFC 1490 encapsulation is supported.

  • Facility to keep track of idle time on a SVC and an extension to tear down the SVC upon reaching a configured idle-time value.

  • Access lists can be configured for selective SVC setup.

  • Configurable SVC physical characteristics so that the CIR can be manipulated.

  • Ability to provide backup to a Frame Relay PVC using SVC.


SVC Configuration Tasks

The Cisco IOS software only supports the Frame Relay SVC feature on a Cisco router as a DTE device. The Frame Relay switching enhancement feature currently does not support SVC switching functionalities. Presently, only PVC switching is supported. There are commercial Frame Relay switches by different vendors that support Frame Relay SVC switching. Check with your service provider about SVC support when ordering a Frame Relay SVC circuit.

Frame Relay SVC is supported on both physical and logical subinterfaces on a Cisco router. To configure a Cisco router to establish a SVC connection request from the Frame Relay network, perform the configuration steps outlined below:

Step 1. | Configure Frame Relay encapsulation on the main interface with the encapsulation frame-relay interface configuration command. To use SVC on a subinterface, create a Frame Relay point-to-point or multipoint subinterface.
Step 2. | Configure a Frame Relay map class using the frame-relay map-class map-class-name global configuration command.
Step 3. | (optional) In the Frame Relay map-class configuration mode, configure fancy queuing and enable BECN feedback to throttle the output rate on the SVC for the map class.
Step 4. | Configure a Frame Relay map group with E.164 or X.121 addressing scheme using map-list global configuration command.
Step 5. | Associate the map class with static protocol address maps under the map-list configuration mode.
Step 6. | (optional) Configure the LAPF parameters in the interface configuration mode.
Step 7. | Associate the configured map list with the Frame Relay main interface or subinterface using the map-group interface configuration command.

To enable SVC operation on a Cisco router, SVC must be enabled at the main interface level with the frame-relay svc command. Once SVC is enabled, it is dynamically enabled on all subinterfaces configured under that main interface. The reserved DLCI 0 is set up for the interface, and all SVC control messages are exchanged from the main interface on the DLCI 0.

The configuration examples for enabling Frame Relay SVC on the physical main interface or Frame Relay subinterface are shown in Example 11-1 and Example 11-2, respectively.

Example 11-1. Configuration Example for Enabling Frame Relay SVC on the Main Physical Interface
Router#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router(config)#interface serial4/2
Router(config-if)#encapsulation frame-relay
Router(config-if)#map-group svc_group
Router(config-if)#frame-relay svc
Router(config-if)#

Example 11-2. Configuration Example for Enabling Frame Relay SVC on a Point-to-Point Subinterface
Router#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router(config)#interface serial4/2.1 point-to-point
Router(config-subif)#map-group svc_group
Router(config-subif)#

NOTE

To enable Frame Relay SVC on a Frame Relay subinterface, the frame-relay svc interface configuration command must be enabled on the physical interface. Then the map-group interface configuration command is applied to the subinterface directly instead of to the physical interface.

The Frame Relay map-class configuration command, frame-relay idle-timer seconds, has a function very similar to the dialer idle-timeout interface command used for configuring dial-on-demand routing (DDR) interfaces. This command indicates the amount of seconds to wait before tearing down the SVC connection after no activity has been detected. The default timeout is 120 seconds.

Table 11-3 shows the list of Frame Relay map-class configuration options that can be used to specify the characteristics of the SVC connection. These parameters are applied to the SVC during call setup time when a user requests a connection.

Table 11-3. Frame Relay Map Class Configuration Options for SVC

Map-Class Configuration Commands

Purpose

frame-relay custom-queue-list list-number

Specifies a custom queue list to be used with the map class associated with an SVC. A custom queue list for custom queuing has to be defined by the user.

frame-relay priority-group list-number

Specifies a priority queue list to be used with the map class associated with an SVC. A priority list for priority queuing has to be defined by the user.

frame-relay adaptive-shaping [becn | foresight]

Enables adaptive traffic shaping on the SVC using either BECN or ForeSight mode.

frame-relay cir {in|out} bps

Specifies the inbound or outbound CIR in bits per second.

frame-relay mincir {in|out} bps

Specifies the inbound or outbound minimum CIR in bits per second. By default, the mincir is half of the configured CIR value.

frame-relay bc {in|out} bits

Specifies the inbound or outbound committed burst in bits.

frame-relay be {in|out} bits

Specifies the inbound or outbound excess burst (Be) in bits.

To configure a Frame Relay SVC map group with either E.164 or X.121 addressing, use the map-list map-group-name source-addr {e164 | x121} source-address dest-addr {e164 | x121} destination-address global configuration command. The map-group-name specified in the map-list command associates the map group configured under the physical or subinterface with the addresses defined in the map list.

Example 11-3 shows a configuration example of the map-list command. In the example, the destination network layer address of the remote host, 192.168.1.1, is associated with a preconfigured Frame Relay map class named svc_class. This is done using the protocol protocol-address class map-class-name [ietf] [broadcast [trigger]] map-list configuration command. The ietf keyword is used if RFC 1490 encapsulation is to be used. The broadcast keyword indicates broadcast traffic to be carried by the SVC, and the trigger keyword allows broadcast traffic to activate the SVC connection.

In Example 11-3, the SVC connection between the local router and the remote host is set up with the parameters configured in the svc_class map class.

Example 11-3. Configuration Example for Configuring a Map List for Enabling SVC for a Frame Relay Interface
Router#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router(config)#map-list svc_group source-addr e164 123456 dest-addr  e164 654321
Router(config-map-list)#ip 192.168.1.1 class svc_class

Configuring Frame Relay LAPF Parameters

The Frame Relay LAPF parameters can be fine-tuned using LAPF configuration commands. These commands are required when default settings need to be changed in order for the Frame Relay SVC DTE device to work well with the Frame Relay switch. In most situations, these parameters do not need to be changed. Consult with your service provider before making changes to the LAPF default settings.

The [no] frame-relay lapf frmr interface configuration command can be used to configure the router to not send Frame Reject frame (frmr) at the LAPF Frame Reject procedure. By default, frmr is sent at the SVC interface.

Example 11-4 shows the entire list of LAPF parameters that can be changed at the interface level.

Example 11-4. Configuration Options for LAPF Parameters on a Frame Relay Interface
Router#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router (config)#interface Serial2/0
Router (config-if)#frame-relay lapf ?
  frmr  set LAPF option on sending FRMR at Frame Reject
  k     set LAPF k value, the max. of outstanding I frames to be sent
  n200  set LAPF N200, the max. retransmission count
  n201  set LAPF N201, the max. length of Information field in I frame
  t200  set LAPF T200, the retransmission time period in 1/10 seconds
  t203  set LAPF T203, the idle timer period in seconds


Monitoring Frame Relay SVC

Example 11-5 shows the status of the show frame-relay map command at R1, after the Frame Relay SVC configurations are completed. In the show frame-relay map output shown in Example 11-5, the output shows that the Frame Relay connection is an SVC circuit and broadcast traffic is allowed to be sent over the SVC. IETF encapsulation is used.

Example 11-5. show frame-relay map Output
R1#show frame-relay map
Serial4/0.1 (up): point-to-point dlci, dlci 100(0x64,0x1840), broadcast, IETF, SVC
status defined, active

Example 11-6 shows the output of the show interface serial slot/number command at router R1.

Example 11-6. show interface Output
R1#show interface Serial4/0
Serial4/0 is up, line protocol is up
  Hardware is M4T
  MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec,
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation FRAME-RELAY, crc 16, loopback not set
  Keepalive set (10 sec)
  LMI enq sent  228, LMI stat recvd 228, 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 enabled, LAPF state up
  Broadcast queue 0/64, broadcasts sent/dropped 37/0, interface broadcasts 0
  Last input 00:00:08, output 00:00:08, output hang never
  Last clearing of "show interface" counters 00:41:07
  Input queue: 0/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/1/256 (active/max active/max total)
     Reserved Conversations 0/0 (allocated/max allocated)
     Available Bandwidth 1158 kilobits/sec
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
     392 packets input, 16707 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
     393 packets output, 16706 bytes, 0 underruns
     0 output errors, 0 collisions, 1 interface resets
     0 output buffer failures, 0 output buffers swapped out
     1 carrier transitions     DCD=up  DSR=up  DTR=up  RTS=up  CTS=up

The show interface global EXEC command can be used to display the interface-specific statistics of the Frame Relay interface. In the example shown, observe that DLCI 0 is used as the management DLCI, Frame Relay SVC mode is enabled, and LAPF state is operational. The Frame Relay interface is operating as a DTE device.

The next two commands are useful for verifying the statistics of the SVC connection as well as for diagnosing the state of the SVC connection. Call parameters negotiated during the SVC setup can be observed using the show frame-relay svc maplist map-list-name global EXEC command. The show frame-relay lapf command can be used to troubleshoot the state of the SVC connection. The show frame-relay lapf command can be useful for troubleshooting problems when errors are encountered during call setup with the Frame Relay switch. Example 11-7 illustrates the output of the show frame-relay svc maplist map-list-name command at router R1.

Example 11-7. Sample Output of show frame-relay svc maplist
R1#show frame-relay svc maplist cisco_svc
Map List : cisco_svc
Address : Source E164 123456 <----> Destination E164 654321

Protocol : ip 172.16.1.2                                Encapsulation : IETF
Call Reference : 8001, Call Destination Side    DLCI : 100

FMIF (Frame Mode Information Field Size), bytes
Configured : In = 1500, Out = 1500
Negotiated : In = 1500, Out = 1500

CIR (Committed Information Rate), bits/sec
Configured : In = 64000,        Out = 64000,
Negotiated : In = 64000,        Out = 64000,

Minimum Acceptable CIR, bits/sec
Configured : In = 32000,        Out = 32000,
Negotiated : In = 32000,        Out = 32000,

Bc (Committed Burst Size), bits
Configured : In = 8000, Out = 8000,
Negotiated : In = 8000, Out = 8000,

Be (Excess Burst Size), bits
Configured : In = 8000, Out = 8000,
Negotiated : In = 8000, Out = 8000,

Example 11-8 shows the output of the show frame-relay lapf command at router R1. The show frame-relay lapf command displays the status of the internals of Frame Relay Layer 2 (LAPF) for SVCs.

Example 11-8. Sample Output of show frame-relay lapf
R1#show frame-relay lapf

Interface = Serial4/0 (up),  LAPF state = MULTIPLE_FRAME_ESTABLISHED (up)
SVC enabled,  Last link down cause = unsolic. DM 1,  #link-reset = 1
T200 = 1.5 sec.,  T203 = 30 sec.,  N200 = 3,  k = 7,  N201 = 260
I-frame xmt = 2,  I-frame rcv = 1,  I-frame reXmt = 0
I xmt dropped = 0,  I rcv dropped = 0,  Rcv pak dropped = 0
RR xmt = 127,  RR rcv = 128,  RNR xmt = 0,  RNR rcv = 0
REJ xmt = 0,  REJ rcv = 0,  FRMR xmt = 0,  FRMR rcv = 0
DM xmt = 0,  DM rcv = 1,  DISC xmt = 0,  DISC rcv = 0
SABME xmt = 1,  SABME rcv = 1,  UA xmt = 1,  UA rcv = 0
V(S) = 2,  V(A) = 2,  V(R) = 1,  N(S) = 0,  N(R) = 2
Xmt FRMR at Frame Rejec

If the LAPF state is in a state other than MULTIPLE_FRAME_ESTABLISHED, it's likely that a problem has occurred during call negotiation and setup with the Frame Relay switch. If a problem exists, you can reset the interface or reload the router. If the condition persists, contact your Frame Relay carrier.

Finally, you can verify the connection of the SVC by sending packets over it from R1 to R2 using the Cisco router ping utility. The results are shown in Example 11-9.

Example 11-9. Verifying Connectivity Between R1 and R2 by Performing a Ping over the SVC Connection
R1#show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
       i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
       * - candidate default, U - per-user static route, o - ODR
       P - periodic downloaded static route

Gateway of last resort is not set

     172.16.0.0/24 is subnetted, 1 subnets
C       172.16.1.0 is directly connected, Serial4/0.1

R1#ping
Protocol [ip]:
Target IP address: 172.16.1.2
Repeat count [5]: 100
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 100, 100-byte ICMP Echos to 172.16.1.2, timeout is 2 seconds:
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Success rate is 100 percent (100/100), round-trip min/avg/max = 28/28/32 ms

The same results are seen on the remote side at the R2 router.


Summary

This chapter covered the major functionalities of the Frame Relay SVC feature. Although Frame Relay SVC is not as widely popular and implemented as its PVC counterpart, Frame Relay SVC does have many advantages. Frame Relay SVC offers more resiliencies to accommodate a certain group of users. For example, SVC offers bandwidth-on-demand and thus provides significant cost savings for Frame Relay users with sporadic or low volume traffic patterns. Moreover, Frame Relay SVC allows any-to-any connectivity between multiple Frame Relay locations without requiring users to provision fixed-cost dedicated Frame Relay PVCs between the sites. For high-volume traffic users, Frame Relay SVC is useful for providing a reliable and redundant backup circuit for the primary Frame Relay PVC. This negates the effects of downtime during failures to the main PVC connection.

This chapter discussed the signaling operation of Frame Relay SVC setup and explained the different SVC addressing plans currently supported. This chapter also covered Cisco's implementation of Frame Relay SVC.

The configuration tasks and Cisco IOS show commands for monitoring and maintaining Frame Relay SVCs are explained in the case study involving a Frame Relay SVC network.

The next chapter covers the Cisco IOS feature for transporting X.25 protocol over Frame Relay network (Annex G feature).


Review Questions

1: | What are the main differences between Frame Relay SVC and PVC implementations?
2: | What are the common considerations for network designers when implementing Frame Relay SVCs?
3: | How is call setup for Frame Relay SVC negotiated between Frame Relay DTE and the Frame Relay switch?
4: | How are the characteristics and parameters (values such as committed access rate) of a SVC connection set up on a Cisco router during call request?
5: | What are the types of addressing schemes for SVC supported by Cisco routers, and what are their differences?
6: | What is the Cisco IOS configuration command to define the idle or inactive period for Frame Relay SVC connection to remain up when there is no active traffic?


References

  • The Frame Relay Forum SVC User-to-Network Interface (UNI) Implementation Agreement FRF 4.1: http://www.mplsforum.org/frame/Approved/FRF.4/FRF4.1.final.pdf

  • ITU-T Q.921, ISDN UNI Data Link Layer Specification: http://www.itu.int

  • ITU-T Q.931, ISDN Signaling Specification for Frame Mode Bearer Service:http://www.itu.int


Case Study: Frame Relay SVC Network Between Two Remote Offices

This section presents a case study of a Frame Relay SVC network, entailing full configuration examples on Cisco routers. Many of the configuration commands introduced in this chapter are configured and demonstrated in this case study. Figure 11-2 shows the network diagram of the setup used for this case study.

Figure 11-2. Routers Connected via a Frame Relay Network to Demonstrate SVC Setup

A STDX 3000 Cascade switch is used in the lab setup for the configuration examples in this section. The examples are focused mainly on the configuration of a Cisco router as a Frame Relay DTE device on the Cisco IOS software. A SVC connection is set up between the Cisco routers via the Frame Relay switch.

NOTE

The configuration model used in these examples is similar to production networks set up with commercial Frame Relay switches capable of supporting SVCs.

Figure 11-2 shows the Frame Relay SVC network setup used for the configuration examples in this section.

In the network diagram depicted in Figure 11-2, both routers R1 and R2 are configured as Frame Relay access devices (DTEs) establishing a SVC connection to the service provider Frame Relay switch. In Figure 11-2, the service provider's Frame Relay switches are fully meshed to minimize network downtimes due to failure of any core switch. Example 11-10 shows the basic configuration setup of R1 and R2 in Figure 11-2. The values of the CIR, Bc, and Be parameters for setting up a Frame Relay SVC are usually supplied by the Frame Relay SVC service provider.

Example 11-10. Basic Configurations of R1 and R2 in Figure 11-2
! R1
<output omitted>
interface Serial4/0
 no ip address
 encapsulation frame-relay
 frame-relay lmi-type ansi
 frame-relay svc
!
interface Serial4/0.1 point-to-point
 ip address 172.16.1.1 255.255.255.0
 map-group cisco_svc
!
map-list cisco_svc source-addr E164 123456 dest-addr E164 654321
 ip 172.16.1.2 class r1 broadcast ietf
!
map-class frame-relay r1
 frame-relay cir 64000
 frame-relay bc 8000
 frame-relay be 8000
 frame-relay mincir 32000
 frame-relay holdq 32
 frame-relay idle-timer 90
 no frame-relay adaptive-shaping

! R2

<output omitted>

interface Serial4/0
 no ip address
 encapsulation frame-relay
 frame-relay lmi-type ansi
 frame-relay svc
!
interface Serial4/0.1 point-to-point
 ip address 172.16.1.2 255.255.255.0
 map-group cisco_svc
!
map-list cisco_svc source-addr E164 654321 dest-addr E164 123456
 ip 172.16.1.1 class r2 broadcast ietf
!
map-class frame-relay r2
 frame-relay cir 64000
 frame-relay bc 8000
 frame-relay be 8000
 frame-relay mincir 32000
 frame-relay holdq 32
 frame-relay idle-timer 90
 no frame-relay adaptive-shaping

NOTE

This configuration example only focuses on Cisco IOS configuration commands on the Cisco router operating as the DTE device. The configurations for the commercial Frame Relay switch used in the lab are not shown.

In the configuration example shown in Example 11-10, note that the frame-relay svc command is enabled under the main interfaces of both R1 and R2. This command enables Frame Relay SVC for all subinterfaces configured under the physical interface. The Frame Relay subinterfaces configured on both R1 and R2 are associated with the map list named cisco_svc via the map-group map-list-name command. A meaningful map list should be used to identify the particular connection established.

The map-list global configuration mode defines the addressing or numbering plans assigned by the service provider. Both X.121 and E.164 addressing plans are supported by Cisco IOS. Observe that the destination E.164 address configured on R1 coincides with the source E.164 address configured at R2 and vice versa. This mapping must be configured correctly at the local peer in order to inform the Frame Relay switch of the destination peer with which it would like to connect. RFC 1490 encapsulation is also used, as shown in the ietf keyword.

Under the map-list configuration command mode, the remote destination's network layer address is mapped to a Frame Relay map class where the call parameters for the particular connection are defined. The switch negotiates the call setup using the parameters specified in the Frame Relay map class. In our example, the CIR, committed burst size, excess burst, minimum CIR, and the output hold queue are specified.

Finally, the frame-relay idle-timer command is used to reduce the idle time allowed on the SVC from the default 120 seconds to 90 seconds.


Chapter 12. X.25 over Frame Relay: Using the Annex G Feature

X.25 is a legacy WAN communication protocol established by the International Telecommunication Union-Telecommunication Standardization Sector (ITU-T) in the 1970s. Similar to Frame Relay, X.25 is designed to interconnect user devices and network devices across geographically dispersed areas. X.25 is designed to operate effectively over any transmission medium regardless of the quality of the line. The X.25 protocol has a built-in error recovery mechanism, which allows it to work over poor-quality transmission media.

This chapter discusses the functionalities of Annex G, a feature that allows X.25 protocol to be transported over a Frame Relay network. The Cisco IOS software supports the Annex G feature. Annex G allows X.25 data packets to be encapsulated in a Frame Relay frame for delivery over a Frame Relay network. This feature is useful for owners of legacy X.25 networks who want to migrate to newer technology, such as Frame Relay.

This chapter aims to provide an overview of the Annex G feature in the context of a Frame Relay environment. This chapter looks at the Annex G feature's special ability to allow service providers to migrate X.25 networks smoothly over to Frame Relay networks. This chapter introduces users to the basic configuration tasks and commands for configuring X.25 and the Annex G feature on a Cisco router. Readers will also find useful configuration examples of the Annex G feature used in a Frame Relay/X.25 network on Cisco routers.

An extensive study of the X.25 protocol is outside the scope of this book. It is assumed that the reader has at least some basic understanding of X.25 protocol and its terminologies. Please refer to Cisco Connection Online (CCO) for the full configuration guide on configuring X.25 protocol on Cisco devices (http://www.cisco.com/en/US/products/sw/iosswrel/ps1818/
products_configuration_guide_chapter09186a0080087858.html).

The topics and questions that this chapter addresses include the following:

  • Understanding the use of the Annex G feature for Frame Relay/X.25 Interworking

  • Configuring basic X.25 on a Cisco router

  • Overview of X.121 Addressing

  • Configuring the Annex G feature on a Cisco router

  • Monitoring and maintaining the Annex G feature on a Cisco router

After completing this chapter, readers will recognize the performance issues commonly associated with the legacy X.25 protocols. The need for a feature to migrate X.25 networks to the newer technologies such as Frame Relay, Asynchronous Transfer Mode (ATM), and IP will become apparent. Readers will be able to understand the operation of the Annex G feature to allow X.25 packets to be carried over a Frame Relay network. Then readers will learn how to perform the basic configuration tasks for setting up X.25 on a Cisco router. Finally, readers will be able to configure the Annex G feature on a Cisco router with Cisco IOS configuration commands and to maintain and troubleshoot Annex G configuration using Cisco IOS show and debug commands.


Current Issues

The X.25 protocol has a great deal of operating overhead because it is designed to support legacy data networks with a high error rate. The high error rate on the legacy network can be because of physical interference or poor line condition. Therefore, in most X.25 implementations, X.25 can only support data rates up to 64 kbps.

Frame Relay is designed to operate over a reliable and clean digital transmission medium. Frame Relay does not support the error correction functions in the X.25 protocol, and therefore, Frame Relay does not incur the operating overhead of X.25. Frame Relay eliminates much of the X.25 overhead because Frame Relay only supports an error checking function in its headers. It leaves the error correction and flow control functions to upper-layer protocols such as TCP/IP. Besides the ability to increase performance, Frame Relay has the ability to dynamically allocate bandwidth. Frame Relay has become a very cost-effective solution with improved network performance and response time. To some degree, Frame Relay has superceded X.25.

The use of X.25 protocol on network backbones is fast becoming obsolete. Modern networks are implementing newer technologies such as Frame Relay, ATM, and IP on their backbones. Nonetheless, X.25 is ubiquitous; the banking industry and parts of Europe and Asia still rely on X.25 networks. For network operators and customers who have considerable investments in X.25 networks and equipment, a feature to protect these investments, by allowing a gradual migration to newer technologies, is considered necessary. The basic issue is to allow X.25 traffic to be transported over other newer technologies, such as Frame Relay, which is seeing widespread popularity.

Figure 12-1 shows a network diagram illustrating an X.25 network interworking with a Frame Relay backbone. In the figure, PAD refers to Packet Assembly and Disassembly. User sessions are carried across an X.25 network using the PAD protocols defined by the ITU-T Recommendations X.3 and X.29.

Figure 12-1. X.25 over Frame Relay

Previous Page
Next Page


Solutions to Current Issues

Annex G is a migration strategy for X.25 to Frame Relay. The Annex G feature facilitates the migration from an X.25 backbone to a Frame Relay backbone by allowing the encapsulation of CCITT X.25/X.75 traffic within a Frame Relay connection. Annex G was initially developed to accommodate the many Cisco customers in certain parts of Europe and Asia where IP is not as common. In these regions, X.25 technology continues to be a very popular protocol. Today, many service providers still offer X.25 services over their public data networks (PDNs). There is also an increasing need for service providers to offer newer services as an alternative to X.25, such as Frame Relay. With Annex G, the process of transporting X.25 over Frame Relay has been simplified, by allowing direct X.25 encapsulation over a Frame Relay network.

The X.25 over TCP (XOT) feature, defined in RFC 1613, allows X.25 packets to be transported over a TCP/IP network rather than over a Link Access Procedure, Balanced (LAPB) link.

Annex G uses direct encapsulation as opposed to XOT, which uses TCP encapsulations. Annex G offers greater interoperability among different vendors and is supported by many Frame Relay equipment manufacturers.

NOTE

XOT is an X.25 feature and is not be covered in this text. Information and configuration examples on XOT can be found at http://www.cisco.com/en/US/tech/tk713/tk730/technologies_configuration_example09186a0080093c0e.shtml.


Annex G Feature

The Annex G function, commonly known as Frame Relay/X.25 Interworking, describes a procedure for encapsulating X.25 traffic within a Frame Relay ANSI T1.618 frame. ANSI T1.618 describes the core aspects of Frame Relay protocol for use with Frame Relay Bearer Service.

NOTE

The details of the Annex G or Frame Relay/X.25 Interworking procedures can be found in both the ANSI T1.617 Annex G and the CCITT Recommendation I.555 documents. The ANSI public web site is found at http://www.ansi.org, and the ITU public web site is located at http://www.itu.int/home/index.html.

Figure 12-2 shows a model of the Annex G Frame Relay/X.25 Interworking function. Two X.25 data terminal equipment (DTE) routers are connected over Frame Relay permanent virtual circuit (PVC) in a Frame Relay network. In this diagram, the Annex G function is implemented on a X.25 DTE device and also on a X.25 data circuit-terminating equipment (DCE) device. The Annex G function can be implemented on both DTE and DCE X.25 devices. The Frame Relay/X.25 Interworking function encapsulates and de-encapsulates the X.25 traffic in a Frame Relay ANSI T1.618 frame. It also provides termination for the LAPB node-to-node link layer protocol used for X.25. With Annex G, the X.25 traffic is "tunneled" through a Frame Relay network.

Figure 12-2. Model for Frame Relay/X.25 Interworking

LAPB is the data link layer protocol in X.25 protocol stack. It is responsible for ensuring reliable transport of data in an X.25 network. X.25PLP refers to the X.25 Packet Level Protocol, which is a network layer protocol responsible for network routing functions in the X.25 network.

Using Annex G, a stream of LAPB/X.25 packets is encapsulated and transmitted transparently over Frame Relay. The X.25 client data is encoded in an X.25 data packet in an LAPB frame. The LAPB frame and its payload are both encapsulated by the Frame Relay's DLCI header (2 to 4 bytes) and the 2 bytes of trailers that comprises of the cyclic redundancy check (CRC). The Annex G function can only support one upper-layer protocol (such as IP, IPX, and DECNET) for every single Frame Relay DLCI connection.

Cisco Implementation of Annex G

The Cisco implementation of the Annex G feature supports the Annex G specifications described in ANSI T1.617. It provides the following services:

  • Support of X.25 profiles

  • Multiple logical X.25 switched virtual circuits (SVCs) per Annex G link

  • X.25 switched and PAD services over Annex G

  • Modulo 8 or 128 packet sequence numbering

The Cisco Annex G feature uses X.25 profiles, which were created to streamline X.25 and LAPB configurations. X.25 profiles can contain existing X.25 and LAPB commands. Once created and named, X.25 profiles can be simultaneously associated with more than one DLCI connection by using the profile name.

The X.25 Layers 2 and 3 are transparently supported over Annex G. LAPB treats the Frame Relay network as an X.25 network link and passes all of the data and control messages over the Frame Relay network.

With modulo 8, the basic operating modulo is selected as the LAPB operating modulo. Modulo 128 specifies LAPB's extended mode.

When the Cisco Annex G feature is implemented in a Frame Relay/X.25 environment, it provides the following benefits and advantages to its users:

  • It allows transparent support of X.25 encapsulation over a Frame Relay network.

  • The X.25 profiles allow direct X.25 and LAPB configurations on a per-DLCI basis.

  • The X.25 profiles allow specification of X.25 and LAPB configurations without having to allocate hardware interface data block (IDB) information.

  • The X.25 profiles consist of bundled X.25 and LAPB commands, which eliminate the need to enter the same X.25 or LAPB commands for each DLCI configured.

  • It has low memory requirements; only the memory necessary to hold the X.25 or LAPB configuration data structure is required.

  • It offers multiple Annex G DLCIs per X.25 profile.

  • Both modulo 8 and 128 packet sequence numbering are supported.

Before you enable the Annex G feature on a Cisco router, note the following limitations and restrictions imposed on it. The following list outlines the restrictions that apply to Annex G configured on a Cisco router:

  • Annex G is supported only on Frame Relay physical interfaces. Frame Relay logical subinterfaces are not supported at this stage.

  • Annex G supports only Frame Relay PVC. Frame Relay SVC is not supported.

  • Each Frame Relay DLCI can be configured for only one Frame Relay service at a time. Hence, if the DLCI is using Annex G, it cannot be configured for another Frame Relay service.

  • Only X.25 SVC connections over Annex G are supported. X.25 PVC connections are not supported.

  • X.25 profiles do not support IP encapsulation.

Before X.25 Annex G can be configured on the serial interface of a Cisco router, the serial interface must be configured to process X.25 packets. The next section describes the basic configuration tasks required to enable X.25 on the serial interface of a Cisco router, including setting up X.25 encapsulation.


Basic X.25 Configuration Tasks on a Cisco Router

This section provides an overview of the configuration tasks and Cisco IOS commands required to enable X.25 processing on a serial interface of a Cisco router. This section also explains the configuration commands required to establish an X.25 PVC connection through an X.25 network. The Cisco IOS commands introduced in this section serve to familiarize readers with the basic X.25 configuration commands in the Cisco IOS software. Take note that you need at least a Cisco IP IOS image to support X.25 protocol on a Cisco router.

Configuring X.25 Encapsulation

To enable X.25 processing on a serial interface, you are required to explicitly configure X.25 encapsulation on a serial interface. Enabling X.25 encapsulation on the serial interface overrides the default High-Level Data Link Control (HDLC) encapsulation. To enable X.25 encapsulation on a serial interface, use the encapsulation x25 interface configuration command. The encapsulation x25 command allows the user to optionally specify the mode of operation and the encapsulation type to use on the X.25 interface. Your X.25 service provider normally specifies the additional settings you need to configure on your serial interface. The default mode of operation is dte and default encapsulation used is ietf. Airline X.25 (AX25), Blacker Front End (BFE), and Defense Data Network (DDN) are among the supported encapsulation options. These options must be explicitly specified if they are required by your provider.

In the examples shown in this section, the default operation mode (dte) and encapsulation type (ietf) are used. Example 12-1 shows the Cisco IOS configuration commands as well as the configuration options for configuring X.25 on a serial interface.

NOTE

Take note that X.25 is a non-broadcast multi-access (NBMA) protocol similar to Frame Relay and ATM. As such, an X.25 interface is susceptible to the issues related to split-horizon when configuring dynamic routing protocols on a Cisco router.

Example 12-1. Configuring X.25 Encapsulation on a Serial Interface
Router#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router(config)#interface serial4/0
Router(config-if)#encapsulation x25 ?
  ax25     Default to IATA's Airline X.25
  bfe      Blacker Front End attachment
  dce      DCE operation
  ddn      Defense Data Network attachment
  dte      DTE operation
  ietf     Default to IETF's RFC-1356 encapsulation
  profile  Use a defined X.25 profile configuration
  <cr>

Router(config-if)#encapsulation x25 dte ?
  ax25  Default to IATA's Airline X.25
  bfe   Blacker Front End attachment
  ddn   Defense Data Network attachment
  ietf  Default to IETF's RFC-1356 encapsulation
<cr>

Example 12-2 shows the output of the show interface serial command on a Cisco router after encapsulation x25 is configured on the serial interface 4/0 from the previous example. Take note that the serial interface is set up as an X.25 DTE interface.

Example 12-2. Output of the show interface serial Command after encapsulation x25 Is Configured
Router#show interface serial4/0
Serial4/0 is up, line protocol is up
  Hardware is M4T
  MTU 1500 bytes, BW 2048 Kbit, DLY 20000 usec,
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation X25, crc 16, loopback not set
  X.25 DTE, address <none>, state R1, modulo 8, timer 0
      Defaults: idle VC timeout 0
        cisco encapsulation
        input/output window sizes 2/2, packet sizes 128/128
      Timers: T20 180, T21 200, T22 180, T23 180
      Channels: Incoming-only none, Two-way 1-1024, Outgoing-only none
      RESTARTs 0/0 CALLs 0+0/0+0/0+0 DIAGs 0/0
  LAPB DTE, state CONNECT, modulo 8, k 7, N1 12056, N2 20
      T1 3000, T2 0, interface outage (partial T3) 0, T4 0
      VS 1, VR 1, tx NR 1, Remote VR 1, Retransmissions 0
      Queues: U/S frames 0, I frames 0, unack. 0, reTx 0
      IFRAMEs 1/1 RNRs 0/0 REJs 0/0 SABM/Es 1/0 FRMRs 0/0 DISCs 0/0
  Last input 00:34:22, output 00:19:12, output hang never
  Last clearing of "show interface" counters 00:19:12
  Queueing strategy: fifo
  Output queue 0/40, 0 drops; input queue 0/75, 0 drops
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
     3 packets input, 11 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
     2 packets output, 7 bytes, 0 underruns
     0 output errors, 0 collisions, 1 interface resets
     0 output buffer failures, 0 output buffers swapped out
     1 carrier transitions     DCD=up  DSR=up  DTR=up  RTS=up  CTS=up

X.25 PVC and SVC

The next step requires you to specify the range of virtual circuit numbers (VCNs) for X.25 operation. In X.25, multiple connections are maintained over a physical link between the DTE and DCE devices. These connections are known as virtual circuits or logical channels. Up to 4095 logical channels can be maintained by a X.25 network. The logical channel identifier (LCI) or VCN is used to identify individual circuits. In addition, X.25 defines a range of VCNs that are an important part of X.25 operation. There are four ranges used as follows:

  • PVC

  • Incoming-only circuits

  • Two-way circuits

  • Outgoing-only circuits

The definition and use of the PVC is obvious. The incoming-only, two-way, and outgoing-only ranges define the VCNs over which an SVC can be established. There are six X.25 commands that can be used to define the upper and lower limit of each of the three SVC ranges, as shown in Table 12-1.

Table 12-1. Setting the Parameters for an X.25 SVC Connection

Description

Command

Default Value

Set the lowest incoming-only circuit number.

X25 lic limit

0

Set the highest incoming-only circuit number.

X25 hic limit

0

Set the lowest two-way circuit number.

X25 ltc limit

1

Set the highest two-way circuit number.

X25 htc limit

1024 (serial)

Set the lowest outgoing-only circuit number.

X25 loc limit

0

Set the highest outgoing-only circuit number.

X25 hoc limit

0

For PVC, the circuit number assigned to it must be lower than the number assigned to a SVC circuit. The circuit numbers must match on both ends of the X.25 connection.

Understanding X.121 Addressing

When connecting a router to your service provider's X.25 network, you are required to set up the X.121 addressing on the interface. X.121 is an ITU-T recommendation for representing the numbering plans for International Data Numbers (IDNs). The numbering plan, or Data Network Identification Codes (DNICs), allows for a number of PDNs in a country, the identification of a country, and also a specific PDN within the country. A DNIC is comprised of four digits, whereby the first three digits represent the International Data Country Codes (DCCs) and the fourth digit may indicate up to 10 different networks within the country. For example, the list of numbers from 310 to 316 represents the X.121 Data Country Codes (DCC) for the United States. Singapore is represented by the DCC of 525.

Configuring X.25 Subinterfaces and X.121 to Network Layer Address Mapping

Both X.25 point-to-point and multipoint subinterfaces are supported on Cisco routers. Point-to-point subinterfaces only accept a single encapsulation command for a given protocol. Only one destination host for the protocol can be specified for a point-to-point subinterface. For physical interfaces or multipoint subinterfaces, one or more destination hosts can be configured. There is no restriction on the number of encapsulation commands that can be configured on a multipoint subinterface. When a routing process forwards a packet to a multipoint interface, the X.25 encapsulation process must be able to map the packet's destination address to a configured encapsulation command. Otherwise, the encapsulation fails and the packet is discarded.

After the interface has been configured, use the x25 pvc interface configuration command to establish an encapsulation PVC for the interface. Using the x25 pvc command is very similar to using the frame-relay interface-dlci command on a Frame Relay point-to-point subinterface. You can use the x25 map command to perform network layer address to local X.121 address mapping. Repeat the command to perform the mapping for each remote destination host. The x25 map is similar to the frame-relay map command on Frame Relay multipoint interfaces.

On X.25 serial interfaces, split horizon is enabled by default. This is contrary to Frame Relay, where split horizon is automatically disabled on the physical interfaces. Take note of this issue when configuring routing protocols on an X.25 network over a hub-and-spoke topology.

The basic configuration tasks for configuring X.25 on an interface are summed up in the following list. X.25 configuration tasks should be performed as listed below:

Step 1. | In the interface configuration mode, configure the serial interface for X.25 mode of operation and encapsulation with the encapsulation x25 [dte | dce] [[ddn | bfe] | [ietf]] command.
Step 2. | Set up the virtual circuit ranges using the commands listed in Table 12-1. The VCN you use should be assigned to you by your service provider.
Step 3. | Set up the X.121 addressing for your X.25 circuit on your X.25 serial interface. The X.121 address numbering used is dependent on your country region, and your X.25 service provider should assign it to you. Use the x25 address x.121-address interface configuration command to set up the assigned X.121 address.
Step 4. | If PVC is used, establish the PVC using the x25 pvc circuit protocol address x.121-address [option] command. Otherwise, set up the x.25 address mapping on the interface using the x25 map protocol address x.121-address [option] command. For both commands, multiple protocols and addresses can be specified in a single command.

The basic X.25 network illustrated in Figure 12-3 is used to demonstrate the X.25 configuration examples in this section. In Figure 12-3, for simplicity, two Cisco routers are connected with a back-to-back serial cable without connecting to any X.25 switch. Router R2, which is connected to the DCE end of the serial cable, acts as the X.25 DCE device. Its serial interface is configured with the clock rate command to supply clocking signals to the far end DTE. In addition, Figure 12-3 demonstrates that a Cisco router can be set up as a X.25 DCE device to perform similar functions as a traditional X.25 switch.

Figure 12-3. Basic Network Involving Two Cisco Routers Communicating Back-to-Back Via X.25

The configuration examples of R1 and R2 are shown in Example 12-3.

Example 12-3. Configuration Examples for Basic X.25
! R1

<text omitted>

ip routing
!
interface Serial0
 ip address 172.16.1.1 255.255.255.0
 encapsulation x25
 x25 address 123456
 x25 ltc 3
 x25 pvc 1 ip 172.16.1.2 654321

! R2

<test omitted>

ip routing
!
interface Serial0
 ip address 172.16.1.2 255.255.255.0
 encapsulation x25 dce
 x25 address 654321
 x25 ltc 3
 x25 pvc 1 ip 172.16.1.1 123456
 clockrate 64000

The show interface command can be used to verify the status and LAPB state of the interface. Example 12-4 demonstrates the sample outputs at both R1 and R2.

Example 12-4. Output of show interface Command at R1 and R2
R1#show interface serial0
Serial0 is up, line protocol is up
  Hardware is cxBus Serial
  Internet address is 172.16.1.1/24
  MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec,
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation X25, crc 16, loopback not set
  Restart-Delay is 0 secs
  X.25 DTE, address 123456, state R1, modulo 8, timer 0
      Defaults: idle VC timeout 0
        cisco encapsulation
        input/output window sizes 2/2, packet sizes 128/128
      Timers: T20 180, T21 200, T22 180, T23 180
      Channels: Incoming-only none, Two-way 3-1024, Outgoing-only none
      RESTARTs 1/0 CALLs 0+0/0+0/0+0 DIAGs 0/0
  LAPB DTE, state CONNECT, modulo 8, k 7, N1 12056, N2 20
      T1 3000, T2 0, interface outage (partial T3) 0, T4 0
      VS 6, VR 6, tx NR 6, Remote VR 6, Retransmissions 0
      Queues: U/S frames 0, I frames 0, unack. 0, reTx 0
      IFRAMEs 6/6 RNRs 0/0 REJs 0/0 SABM/Es 1/1 FRMRs 0/0 DISCs 0/0
  Last input 00:03:04, output 00:03:04, output hang never
  Last clearing of "show interface" counters 00:05:17
  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
  Queueing strategy: fifo
  Output queue: 0/40 (size/max)
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
     10 packets input, 540 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
     9 packets output, 538 bytes, 0 underruns
     0 output errors, 0 collisions, 1 interface resets
     0 output buffer failures, 0 output buffers swapped out
     1 carrier transitions
RTS up, CTS up, DTR up, DCD up, DSR up

R2#show interface serial0
Serial0 is up, line protocol is up
  Hardware is M8T-V.35
  Internet address is 172.16.1.2/24
  MTU 1500 bytes, BW 2048 Kbit, DLY 20000 usec,
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation X25, crc 16, loopback not set
  X.25 DCE, address 654321, state R1, modulo 8, timer 0
      Defaults: idle VC timeout 0
        cisco encapsulation
        input/output window sizes 2/2, packet sizes 128/128
      Timers: T10 60, T11 180, T12 60, T13 60
      Channels: Incoming-only none, Two-way 3-1024, Outgoing-only none
      RESTARTs 1/0 CALLs 0+0/0+0/0+0 DIAGs 0/0
  LAPB DCE, state CONNECT, modulo 8, k 7, N1 12056, N2 20
      T1 3000, T2 0, interface outage (partial T3) 0, T4 0
      VS 6, VR 6, tx NR 6, Remote VR 6, Retransmissions 0
      Queues: U/S frames 0, I frames 0, unack. 0, reTx 0
      IFRAMEs 6/6 RNRs 0/0 REJs 0/0 SABM/Es 1/1 FRMRs 0/0 DISCs 0/0
  Last input 00:05:09, output 00:05:09, output hang never
  Last clearing of "show interface" counters 00:05:54
  Queueing strategy: fifo
  Output queue 0/40, 0 drops; input queue 0/75, 0 drops
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
     9 packets input, 538 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
     10 packets output, 540 bytes, 0 underruns
     0 output errors, 0 collisions, 2 interface resets
     0 output buffer failures, 0 output buffers swapped out
1 carrier transitions     DCD=up  DSR=up  DTR=up  RTS=up  CTS=up

The show x25 map command, similar to the show frame-relay map command, can be used to observe the Layer 3 to X.121 addressing mapping on the local router. Example 12-5 shows the output of the show x25 map command at R1 and R2.

Example 12-5. Output of show x25 map Command at R1 and R2
R1#show x25 map
Serial0: X.121 654321 <-> ip 172.16.1.2
  PVC, 1 VC: 1/P

R2#show x25 map
Serial0: X.121 654321 <-> ip 172.16.1.2
PVC, 1 VC: 1/P

An extended ping from R1 to the network layer address 172.16.1.2/24 at R2 is performed. Example 12-6 shows the outcome.

Example 12-6. Performing a Ping from R1 to R2 over the X.25 Connection
R1#ping
Protocol [ip]:
Target IP address: 172.16.1.2
Repeat count [5]: 20
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 20, 100-byte ICMP Echos to 172.16.1.2, timeout is 2 seconds:
!!!!!!!!!!!!!!!!!!!!
Success rate is 100 percent (20/20), round-trip min/avg/max = 28/30/32 ms

Take note that the X.25 configuration commands discussed so far are only the minimum configurations required for setting up a basic X.25 circuit. There are many more X.25 configuration options and features available that are not covered here. You can make use of the Cisco Feature Navigator tool on the CCO (login is required) to find out other useful X.25 features for your network.

NOTE

The Cisco Annex G feature is released in Cisco IOS Release 12.0(3)T or later. The Cisco IOS T-train Release introduces new features into the Cisco IOS software and also provides fixes to defects. It is supported on major Cisco router platforms, including Cisco 1600, 2600, 3600, 7200, and 7500 series.

The next section presents a case study on the use of the Annex G feature. The scenario in the case study illustrates the use of the Annex G feature to transport the traffic from two private X.25 networks across a Frame Relay network.


Summary

This chapter presented a basic introduction to the X.25 protocol. X.25 is a popular WAN technology that is slowly becoming obsolete as a result of the widespread adoption of newer technologies, such as Frame Relay, ATM, and IP. Nevertheless, X.25 is not completely gone. It is ubiquitous in some industries and certain parts of the world today. For this reason, a feature to allow existing X.25 backbones to migrate to the newer technologies is needed.

The Cisco IOS software supports the Frame Relay Annex G feature, which allows X.25 backbone to Frame Relay migration by encapsulating X.25 traffic in a Frame Relay connection. The Annex G feature is very useful to service provider customers who have invested considerably in X.25 equipment and infrastructure but would like to migrate to newer technologies, such as Frame Relay. The Annex G feature facilitates a smooth migration strategy toward Frame Relay.

This chapter covered the basic configuration tasks required to enable X.25 on a Cisco router. The chapter also explained the operations of the Annex G feature and presented the configuration tasks for configuring Annex G on Cisco routers. The end of this chapter presents a case study to demonstrate the Cisco IOS show and debug commands for monitoring and maintaining Annex G configurations on a Cisco router. The next chapter covers the Cisco Frame Relay Enhanced LMI feature.


Review Questions

1: | What are the main reasons for users to migrate their existing X.25 networks to Frame Relay?
2: | What are the protocol differences between Frame Relay and X.25?
3: | Name the main advantages and disadvantages of Frame Relay over X.25.
4: | What must the user check when configuring distance vector routing protocols over an X.25 interface?
5: | Describe the use of the X.25 profiles for X.25 configuration and name the Cisco IOS configuration command for creating an X.25 profile.


References

  • Annex G: ANSI T1.617a documentation (1993): http://www.ansi.org

  • Cisco IOS 12.0T WAN Configuration Guide: http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/120newft/120t/120t3/x25anxg.htm


Case Study: Use of the Annex G Feature

This section presents a case study on the use of the Annex G feature. This section also covers the configuration tasks and commands required to set up Annex G on Cisco routers. Refer to the network diagram in Figure 12-4 as the reference for the configuration examples presented in this case study. The topology depicted in Figure 12-4 allows an X.25 customer to make use of the higher-speed Frame Relay for transit.

Figure 12-4. Network Diagram for Configuration Examples

NOTE

The Cisco IGX 8400 switch is used for provisioning the Frame Relay PVCs in this Frame Relay network. Alternatively, a Cisco router supporting the Frame Relay switching feature could be used to provision the PVCs.

Before moving to the configuration tasks for Annex G, first verify the status of the Frame Relay PVCs provisioned at the FR_R1 and FR_R2 routers. Example 12-7 indicates the status of the show frame-relay pvc command at both FR_R1 and FR_R2.

Example 12-7. Verify that the Frame Relay Circuits Are Properly Provisioned Before Configuring Annex G
! FR_R1:

FR_R1#show frame-relay pvc

PVC Statistics for interface Serial3/2 (Frame Relay DTE)

              Active     Inactive      Deleted       Static
  Local          0            0            0            0
  Switched       0            0            0            0
  Unused         1            0            0            0

DLCI = 100, DLCI USAGE = UNUSED, PVC STATUS = ACTIVE, INTERFACE = Serial3/2

  input pkts 0             output pkts 0            in bytes 0
  out bytes 0              dropped pkts 0           in pkts dropped 0
  out pkts dropped 0                out bytes dropped 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 00:00:23, last time pvc status changed 00:00:03

! FR_R2:

FR_R2#show frame-relay pvc

PVC Statistics for interface Serial3/2 (Frame Relay DTE)

              Active     Inactive      Deleted       Static
  Local          0            0            0            0
  Switched       0            0            0            0
  Unused         1            0            0            0

DLCI = 100, DLCI USAGE = UNUSED, PVC STATUS = ACTIVE, INTERFACE = Serial3/2

  input pkts 0             output pkts 0            in bytes 0
  out bytes 0              dropped pkts 0           in pkts dropped 0
  out pkts dropped 0                out bytes dropped 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 00:00:23, last time pvc status changed 00:00:03

Configuring Annex G on a Cisco Router

The Annex G feature is configured on both FR_R1 and FR_R2. X25_R1 and X25_R2 are strictly X.25 routers unaware of the "X.25 tunnel" configured through the Frame Relay network. To configure Annex G on the Frame Relay routers, you need to first set up X.25 profiles using the x25 profile profile-name global configuration command.

X.25 profiles allow specification of an X.25 configuration and LAPB configuration on an interface. Under the X.25 profile subconfiguration command, you can set up the X.25-specific configurations within. Example 12-8 lists the complete X.25 configuration commands available within the X.25 profile.

Example 12-8. X.25 Configuration Options Inside an X.25 Profile
FR_R1(config)#x25 profile Annex_G
FR_R1(config-x25)#x25 ?
  accept-reverse            Accept all reverse charged calls
  address                   Set interface X.121 address
  alias                     Define an alias address pattern
  aodi                      Enable AODI (Always On/Direct ISDN) Service
  default                   Set protocol for calls with unknown Call User Data
  facility                  Set explicit facilities for originated calls
  fail-over                 Set fail-over interface and delay time
  hic                       Set highest incoming channel
  hoc                       Set highest outgoing channel
  hold-queue                Set limit on packets queued per circuit
  hold-vc-timer             Set time to prevent calls to a failed destination
  htc                       Set highest two-way channel
  idle                      Set inactivity time before clearing SVC
  ip-precedence             Open one virtual circuit for each IP TOS
  ips                       Set default maximum input packet size
  lic                       Set lowest incoming channel
  linkrestart               Restart when LAPB resets
  loc                       Set lowest outgoing channel
  ltc                       Set lowest two-way channel
  map                       Map protocol addresses to X.121 address
  modulo                    Set operating standard
  nonzero-dte-cause         Allow non-zero DTE cause codes
  nvc                       Set maximum VCs simultaneously open to one host per protocol
  ops                       Set default maximum output packet size
  subscribe                 Subscribe to a supported behavior
  suppress-called-address   Omit destination address in outgoing calls
  suppress-calling-address  Omit source address in outgoing calls
  t20                       Set DTE Restart Request retransmission timer
  t21                       Set DTE Call Request retransmission timer
  t22                       Set DTE Reset Request retransmission timer
  t23                       Set DTE Clear Request retransmission timer
  threshold                 Set packet count acknowledgement threshold
  use-source-address        Use local source address for forwarded calls
  win                       Set default input window (maximum unacknowledged packets)
  wout                     Set default output window (maximum unacknowledged packets)

The frame-relay interface-dlci command or the encapsulation x25 command can reference a configured x.25 profile. Multiple Annex G Frame Relay DLCIs can also use the same profile. A Frame Relay DLCI configured for Annex G is logically equivalent to a single X.25/LAPB interface. Annex G service is only supported on the Frame Relay main interface.

After this step is done, the x25 route command must be used to switch X.25 traffic from the inside X.25 network over Annex G. Both the X.25 serial interface and the Frame Relay DLCI number must be specified.

The configuration tasks for configuring Annex G is summed up in the list below. The configurations are applied to each router connected between the X.25 and Frame relay network (FR_R1 and FR_R2 in Figure 12-4).

Annex G Configuration Tasks
Step 1. | Set up the X.25 profile for Annex G using the global x25 profile profile-name [dte|dce|dxe] configuration command. The default mode is DTE.
Step 2. | Activate Frame Relay encapsulation on the interface to be used for Annex G. This interface should be a Frame Relay main interface connected to a Frame Relay switch/network.
Step 3. | Under the main interface, configure the Frame Relay DLCI with the frame-relay interface-dlci command.
Step 4. | Under the Frame Relay interface DLCI configuration mode, assign the X.25 profile configured in Step 1 to the DLCI using the x25-profile profile-name command.
Step 5. | Enable X.25 routing of outgoing calls with x25 routing command. This is required for Step 6.
Step 6. | Use the x25 route number interface serial-interface dlci number command to assign an X.25 route for the DLCI on that interface. This is needed if the router is to accept switched calls and to place outgoing calls.

The running configurations for the routers in Figure 12-4 are shown in Example 12-9. Note that some text output from the complete configuration file is omitted, and only the configurations related specifically to Annex G are shown.

Example 12-9. Running Configurations of X25_R1, FR_R1, FR_R2, and X25_R2 in Figure 12-4
! X25_R1:
<text omitted>
!
ip routing
!
interface Serial1
 ip address 172.16.1.1 255.255.255.0
 encapsulation x25
 x25 address 123456
 x25 ltc 128
 x25 nvc 4
 x25 map ip 172.16.1.2 654321 broadcast

! FR_R1:

<text omitted>
!
 x25 profile FR_ANNEX_G dte
 x25 accept-reverse
x25 routing
!
interface Serial3/0
 no ip address
 encapsulation x25 dce
 x25 ltc 128
 x25 nvc 4
 clock rate 64000
!
interface Serial3/2
 no ip address
 encapsulation frame-relay
 no fair-queue
 frame-relay interface-dlci 100
  x25-profile FR_ANNEX_G
!
x25 route 123456 interface Serial3/0
x25 route 654321 interface Serial3/2 dlci 100

! FR_R2:

<text omitted>
!
 x25 profile FR_ANNEX_G dce
 x25 accept-reverse
x25 routing
!
interface Serial1/0
 no ip address
 encapsulation x25 dce
 x25 nvc 4
 clockrate 64000
!
interface Serial1/3
 no ip address
 encapsulation frame-relay
 frame-relay interface-dlci 200
 x25-profile FR_ANNEX_G
!
x25 route 654321 interface Serial1/0
x25 route 123456 interface Serial1/3 dlci 200

! X25_R2:

<text omitted>
ip routing
!
interface Serial3
 ip address 172.16.1.2 255.255.255.0
 encapsulation x25
 x25 address 654321
 x25 nvc 4
 x25 map ip 172.16.1.1 123456 broadcast

Take note that one of the X25 profiles configured on FR_R1 and FR_R2 is in the DTE mode, whereas the other is set to DCE mode. The configurations at both Annex G routers must be compatible, otherwise the Annex G circuit will fail to function properly.

Monitoring and Troubleshooting Annex G

The show x25 interface serial/number dlci dlci_number privileged EXEC command can be used to observe the operating configuration status of a particular Annex G connection, as shown in Example 12-10.

Example 12-10. Using the show x25 interface serial/number dlci dlci_number Command
FR_R1#show x25 interface s3/2 dlci 100
SVC 1,  State: D1,  Interface: Se3/2 DLCI 100
  Started 00:06:08, last input 00:06:08, output 00:06:08
  Connects 654321 <--> 123456 to Serial3/0 SVC 128
  Window size input: 2, output: 2
  Packet size input: 128, output: 128
  PS: 5  PR: 5  ACK: 5  Remote PR: 4  RCNT: 0  RNR: no
  P/D state timeouts: 0  timer (secs): 0
  data bytes 500/500 packets 5/5 Resets 0/0 RNRs 0/0 REJs 0/0 INTs 0/0

The state is D1, which indicates Flow Control Ready. Table 12-2 lists the other X.25 states that may be encountered.

Table 12-2. X.25 Connection State Definitions

State

Definition

D1

Flow control ready

D2

DTE reset request

D3

DCE reset indication

P1

Idle

P2

DTE waiting for DCE to connect call

P3

DCE waiting for DTE to accept call

P4

Data transfer

P5

Call collision

P6

DTE clear request

P7

DCE clear indication

R1

Packet level ready

R2

DTE restart request

R3

DCE restart indication

X1

Nonstandard state for a virtual circuit in hold-down

The show x25 profile command can also be used to verify the parameters of the X25 profiles configured on the local router. Example 12-11 shows an example of the use of the command.

Example 12-11. Output of show x25 profile Command
FR_R1#show x25 profile

X.25 profile name: FR_ANNEX_G
  Number of references: 1
  In use by:
      Annex G: Serial3/2 DLCI 100
  PROFILE DTE, address <none>, state R/Inactive, modulo 8, timer 0
      Defaults: idle VC timeout 0
        input/output window sizes 2/2, packet sizes 128/128
      Timers: T20 180, T21 200, T22 180, T23 180
      Channels: Incoming-only none, Two-way 1-1024, Outgoing-only none
  LAPB DTE, modulo 8, k 7, N1 default, N2 20
T1 3000, T2 0, interface outage (partial T3) 0, T4 0

The output of the command shows the number of Annex G DLCIs that are currently referencing this particular X25 profile. More than one Frame Relay Annex G DLCI can use an X25 profile. Next, the show x25 vc command can be used to display the information about an X.25 VC connected to an Annex G service. An example is given in Example 12-12.

Example 12-12. Output of show x25 vc Command
FR_R1#show x25 vc
SVC 128,  State: D1,  Interface: Serial3/0
  Started 00:18:40, last input 00:18:39, output 00:18:39
  Connects 654321 <--> 123456 from Serial3/2 DLCI 100
  Window size input: 2, output: 2
  Packet size input: 128, output: 128
  PS: 5  PR: 5  ACK: 4  Remote PR: 5  RCNT: 1  RNR: no
  P/D state timeouts: 0  timer (secs): 0
  data bytes 500/500 packets 5/5 Resets 0/0 RNRs 0/0 REJs 0/0 INTs 0/0
SVC 1,  State: D1,  Interface: Se3/2 DLCI 100
  Started 00:18:40, last input 00:18:39, output 00:18:39
  Connects 654321 <--> 123456 to Serial3/0 SVC 128
  Window size input: 2, output: 2
  Packet size input: 128, output: 128
  PS: 5  PR: 5  ACK: 5  Remote PR: 4  RCNT: 0  RNR: no
  P/D state timeouts: 0  timer (secs): 0
  data bytes 500/500 packets 5/5 Resets 0/0 RNRs 0/0 REJs 0/0 INTs 0/0

Finally, verify the connectivity provided by the Annex G service by performing an extended ping from X25_R1 to X25_R2. The outcome of the ping test is shown in Example 12-13.

Example 12-13. Performing a Ping from X25_R1 to X25_R2 over the Annex G Connection
X25_R1#show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
       i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
       * - candidate default, U - per-user static route, o - ODR
       P - periodic downloaded static route

Gateway of last resort is not set

     172.16.0.0/24 is subnetted, 1 subnets
C       172.16.1.0 is directly connected, Serial1

X25_R1#ping
Protocol [ip]:
Target IP address: 172.16.1.2
Repeat count [5]: 20
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 20, 100-byte ICMP Echos to 172.16.1.2, timeout is 2 seconds:
!!!!!!!!!!!!!!!!!!!!
Success rate is 100 percent (20/20), round-trip min/avg/max = 116/118/120 ms

This example verifies proper operation of the Annex G connection. X.25 data packets from X25_R1 are transported transparently over the Frame Relay network to the remote X.25 destination, X25_R2. Using Annex G, the local X25 host has no knowledge that the connection service is provided by a Frame Relay network.

Two IOS commands are available for troubleshooting the Annex G connection on a Cisco router. The clear x25 serial [number] [dlci_number] command allows an Annex G DLCI link to be restarted. The user can specify to either clear all X.25 circuits on that link or to clear a specific X.25 logical circuit number. The example that follows clears all the X.25 connections configured on serial 3/0.

FR_R1#clear x25 serial 3/0
Force Restart [confirm]

The debug x25 annexg command can be used to display relevant X.25 debugging information for a Frame Relay Annex G connection. Example 12-14 shows a sample output observed on FR_R1 after the command was enabled and X.25 data packets were received from X25_R1, routed to X25_R2.

Example 12-14. Sample Output of debug x25 annexg Command
FR_R1#debug x25 annexg
X.25 over FR (Annex-G) debugging is on

21:25:06: annexg_restart_tx: sending pak to Serial3/2
21:25:06: annexg_restart_tx: sending pak to Serial3/2
21:25:06: annexg_restart_tx: sending pak to Serial3/2
21:25:06: annexg_restart_tx: sending pak to Serial3/2
21:25:06: annexg_restart_tx: sending pak to Serial3/2
21:25:06: annexg_restart_tx: sending pak to Serial3/2
21:25:06: annexg_restart_tx: sending pak to Serial3/2
21:25:07: annexg_restart_tx: sending pak to Serial3/2
21:25:07: annexg_restart_tx: sending pak to Serial3/2
21:25:07: annexg_restart_tx: sending pak to Serial3/2

The debug messages indicate that X.25 packets are rerouted out to the Frame Relay Annex G connection on Serial 3/2.


Chapter 13. Frame Relay Enhanced Local Management Interface (ELMI)

Chapter 1, "Introduction to Frame Relay," introduced the basic Frame Relay Local Management Interface (LMI) protocols. LMI is a set of specifications that provides a standard connection status signaling mechanism for Frame Relay devices. With the basic LMI protocols, different statusessuch as network congestion, creation of new switched virtual circuits (SVCs), and polling of virtual circuit (VC) connection statuscan be actively exchanged between Frame Relay devices in a Frame Relay network. For this reason, LMI has become imperative to the proper operation and monitoring of Frame Relay circuits in Frame Relay networks.

Currently, the Cisco Frame Relay Enhanced LMI (ELMI) specifications provide newer, advanced capabilities. ELMI is an enhancement to LMI that defines new specifications. This chapter covers the Cisco Frame Relay ELMI feature.

The Frame Relay ELMI feature comprises two separate components: Frame Relay Quality of Service (QoS) Autosense and Address Registration. The Frame Relay QoS Autosense functionality in ELMI effectively allows Cisco WAN network switches, such as the IGX, to inform connected Cisco Frame Relay devices about network parameters, such as QoS, committed information rate (CIR), committed burst (Bc), and excess burst (Be). The Frame Relay Address Registration functionality provides a Network Management System (NMS) with the capability to detect connectivity between the switches and routers on a Frame Relay network. The Frame Relay ELMI feature is currently supported only on Cisco network switches, Cisco routers, and other network devices.

This chapter begins with a discussion of the current issues Frame Relay users experience. The chapter presents an overview of the Frame Relay ELMI solution and its benefits. The operation of both functionalities, QoS Autosense and Address Registration, in the Frame Relay ELMI feature are also explained. Subsequently, the configuration tasks for the Frame Relay ELMI feature are illustrated with practical configuration examples on Cisco routers. Finally, this chapter demonstrates the relevant Cisco IOS show and debug commands for monitoring and maintaining the Frame Relay ELMI configurations on a Cisco router.

The topics and questions that this chapter addresses include the following:

  • The applications and benefits of Frame Relay QoS Autosense and Frame Relay Address Registration

  • Operation of the Frame Relay QoS Autosense and Frame Relay Address Registration features

  • Configuring Frame Relay QoS Autosense and Frame Relay Address Registration

  • Monitoring and maintaining Frame Relay QoS Autosense and Frame Relay Address Registration

  • Operation of Management Information Base (MIB)

After completing this chapter, readers will be able to appreciate the benefits of the Frame Relay QoS Autosense functionality and how it helps to simplify configuration and management of Frame Relay devices. Readers will also be able to understand the use of the Frame Relay Address Registration functionality and the capability it provides to NMSs to detect connectivity in the Frame Relay network. Readers will learn how to configure the Frame Relay ELMI feature on Cisco devices, as well as the Cisco IOS show and debug commands to monitor and maintain Frame Relay ELMI configurations on Cisco devices.


Current Issues

This section addresses the issues affecting current Frame Relay users. The highlighted issues are noteworthy in particular to Frame Relay customers maintaining an enterprise-scale Frame Relay network.

Unable to Dynamically Obtain QoS Parameters from Frame Relay Switch

With the current Frame Relay LMI protocols, there is no way a Frame Relay service provider (Frame Relay switches) can dynamically inform its users or customers (Frame Relay access routers) about various QoS parameters. Frame Relay customers or users need to directly obtain their QoS parameters from their service providers to configure their Frame Relay access routers. Examples of important QoS parameters include the common Frame Relay Traffic Shaping parameters, such as CIR, Bc, and Be.

Obtaining the correct QoS parameters is very important, because the Frame Relay devices need to base their congestion management decisions on those parameters. Instead of manually setting up the QoS parameters on every Frame Relay access router connected to the Frame Relay switch, a more scalable approach would be to allow the Frame Relay access devices to dynamically obtain such information from the Frame Relay network.

Unable to Obtain End-to-End Mapping of Frame Relay Network

The present software does not support network topology discovery for Frame Relay interfaces. As such, router and switch interconnections are unknown to applications running on NMSs. The existing Frame Relay LMI protocols need to be enhanced to allow topology discovery for devices directly attached to Frame Relay switches across WAN interfaces.


Solutions to Current Issues

This section introduces the Frame Relay QoS Autosense and Frame Relay Address Registration functionalities of the Frame Relay ELMI feature. The issues highlighted in the previous section, "Current Issues," are addressed here.

NOTE

Frame Relay QoS Autosense is supported from Cisco IOS Release 11.3 or later. Frame Relay ELMI Address Registration is supported from Cisco IOS Release 12.1(3)T or later. They are both supported on Cisco 2500, Cisco 2600, Cisco 3600, Cisco 4500, Cisco 7200, and Cisco 7500 series routers. In addition, certain high-end Cisco Catalyst switches installed with WAN modules and router port adaptors (PA), such as the Catalyst 6500 series installed with a SUP720 module, are able to support both Frame Relay QoS Autosense and Frame Relay ELMI Address Registration. The Frame Relay ELMI Address Registration is supported by the IGX switch running switch software with version 9.3.x or later. Additional information on QoS Autosense is available at http://www.cisco.com/univercd/cc/td/doc/product/software/ios113ed/113ed_cr/wan_c/wcfrelay.htm. Additional information on Frame Relay Address Registration can be found at: http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121newft/121t/121t3/dtfripar.htm.

Frame Relay ELMI QoS Autosense

Frame Relay ELMI QoS Autosense is supported only on Cisco routers and Cisco network switches, such as IGX and BPX. Essentially, the Frame Relay ELMI QoS Autosense feature allows a Cisco router to respond to changes in the network dynamically. With QoS Autosense, a Cisco router data terminal equipment (DTE) can be configured to dynamically learn QoS parameters from the connected Cisco network switch data circuit-terminating equipment (DCE). The router can subsequently use the learned QoS parameters for Frame Relay Traffic Shaping, Frame Relay configurations, or network management purposes. Moreover, a service provider can configure its Frame Relay switch to use ELMI to disseminate configuration information to its customers to set up congestion management and prioritization schemes.

Many benefits are associated with Frame Relay QoS Autosense. First of all, Frame Relay QoS Autosense effectively simplifies configuration and management tasks on every Frame Relay access router. Additionally, ELMI allows central management of user configurations. A service provider can use ELMI to disseminate an aligned set of Frame Relay parameters to its customers so the common set of configurations is consistently applied to the entire network.

Figure 13-1 illustrates an example of the ELMI QoS Autosense application. In the figure, a Cisco switch sends QoS information to a Cisco router.

Figure 13-1. ELMI Exchanges Between Cisco Switch and Cisco Router

When the Frame Relay ELMI QoS Autosense feature is deployed in conjunction with the Frame Relay Traffic Shaping feature, the router can respond to changes in the network dynamically.

This dynamic response eliminates the requirements of the user to manually configure individual QoS parameters and also reduces the chance of inconsistent or inaccurate values during the configuration of the router. Frame Relay QoS Autosense should be disabled if the Frame Relay user wishes to have full control of the QoS parameter settings.

NOTE

The Frame Relay ELMI feature works in parallel with the original LMI protocols. The Frame Relay QoS Autosense feature does not affect the functionality of the LMI Autosense feature, which is enabled by default on Frame Relay interfaces. It is also compatible with Frame Relay SVC.

Frame Relay ELMI Address Registration

The Frame Relay ELMI Address Registration feature provides an End-to-End networking solution with integrated network management capabilities. Using ELMI protocols and the enhanced Frame Relay MIB, an NMS can become aware of the existing network connectivity between the switches and routers in a network. Effectively, this allows autodetection of the complete network topology.

The original LMI protocols are enhanced to support the Frame Relay ELMI Address Registration feature. With ELMI Address Registration, users can make use of network management tools on an NMS to discover the complete topology of the network. The Frame Relay Address Registration feature uses the ELMI protocols to allow the autodetection of the interconnection between Cisco routers and switches. With a network management tool such as CiscoWorks 2000, network administrators can create an end-to-end topology map of their network. The Frame Relay ELMI feature supports CiscoWorks 2000.

NOTE

CiscoWorks consists of a family of comprehensive network management tools that allows users to easily access and manage critical network resources. Refer to http://www.cisco.com/en/US/products/sw/cscowork/index.html for more details on CiscoWorks products.

Figure 13-2 illustrates a typical network in which ELMI Address Registration is used. In this figure, a central NMS station is connected to a Frame Relay network on an out-of-band management Ethernet segment. Recall that an out-of-band network is typically meant for network management purposes and is normally not part of the network, which transports users' traffic.

Figure 13-2. Detecting Connectivity Using ELMI Address Registration

Referring to Figure 13-2, after Address Registration is fully configured on all Frame Relay devices, the Frame Relay devices first register their IP addresses and interface indexes (IfIndex) with each other through version negotiation of the ELMI protocol. Then the NMS uses the Frame Relay MIB to poll the managed interfaces of the Frame Relay devices. Finally, the Frame Relay devices answer to the queries of the NMS, and the NMS learns the IP address and IfIndex of the devices to discover the interconnection between the routers and the switches.

The NMS is not able to discover the interconnection between two connected Frame Relay devices if Frame Relay Address Registration is disabled or is not supported on one of the devices. For example, if Address Registration is supported on the router but not on the Frame Relay switch, the neighbor IP address learned by the NMS would be 0.0.0.0. Refer to Table 13-1 in the "Operation of MIB" section of this chapter for all possible results if a device is unable to support Frame Relay Address Registration.

Table 13-1. Representation of the ELMI MIB Objects

ELMI MIB Object Name

Syntax/Values

Description

cfrElmiIpAddr

IpAddress/Read only

This represents the management address of the device used for address registration.

CfrElmiLinkStatus

Integer/ Read only

This indicates whether ELMI is enabled on a Frame Relay interface: enabled(1), disabled(2).

cfrElmiArStatus

Integer/ Read only

This variable indicates whether ELMI AR is enabled or not on a Frame Relay interface. A value of 1 indicates ELMI AR is supported on the interface. A value of 2 indicates ELMI AR is supported, but the user disabled the exchange of IP address and IfIndex with the neighboring device.

cfrElmiRemoteStatus

Integer/ Read only

This variable states the ELMI status on the other end of the interface. If cfrElmiLinkStatus is enabled on the other end, a value of 1 is returned, otherwise 2 is returned.

cfrElmiNeighborArStatus

Integer/ Read only

This variable indicates the status of ELMI AR on the neighboring device. A value of 1 indicates ELMI AR is not supported on the neighboring device. A value of 2 indicates ELMI AR is enabled on the interface. A value of 3 indicates AR is supported, but the user disabled the exchange of IP address and IfIndex with the neighbor.

cfrElmiNeighborIpAddress

IpAddress/Read only

The management IP address of the neighboring device to which the other end of this interface is connected. NMS can use this address to send management messages to the device.

If Address Registration is not supported on the remote end, the value is 0.0.0.0. NMS uses this object in the topology discovery of the network.

CfrElmiNeighborIfIndex

Integer/ Read only

The interface index of the neighboring device to which this interface is connected. If the value of cfrElmiNeighborArStatus is 2, this has a valid value. If the value of cfrElmiNeighborArStatus is 3 or 1, the value of this object is 0. NMS uses this object in the topology discovery of the network.

CfrElmiNeighborVendorName

String/Read Only

Vendor name of the neighboring device to which the other end of this interface is connected.

cfrElmiNeighborPlatformName

String/Read Only

Platform name of the neighboring device to which the other end of this interface is connected.

cfrElmiNeighborDeviceName

String/Read Only

Device name of the neighboring device to which the other end of this interface is connected.

Using Frame Relay ELMI Address Registration, neighboring devices exchange their management IP addresses and IfIndex. An NMS is connected to every Frame Relay device on the Frame Relay network on an out-of-band network. Normally, an out-of-band network is a network where only management information traverses. Then the NMS actively polls the devices and uses MIB to extract the IP addresses and IfIndex information of devices neighboring the managed device.

During version negotiation, a neighbor informs its connected neighbors of its management IP address and IfIndex of the connected interface. Both the router and the switch register their IP addresses and IfIndexes with each other. The Frame Relay MIB is enhanced to support Address Registration and to allow NMS to detect the connectivity between the router and switch.

As shown in Figure 13-2, the ELMI protocol is enabled on the connected interfaces of the routers and switches. The NMS is typically connected to the routers and switches through an Ethernet segment. When ELMI is running, the routers inform the switch of their IP addresses and IfIndexes. Similarly, the switch sends its IP address and IfIndex to the router. The NMS then reads the connectivity information from the routers and switches and creates a network map of the various connections. If the IP address of the router or switch changes, the address change information can be detected during the periodic version negotiation.


Configuring the Frame Relay ELMI Feature

This section explains the configuration tasks required to configure Frame Relay QoS Autosense and Frame Relay Address Registration on Cisco devices. Practical configuration examples are used to illustrate the relevant Cisco IOS configuration commands. This section also introduces the related Cisco IOS show and debug commands for monitoring and maintaining Frame Relay ELMI configurations on a Cisco router.

Configuring Frame Relay QoS Autosense

This section discusses the Cisco IOS configuration commands required for configuring Frame Relay ELMI QoS Autosense on a Cisco router.

Before configuring Frame Relay ELMI QoS Autosense on a Cisco router, Frame Relay encapsulation must be enabled on the main interface. ELMI must be configured on the main interface. To configure ELMI QoS Autosense, follow the configuration steps listed below:

Step 1. | Go into the interface configuration mode of the main interface on which you want to configure Frame Relay ELMI QoS Autosense. Frame Relay encapsulation must be enabled on the specified main interface. This is done with encapsulation frame-relay [cisco | ietf].
Step 2. | Enable Frame Relay ELMI QoS Autosense on the main interface with the frame-relay qos-autosense interface configuration command. This command effectively enables the ELMI process on the router.

Example 13-1 shows the configuration example of enabling Frame Relay ELMI QoS Autosense on a Cisco router.

Example 13-1. Configuring Frame Relay ELMI QoS Autosense
R1#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)#interface serial3/1
R1(config-if)#encapsulation frame-relay
R1(config-if)#frame-relay qos-autosense
R1(config-if)#end
R1#

The following is a practical example to verify the Frame Relay QoS Autosense feature. For the discussion with Frame Relay ELMI QoS Autosense in this section, a simple network setup using a Cisco c7200 series router and a Cisco IGX 8400 series switch, as depicted in Figure 13-3, is used.

Figure 13-3. Verifying ELMI QoS Autosense

Example 13-2 shows the running configurations of the router in Figure 13-3.

Example 13-2. Running Configurations of Router in Figure 13-3
<output omitted>

ip routing
!
interface Serial3/1
 encapsulation frame-relay
 frame-relay traffic-shaping
 frame-relay lmi-type q933a
 frame-relay qos-autosense
!
interface Serial3/1.100 point-to-point
 ip address 172.16.1.1 255.255.255.252
 frame-relay interface-dlci 100
!
interface Serial3/3
 encapsulation frame-relay
 frame-relay traffic-shaping
 frame-relay lmi-type q933a
 frame-relay qos-autosense
!
interface Serial3/3.200 point-to-point
 ip address 172.16.2.1 255.255.255.252
 frame-relay interface-dlci 200

In the configurations shown in Example 13-2, observe that Frame Relay traffic shaping is configured on router R1 under the main interfaces Serial 3/1 and Serial 3/3. The frame-relay traffic-shaping command is supported at the main interface level and not at the subinterface level. Similarly, the frame-relay qos-autosense command is configured at the main interface level and not at the subinterface level.

NOTE

It is not necessary to configure Frame Relay Traffic Shaping on the interface to enable ELMI. However, when Frame Relay traffic shaping is used in conjunction with ELMI QoS Autosense, the router can sense QoS information (such as CIR, Bc, and Be) from the switch. These values can be used for traffic shaping. This enhancement works only between Cisco routers and Cisco switches (IGX/BPX and MGX series).

The setup of the Universal Frame-Relay Module (UFM) ports on the Cisco IGX is shown in Example 13-3.

Example 13-3. Setup of the UFM Ports on the Cisco IGX Switch
Port:      11.11             [ACTIVE  ]
Interface:  V35     DCE                      Configured Clock:    256 Kbps
Clocking:   Normal                           Measured Rx Clock:   256 Kbps
Neighbor IP Add: 0.0.0.0               Neighbor IfIndex: 7
Port ID                        0       Min Flags / Frames           1
Port Queue Depth           65535       OAM Pkt Threshold            3 pkts
ECN Queue Threshold        65535       T391 Link Intg Timer        25 sec
DE Threshold                 100 %     N391 Full Status Poll        3 cyl
Signalling Protocol  Annex A UNI -E    EFCI Mapping Enabled        No
Asynchronous Status          Yes       CLLM Enabled/Tx Timer   No/  0 msec
T392 Polling Verif Timer      15       IDE to DE Mapping          Yes
N392 Error Threshold           4       Interface Control Template
N393 Monitored Events Count    4          Lead    CTS    DSR    DCD
Communicate Priority          No          State   ON     ON     ON
Upper/Lower RNR Thresh  75%/ 25%       Neighbor Discovery     Disable

Port:       11.5              [ACTIVE  ]
Interface:  V35     DCE                      Configured Clock:    256 Kbps
Clocking:   Normal                           Measured Rx Clock:   256 Kbps
Neighbor IP Add: 0.0.0.0               Neighbor IfIndex: 9
Port ID                        0       Min Flags / Frames           1
Port Queue Depth           65535       OAM Pkt Threshold            3 pkts
ECN Queue Threshold        65535       T391 Link Intg Timer        25 sec
DE Threshold                 100 %     N391 Full Status Poll        3 cyl
Signalling Protocol  Annex A UNI -E    EFCI Mapping Enabled        No
Asynchronous Status          Yes       CLLM Enabled/Tx Timer   No/  0 msec
T392 Polling Verif Timer      15       IDE to DE Mapping          Yes
N392 Error Threshold           4       Interface Control Template
N393 Monitored Events Count    4          Lead    CTS    DSR    DCD
Communicate Priority          No          State   ON     ON     ON
Upper/Lower RNR Thresh  75%/ 25%       Neighbor Discovery     Disable

On the Cisco IGX switch, the QoS parameters specified and configured for DLCI 100 and 200 are shown in Example 13-4. The CIR is configured at 64 kbps, the Bc is at 6000 bps, and the Be is at 5000 bps.

The ELMI protocol is activated on the IGX switch port using the cnfport IGX switch port configuration command. The Cisco IGX switch command syntax and configuration guide can be downloaded from Cisco Connection Online (CCO) at: http://www.cisco.com/en/US/products/hw/switches/ps988/index.html. Alternatively, the Cisco Press book Cisco WAN Switching Professional Reference (ISBN: 1587050552) by Tracy Thorpe (2002) is a comprehensive resource for Cisco WAN switches and configuration commands.

Example 13-4. Specifying the QoS Parameters for DLCI 100 and DLCI 200 on the IGX Switch
! DLCI 100

Conn:  11.11.100         wan_igx1    11.11.100          fr       Status:OK
    MIR         CIR         Bc          Be       Cmax   ECN QThresh     QIR
   16/16       64/64     6000/6000   5000/5000   10/10  65535/65535    56/56

Pri: L  Test-RTD: 0 msec                               FST: n  % Util: 100/100

Path:   Route information not applicable for local connections

IGX      UFMU:   OK
UFI:   OK

! DLCI 200

Conn:  11.5.200          wan_igx1    11.5.200           fr       Status:OK
    MIR         CIR         Bc          Be       Cmax   ECN QThresh     QIR
   16/16       64/64     6000/6000   5000/5000   10/10  65535/65535    56/56

Pri: L  Test-RTD: 0 msec                               FST: n  % Util: 100/100

Path:   Route information not applicable for local connections

IGX      UFMU:   OK
UFI:   OK

show frame-relay qos-autosense

The show frame-relay qos-autosense privileged EXEC command can be used on the router to verify the QoS values learned from the switch, which is also configured with QoS Autosense. This is illustrated in Example 13-5.

Example 13-5. Verifying ELMI QoS Autosense with show frame-relay qos-autosense
R1#show frame qos-autosense

ELMI information for interface Serial3/1
IP Address used for Address Registration:0.0.0.0 My Ifindex:7
ELMI AR Status:Enabled
 Connected to switch:SWITCH   Platform:IGX   Vendor:CISCO
SW side ELMI AR Status:Disabled
IP Address used by switch for address registration:0.0.0.0 Ifindex:0
              (Time elapsed since last update 00:02:34)

 DLCI = 100
 OUT:   CIR 64000        BC 6000         BE 5000         FMIF 4506
 IN:    CIR Unknown      BC Unknown      BE Unknown      FMIF Unknown
 Priority 0     (Time elapsed since last update 00:01:46)

ELMI information for interface Serial3/3
IP Address used for Address Registration:0.0.0.0 My Ifindex:9
ELMI AR Status:Enabled
 Connected to switch:SWITCH   Platform:IGX   Vendor:CISCO
SW side ELMI AR Status:Disabled
IP Address used by switch for address registration:0.0.0.0 Ifindex:0
              (Time elapsed since last update 00:01:32)

 DLCI = 200
 OUT:   CIR 64000        BC 6000         BE 5000         FMIF 4506
 IN:    CIR Unknown      BC Unknown      BE Unknown      FMIF Unknown
 Priority 0     (Time elapsed since last update 00:01:07)

show frame-relay pvc

Compare the values of the QoS parameters learned by the R1 router with the parameters set on the IGX switch. The show frame-relay pvc command also indicates the parameters to be used for Frame Relay Traffic Shaping, as shown in Example 13-6.

Example 13-6. The show frame-relay pvc Command Indicates QoS Values Learned Via QoS Autosense Are Used for Traffic Shaping
R1#show frame-relay pvc 100

PVC Statistics for interface Serial3/1.100 (Frame Relay DTE)

DLCI = 100, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial3/1.100

  input pkts 62            output pkts 62           in bytes 2108
  out bytes 2108           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 62        out bcast bytes 2108
  pvc create time 01:09:53, last time pvc status changed 00:00:41
  cir 64000     bc 6000      be 5000      byte limit 1375   interval 93
  mincir 32000     byte increment 750   Adaptive Shaping none
  pkts 62        bytes 2108      pkts delayed 0         bytes delayed 0
  shaping inactive
  traffic shaping drops 0
  Queueing strategy: fifo
  Output queue 0/40, 0 drop, 0 dequeued

R1#show frame-relay pvc 200

PVC Statistics for interface Serial3/3.200 (Frame Relay DTE)

DLCI = 200, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial3/3.200

  input pkts 60            output pkts 60           in bytes 2040
  out bytes 2040           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 60        out bcast bytes 2040
  pvc create time 01:09:53, last time pvc status changed 00:00:00
  cir 64000     bc 6000      be 5000      byte limit 1375   interval 93
  mincir 32000     byte increment 750   Adaptive Shaping none
  pkts 60        bytes 2040      pkts delayed 0         bytes delayed 0
  shaping inactive
  traffic shaping drops 0
  Queueing strategy: fifo
Output queue 0/40, 0 drop, 0 dequeued

When ELMI is used in conjunction with Frame Relay Traffic Shaping, the router receives the congestion information through BECN or ForeSight congestion signaling and reduces its output rate to the value specified in the Frame Relay traffic shaping configurations. Learning the parameters required for Frame Relay traffic shaping from the network can reduce the chance of specifying inconsistent values when configuring the router.

Configuring Frame Relay ELMI Address Registration

This section looks at the configuration examples for enabling Frame Relay ELMI for Address Registration.

Before enabling Frame Relay ELMI Address Registration, ELMI protocols must be turned on the interface with the frame-relay qos-autosense command. To configure the Frame Relay ELMI Address Registration feature on a Cisco router, perform the configuration steps listed below:

Step 1. | Configure the IP address to be used for ELMI Address Registration. This is done using the frame-relay address registration ip ip-address global configuration command. Use the no form of the command to disable IP address registration.
Step 2. | Alternatively, the frame-relay address registration auto-address command can be used to select an IP address when the router boots up. By default, the frame-relay address registration auto-address command is enabled.
Step 3. | The no frame-relay address-reg enable interface configuration command can be used to disable ELMI Address Registration on an interface. You might want to do so for security reasons, when the user does not wish to exchange IP address and the IfIndex with the neighboring devices.

NOTE

By default, frame-relay address registration auto-address is enabled. The auto-address mechanism first checks the Ethernet interfaces on the router for the management IP address. If none is found, it checks for serial interfaces and then any other interface types.

The no frame-relay address registration auto-address global configuration command turns off the autoselection of the IP address. Similarly, the auto-address mechanism is disabled if an IP address is specified with the frame-relay address registration ip ip-address global configuration command.

The next example looks at the Frame Relay ELMI Address Registration feature operating between a Cisco router and the Cisco IGX switch. Both frame-relay address registration ip ip-address and frame-relay address registration auto-address commands introduced earlier are tested and verified.

To demonstrate the use of Address Registration via Frame Relay ELMI, the network diagram illustrated in Figure 13-4 is used for the examples. A UNIX workstation installed with a standard Simple Network Management Protocol (SNMP) query tool is also used to mimic the network management tool on the standard CiscoWorks network management software.

Figure 13-4. Verifying Frame Relay ELMI Address Registration with a Simple Network

The configurations of router R1 are shown in Example 13-7. Example 13-7 first verifies Frame Relay Address Registration using a management IP address manually specified by the user. In this case, the frame-relay address registration ip ip-address command is used. The snmp-server community command and related SNMP information are discussed in the next section.

Example 13-7. Configurations of Router R1 in Figure 13-4
<output omitted>

ip routing
!
frame-relay address registration ip 1.1.1.1
!
interface Serial3/1
 encapsulation frame-relay
 frame-relay traffic-shaping
 frame-relay lmi-type q933a
 frame-relay qos-autosense
!
interface Serial3/1.100 point-to-point
 ip address 172.16.1.1 255.255.255.252
 frame-relay interface-dlci 100
!
interface Serial3/3
 encapsulation frame-relay
 frame-relay traffic-shaping
 frame-relay lmi-type q933a
 frame-relay qos-autosense
!
interface Serial3/3.200 point-to-point
 ip address 172.16.2.1 255.255.255.252
 frame-relay interface-dlci 200
!
interface Ethernet1/0
 ip address 150.1.5.1 255.255.255.0
 !
snmp-server community public RO

NOTE

The management IP address specified in the frame-relay address registration ip command in Example 13-7 is 1.1.1.1. This address is not configured anywhere on any physical or logical interfaces on router R1. In fact, the management IP address, as its name implies, exists only for the purpose of network management and does not need to be defined before it can be used. However, the network administrator should use a proper identification and addressing scheme that allows easy mapping of the entire network topology.

In Example 13-7, ELMI Address Registration is enabled on both serial main interfaces on router R1. On the Cisco IGX switch side, ELMI Address Registration is enabled only on port 11.11 (DLCI 100) and disabled on port 11.5 (DLCI 200), configured using the cnfport IGX switch port configuration command. The management IP address configured on the switch is 172.21.202.99.

Later in this chapter, the behavior of the ELMI AR feature is observed when it is disabled on one side (enabled on one port but disabled on another port) of the network (switch side in this case).


Operation of MIB

Before moving into the configuration example, this section gives a brief overview of the operation of MIB and how it can be applicable to ELMI Address Registration. In Example 13-7, the snmp-server community command is configured on router R1 to allow SNMP Read Only access to the router using the "public" community string. The complete syntax for the snmp-server community command is as follows:

Router(config)#snmp-server community string [view view-name] [ro | rw] [number]

The view option associates the community string with a predefined SNMP view record using the snmp-server view view-name oid-tree {included | excluded} command. The rw option indicates both read and write permission, whereas ro allows only the read option. To enhance security, the number option can be used to associate it with a standard access list configured on the router. Only hosts allowed in the access list are permitted to perform SNMP function with the specified community string.

This section uses the new MIB table defined in Table 13-1 found later in this section for Frame Relay ELMI implemented in the Frame Relay MIB. The MIB is a virtual information storage area for network management information, which consists of collections of managed objects. Within the MIB, collections of related objects are defined in MIB modules. MIB modules are written in the SNMP MIB module language defined in STD 58, RFC 2578, RFC 2579, and RFC 2580.

The SNMP agent contains MIB variables whose values the SNMP manager can request or change through SNMP GET or SET operations. A manager can get a value from an agent or store a value into that agent. The agent gathers data from the MIB, the repository for information about device parameters and network data. The agent can also respond to manager requests to GET or SET data.

The complete Frame Relay MIB, including the Frame Relay ELMI MIB, can be downloaded from the following Cisco FTP site: ftp://ftp.cisco.com/pub/mibs/v2/CISCO-FRAME-RELAY-MIB.my.

The communication relationship between the SNMP manager and agent is shown in Figure 13-5.

Figure 13-5. Communication Between SNMP Agent and Manager

The SNMP manager sends an MIB GET (ro access required) or SET (rw access required) request to the MIB SNMP agent. The MIB SNMP agent then responds to these requests. Optionally, the MIB SNMP agent can be configured to send unsolicited notifications (trap) to the manager to notify the manager of network conditions.

With reference to Figure 13-4 and Example 13-7, Example 13-8 verifies network connectivity between the MIB SNMP agent (router R1) and the SNMP manager (NMS) at 150.1.5.100.

There must be connectivity between R1 and NMS in order to allow the latter to send MIB GET requests to R1 to query the ELMI Address Registration.

Example 13-8. Verifying Connectivity Between R1 and NMS
R1#ping 150.1.5.100

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 150.1.5.100, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms
R1#

Example 13-9 verifies the address registration taking place on R1, as shown by the show frame-relay qos-autosense command.

Example 13-9. show frame-relay qos-autosense Indicating Address Registration Taking Place on R1
R1#show frame-relay qos

ELMI information for interface Serial3/1.100
IP Address used for Address Registration:1.1.1.1 My Ifindex:7
ELMI AR Status:Enabled
 Connected to switch:SWITCH   Platform:IGX   Vendor:CISCO
SW side ELMI AR Status:Enabled
IP Address used by switch for address registration:172.21.202.99 Ifindex:10000010
              (Time elapsed since last update 00:00:20)

 DLCI = 100
 OUT:   CIR 64000        BC 6000         BE 5000         FMIF 4506
 IN:    CIR Unknown      BC Unknown      BE Unknown      FMIF Unknown
 Priority 0     (Time elapsed since last update 00:04:37)

ELMI information for interface Serial3/3.200
IP Address used for Address Registration:1.1.1.1 My Ifindex:9
ELMI AR Status:Enabled
 Connected to switch:SWITCH   Platform:IGX   Vendor:CISCO
SW side ELMI AR Status:Disabled
IP Address used by switch for address registration:0.0.0.0 Ifindex:0
              (Time elapsed since last update 00:00:20)

 DLCI = 200
 OUT:   CIR 64000        BC 6000         BE 5000         FMIF 4506
 IN:    CIR Unknown      BC Unknown      BE Unknown      FMIF Unknown
 Priority 0     (Time elapsed since last update 00:04:37)

In Example 13-9, the output of the show frame-relay qos-autosense command at R1 indicates several parameters of interest to ELMI Address Registration.

In the show output, the parameter indicated by "IP Address used for Address Registration" represents the management IP address used by the router R1 for Address Registration. Checking Example 13-7, the frame-relay address registration ip 1.1.1.1 verifies the output. The corresponding MIB object of IfIndex for Serial3/1 is 7. The MIB object IfIndex represents the collection of all physical and logical interfaces installed or created on the router. Next, the ELMI AR Status on router R1 is shown as Enabled, which is true for both interfaces (DLCI 100 and DLCI 200).

The output further indicates that the directly connected device is an IGX switch platform manufactured by the vendor CISCO. This information can be useful when interoperating with other vendors' switches that support ELMI Address Registration.

The show output also indicates that the ELMI AR status at the switch side is enabled, and the management IP address announced is 172.21.202.99. The information tallies with Figure 13-4 and the configuration example in Example 13-7.

Finally, notice that on Serial3/3.200 for DLCI 200, the ELMI AR status of the switch detected at the router shows Disabled. This is true because, as mentioned earlier, ELMI AR is only enabled on port 11.11 (for DLCI 100) and disabled on port 11.5 (for DLCI 200) of the IGX switch. When ELMI Address Registration is disabled, the switch sends 0.0.0.0 in the IP address field but with a valid IfIndex during version negotiation. Example 13-10 demonstrates the class variables of the cfrElmiEntry class retrieved by the SNMP getmany management utility. This SNMP function is executed on a UNIX workstation setup as a NMS connected to the routers.

Example 13-10. Executing SNMP GET Query on NMS and Resultant Output
Unix>getmany v2 150.1.5.1 public cfrElmiEntry

! MIB GET output:
cfrElmiLinkStatus.7 = 1
cfrElmiLinkStatus.9 = 1
cfrElmiArStatus.7 = 1
cfrElmiArStatus.9 = 1
cfrElmiRemoteStatus.7 = 1
cfrElmiRemoteStatus.9 = 2

Unix>getmany v2 150.1.5.1 public cfrElmiNeighborEntry

! MIB GET output:
cfrElmiNeighborArStatus.7 = 2
cfrElmiNeighborArStatus.9 = 3
cfrElmiNeighborIpAddress.7 = 172.21.202.99
cfrElmiNeighborIpAddress.9 = 0.0.0.0
cfrElmiNeighborIfIndex.7 = 10000010
cfrElmiNeighborIfIndex.9 = 0
cfrElmiNeighborVendorName.7 = CISCO
cfrElmiNeighborVendorName.9 = CISCO
cfrElmiNeighborPlatformName.7 = IGX
cfrElmiNeighborPlatformName.9 = IGX
cfrElmiNeighborDeviceName.7 = SWITCH
cfrElmiNeighborDeviceName.9 = SWITCH

In Example 13-10, the results of the SNMP query performed by the NMS on the router R1 reveal it has two interfaces enabled with ELMI Address Registration. This is indicated by the output cfrElmiArStatus.7 = 1, whereby 1 means enabled and 2 represents disabled. From the information in the cfrElmiNeighborEntry object, you know that router R1 has a neighboring device. The neighbor is a Cisco IGX switch, but only one of its switch ports is enabled for ELMI AR (cfrElmiNeighborArStatus.7 = 1 means not supported, cfrElmiNeighborArStatus.7 = 2 means enabled, and cfrElmiNeighborArStatus.7 = 3 means disabled). The switch-side management IP address is 172.21.202.99, and the corresponding IfIndex is 10000010.

Table 13-1 lists the syntax for some of the ELMI MIB objects shown in this example. Table 13-1 is derived from the complete Frame Relay ELMI MIB list. The complete list of the Frame Relay ELMI MIB objects is available at the following FTP site: ftp://ftp.cisco.com/pub/mibs/v2/CISCO-FRAME-RELAY-MIB.my.

The next example disables the manual AR address configuration by using autoaddress mode. The frame-relay address registration ip command is removed and replaced by the frame-relay address registration auto-address command. The new configurations are shown in Example 13-11.

Example 13-11. Configurations of Router R1 Using Autoaddress Mode
<output omitted>

ip routing
!
frame-relay address registration auto-address
!
interface Serial3/1
 encapsulation frame-relay
 frame-relay traffic-shaping
 frame-relay lmi-type q933a
 frame-relay qos-autosense
!
interface Serial3/1.100 point-to-point
 ip address 172.16.1.1 255.255.255.252
 frame-relay interface-dlci 100
!
interface Serial3/3
 encapsulation frame-relay
 frame-relay traffic-shaping
 frame-relay lmi-type q933a
 frame-relay qos-autosense
!
interface Serial3/3.200 point-to-point
 ip address 172.16.2.1 255.255.255.252
 frame-relay interface-dlci 200
!
interface Ethernet1/0
 ip address 150.1.5.1 255.255.255.0
 !
snmp-server community public RO

In the next example, the frame-relay address registration auto-address command is used to enable the router R1 to automatically select an IP address to use as its management IP address. This command overwrites the frame-relay address registration ip command, if it is configured. However, if there is no valid IP address found, the router or switch does not perform address registration but continues to send the IfIndex.

Example 13-12 shows the show frame-relay qos-autosense output at router R1 after frame-relay address registration auto-address command is enabled.

Example 13-12. show frame-relay qos-autosense Output on Router R1 After Autoaddress Is Configured
R1#show frame-relay qos-autosense interface serial3/1.100

ELMI information for interface Serial3/1.100
IP Address used for Address Registration:150.1.5.1 My Ifindex:7
ELMI AR Status:Enabled
 Connected to switch:SWITCH   Platform:IGX   Vendor:CISCO
SW side ELMI AR Status:Enabled
IP Address used by switch for address registration:172.21.202.99 Ifindex:10000010
              (Time elapsed since last update 00:00:15)

 DLCI = 100
 OUT:   CIR 64000        BC 6000         BE 5000         FMIF 4506
 IN:    CIR Unknown      BC Unknown      BE Unknown      FMIF Unknown
 Priority 0     (Time elapsed since last update 00:00:10)

Example 13-13 shows the show frame-relay qos-autosense output at router R1 after the Ethernet interface is shut down.

Example 13-13. show frame-relay qos-autosense Output on Router R1 After Its Ethernet Interface Is Shut Down
R1#config terminal
Enter configuration commands, one per line.  End with CNTL/Z.
R1(config)#interface ethernet1/0
R1(config-if)#shutdown
R1(config-if)#end
R1#

R1#show frame-relay qos interface serial3/1.100

ELMI information for interface Serial3/1.100
IP Address used for Address Registration:172.16.1.1 My Ifindex:7
ELMI AR Status:Enabled
 Connected to switch:SWITCH   Platform:IGX   Vendor:CISCO
SW side ELMI AR Status:Enabled
IP Address used by switch for address registration:172.21.202.99 Ifindex:10000010
              (Time elapsed since last update 00:00:04)

 DLCI = 100
 OUT:   CIR 64000        BC 6000         BE 5000         FMIF 4506
 IN:    CIR Unknown      BC Unknown      BE Unknown      FMIF Unknown
 Priority 0     (Time elapsed since last update 00:04:22)

When autoaddress mode is used for ELMI Address Registration, the router first selects the management IP address from an Ethernet interface, followed by that of a serial interface, and then any other interfaces. If no address is found, it sends 0.0.0.0 as its AR address.

Example 13-14 shows the final example of this section. In this example, the debug frame-relay lmi command is enabled on router R1 to verify the ELMI status messages exchanged between router R1 and the Cisco IGX switch in Figure 13-4.

Example 13-14. Output Captured by the debug frame-relay lmi Command at Router R1
R1#debug frame-relay lmi
*Sep 25 07:42:33.235: ELMI: sending version status_enquiry message
*Sep 25 07:42:33.235: datagramstart = 0x70014D4, datagramsize = 72
*Sep 25 07:42:33.235: FR encap = 0x00010308
*Sep 25 07:42:33.235: 00 75 51 01 08 09 3D 09 43 69 73 63 6F 20 20 20
*Sep 25 07:42:33.235: 20 20 20 20 20 20 20 37 32 30 36 20 20 20 20 20
*Sep 25 07:42:33.235: 20 20 20 20 20 20 64 74 77 61 31 20 20 20 20 20
*Sep 25 07:42:33.235: 20 20 20 20 20 01 00 00 00 07 AC 10 01 01 00 00
*Sep 25 07:42:33.235: 00 00 00 80
*Sep 25 07:42:33.235:
*Sep 25 07:42:33.243: Serial3/1(in): Status, myseq 0, pak size 72
*Sep 25 07:42:33.243: RT IE 51, length 1, type 8
*Sep 25 07:42:33.243: ELMI: packet received on Serial3/1
*Sep 25 07:42:33.243: datagramstart = 0x714A170, datagramsize = 72
*Sep 25 07:42:33.243: FR encap = 0x00010308
*Sep 25 07:42:33.243: 00 7D 51 01 08 09 3D 09 43 49 53 43 4F 20 20 20
*Sep 25 07:42:33.243: 20 20 20 20 20 20 20 49 47 58 20 20 20 20 20 20
*Sep 25 07:42:33.243: 20 20 20 20 20 20 53 57 49 54 43 48 20 20 20 20
*Sep 25 07:42:33.247: 20 20 20 20 20 02 00 00 00 00 00 00 00 00 00 00
*Sep 25 07:42:33.247: 00 00 00 80
*Sep 25 07:42:33.247:
*Sep 25 07:42:33.247: ELMI: received version status, version type = Enhanced
*Sep 25 07:42:33.247: CISCO           IGX             SWITCH          Disabled 0 0.0.0.0

In Example 13-14, the output relevant to Frame Relay ELMI is highlighted in bold. In the debug frame-relay lmi output in Example 13-14, the first set of debug output captured indicates router R1 (DTE) has sent a version enquiry message to the Cisco IGX switch (DCE). The "01" field indicates ELMI Address Registration is enabled on the router. Next, "00 00 00 07" reflects the ifIndex of the interface (serial3/1.100) of router R1 on which ELMI is running. The value of "07" coincides with the output of the show frame qos int ser3/1.100 command in the previous Example 13-13. Then, "AC 10 01 01" is the hexadecimal value of the IP address (172.16.1.1/24) configured on interface serial3/1.100 of router R1.

The second set of debug output in Example 13-14 reveals the version status message router R1 has received from the Cisco IGX switch. In this case, the value "02" indicates that ELMI Address Registration is supported on the Cisco IGX switch, but it has been disabled by the user.

Table 13-2 summarizes the ELMI Address Registration field descriptions in Example 13-14.

Table 13-2. Representations of the Field Descriptions in Example 13-14

Field

Description

01

Indicates that ELMI Address Registration is enabled. Possible values include:

  • 00 ELMI Address Registration is not supported by the interface.

  • 01 ELMI Address Registration is enabled.

  • 02 ELMI Address Registration is supported, but the user has disabled the exchange of information.

  • 03 Indicates that the DCE has sent an ELMI Address Registration asynchronous version status message. Asynchronous version status messages are sent when the IP address of the DCE is changed.

00 00 00 07

ifIndex of interface serial3/1.100 of router R1.

AC 10 01 01

Management IP address of router R1.


Summary

This chapter introduced the Cisco Frame Relay ELMI feature. The Frame Relay ELMI feature adds new functionalities to existing LMI specifications. The new capabilities provided by the ELMI protocols allows a Cisco router to perform QoS auto-sensing, permitting the router to obtain QoS parameters dynamically from the Frame Relay network. When used in conjunction with features such as Frame Relay Traffic Shaping, the feature is advantageous because it allows Frame Relay users to align their configurations with the service providers' network. Users can therefore base their congestion and traffic management decisions on the derived information.

The Frame Relay ELMI Address Registration functionality allows network administrators to use SNMP MIB to extract the IP address and the IfIndex of devices neighboring its managed device in the Frame Relay network. This benefit allows network administrator to detect and monitor network connectivity between devices, as well as to create a complete topology map of the network.

This chapter explained the configuration tasks and Cisco IOS configuration commands required to configure Frame Relay QoS Autosense and Frame Relay Address Registration on a Cisco router. This chapter also covered the Cisco IOS show and debug commands for monitoring and maintaining Frame Relay ELMI configurations on a Cisco router.

The next chapter discusses the Multilink Frame Relay (FRF.16) feature.


Review Questions

1: | Describe the benefits of using Frame Relay QoS Autosense in setting up the Frame Relay Traffic Shaping feature on a group of Cisco routers.
2: | Describe the purpose of the Frame Relay Address Registration functionality of the Frame Relay ELMI feature.
3: | What happens if a router that does not support Address Registration is connected to a Frame Relay switch that does support Address Registration?
4: | Which IP address on the router is selected as the management IP address if autoaddress registration is used?
5: | In the context of Frame Relay Address Registration, what does the field 01 indicate in the output of the debug frame-relay lmi command when a Cisco router sends out a version status enquiry to its neighbor?


References

  • Cisco IOS Release 11.3 Frame Relay Configuration Guide: http://www.cisco.com/univercd/cc/td/doc/product/software/ios113ed/113ed_cr/wan_c/wcfrelay.htm

  • Cisco IOS Release 12.1(3)T WAN Configuration Guide: http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121newft/121t/121t3/dtfripar.htm

  • Understanding SNMP Support: http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/ffun_c/fcfprt3/fcf014.htm#41460

  • Cisco Frame Relay MIB enhancements: ftp://ftp.cisco.com/pub/mibs/v2/CISCO-FRAME-RELAY-MIB.my


Chapter 14. Multilink Frame Relay (FRF.16)

The Frame Relay Forum Technical Committee released a set of standards specifications in May 2002 to support Multilink Frame Relay for the User-Network Interface (UNI) and the Network-to-Network Interface (NNI). This set of standards, defined in the Frame Relay Forum Implementation Agreement Document Number FRF.16, describes a method that allows a group of Frame Relay physical interfaces to be combined into a single Frame Relay "bundle" to effectively boost the aggregate throughput. FRF.16.1 is the latest version of the Multilink Frame Relay UNI/NNI Implementation Agreement document and the full version of FRF.16.1 is available at http://www.mplsforum.org/frame/Approved/FRF.16/frf16.1.pdf.

This chapter discusses Cisco's implementation of the Multilink Frame Relay feature in its Cisco IOS software. The Multilink Frame Relay feature supported in the Cisco IOS closely follows the specifications outlined in FRF.16 specifications.

In order to fully understand the benefits of the Multilink Frame Relay feature, this chapter first discusses the various problems or issues that are addressed by the feature. It then describes the solutions that are gained through implementation of the Multilink Frame Relay feature, then offers an overview and detailed description of the feature itself. Later in the chapter, a configuration section is presented on enabling the Multilink Frame Relay feature on a Cisco router. Finally, the monitoring and troubleshooting commands for verifying Multilink Frame Relay on a Cisco router are demonstrated.

The topics and questions that this chapter addresses include the following:

  • Overview of Multilink Frame Relay and Frame Relay Forum Implementation Agreement FRF.16

  • Understanding the setup and operation of Multilink Frame Relay

  • Understanding Cisco's implementation of Multilink Frame Relay

  • Configuring Multilink Frame Relay on Cisco routers

  • Monitoring and maintaining Multilink Frame Relay on Cisco routers

After completing this chapter, readers will recognize the purpose of the Multilink Frame Relay feature and will appreciate the benefits of aggregating the bandwidth of separate physical interfaces. Readers will also understand the basic operation of Multilink Frame Relay and the Frame Relay Forum Implementation Agreement FRF.16. Readers will learn the configuration tasks and Cisco IOS configuration commands required to set up Multilink Frame Relay on a Cisco router. Subsequently, readers will find out the relevant Cisco IOS show and debug commands for monitoring and maintaining Multilink Frame Relay on a Cisco router.


Current Issues

Presently, many Frame Relay service providers and customers face the common problem of bandwidth constraints imposed on their Frame Relay circuits. This problem is best explained with an example. A Frame Relay customer might require an intermediate access bandwidth between a T1/E1 (1.544/2.048 Mbps) line and a T3/E3 (45/33 Mbps) line in order to meet user requirements. However, it might not be possible to meet the users' requirements because of the lack of high-speed transmission facilities in some geographical regions. At present, T3/E3 service is not readily available in every part of the world. Moreover, service providers might not be able to offer their customers such services because of certain policies or restrictions. In many cases, the customers are forced to purchase separate T1/E1 lines and combine them to obtain the required aggregate bandwidth level.

Figure 14-1 illustrates an example of the use of multiple separate circuits to attain required bandwidth requirements.

Figure 14-1. Combining Separate Frame Relay Virtual Circuits to Meet Users' Increased Bandwidth Requirements

The method of combining several physical interfaces to attain the required bandwidth level has other restrictions. For example, a customer using multiple physical T1 lines is required to provision separate Frame Relay virtual circuits (VCs) on each T1 line. However, this design introduces a single point of failure in the network, because all VCs provisioned on a particular link are lost if that T1 line goes down.

Furthermore, combining separate lines to attain the required bandwidth can represent an inflexible and inefficient utilization of the pool of available bandwidth. For example, when a burst of traffic causes a particular VC to become congested, the user is unable to redirect the excess traffic to the remaining underutilized lines. This design restricts the packet flow on the congested VC, and subsequently, the overflowing packets are inevitably dropped.


Solutions to Current Issues

The Multilink Frame Relay solution uses a technique very similar to an inverse multiplexer, therefore providing a cost-effective way to increase bandwidth for Frame Relay users. Multilink Frame Relay works at the software level. It allows multiple physical Frame Relay serial interfaces to be combined to form a higher bandwidth virtual bundle. Multilink Frame Relay offers many advantages and benefits that help to resolve the issues discussed in the last section.

First of all, the Multilink Frame Relay feature is a software solution. It offers a more cost-effective way to meet users' increased demand for bandwidth. Multilink Frame Relay offers many benefits to users who live in regions where T3/E3 lines are too expensive to build or very costly to maintain. Multilink Frame Relay is also valuable for Frame Relay users when their local service providers do not offer fractional T1/E1 or T3/E3 services. In both cases, Frame Relay users can use the Multilink Frame Relay feature to combine multiple T1/E1 lines to attain the higher aggregate bandwidth they require.

Multilink Frame Relay also allows more flexible management of a pool of available bandwidth. For instance, depending on users' requirements, network managers can decide on the number of physical interfaces required to form a single Frame Relay bundle. The remaining interfaces and the available bandwidth can be used or allocated for other applications or purposes.

The Multilink Frame Relay feature offers other benefits, such as greater resiliency and traffic load balancing. When multiple physical interfaces are provisioned as a single Frame Relay bundle, the Frame Relay bundle can continue to support the Frame Relay service when one of the physical links fails. When a bundle link fails, active traffic can be dynamically redirected to the remaining bundle links without causing service disruption to the users. For load balancing, when the active bundle link that is used for traffic transmission is busy transmitting a long packet, Multilink Frame Relay can redirect the traffic to other idle bundle links. Load balancing maximizes bandwidth utilization and reduces the latency for delay-sensitive traffic. Therefore, the Multilink Frame Relay design increases resiliency by reducing the single point of failure on the Frame Relay interface and improves bandwidth utilization with flexible load balancing.

Using the Multilink Frame Relay feature to create a logical bundle can decrease Layer 3 routing complexity. Dynamic routing protocols see the Multilink Frame Relay bundle as a single interface rather than as its individual physical interface members. Hence, it is necessary to allocate a single IP subnet to the bundle instead of assigning subnet addresses to each physical interface.

Despite the many benefits of Multilink Frame Relay, there are some downsides to its use. First of all, Frame Relay Fragmentation cannot be supported together with the Multilink Frame Relay feature. The Multilink Frame Relay feature also uses up resources on the router. Every Multilink Frame Relay interface created on a Cisco router requires the allocation of an interface descriptor block (IDB), which consists of hardware IDB and software IDB. The hardware IDB controls the physical interface, whereas the software IDB controls the Layer 2 encapsulation. Take note that the maximum number of IDBs that a platform can support can be verified with the show idb privileged EXEC command.

Refer to Cisco.com (http://www.cisco.com/en/US/products/sw/iosswrel/ps1835/products_tech_note09186a0080094322.shtml) for further details on IDBs on Cisco platforms. The maximum number of Multilink Frame Relay interfaces or bundles that can be created is platform-dependent.

NOTE

Although the Multilink Frame Relay feature is similar to Multilink Point-to-Point Protocol (PPP) in principle, both features are completely different in terms of the functionalities each supports.


Multilink Frame Relay Setup and Operation

Now that the main issues and solutions that are raised through implementation of the Multilink Frame Relay feature have been described, you can put the full benefits of this feature into perspective.

This section discusses the components of the Multilink Frame Relay feature and explains its setup and basic operation.

Multilink Link Integrity Protocol

Multilink Frame Relay uses the Link Integrity Protocol Control messages for link management of the bundle links. The link control messages defined by the Multilink Frame Relay Link Integrity Protocol are exchanged between peers in a three-step process: establishing the link, maintaining the link, and tearing down the link. The basic format of the Multilink Frame Relay Link Integrity Protocol message, as defined in FRF.16, is shown in Figure 14-2.

Figure 14-2. Format of the Multilink Frame Relay Link Integrity Protocol Message

Multilink Frame Relay Link Integrity Protocol Control messages are transmitted in Multilink Frame Relay frames with the Control Bit set to 1. This serves to differentiate a Multilink Frame Relay data packet from a Multilink Frame Relay link control packet. The Begin (B) and End (E) bits in the headers indicate whether fragmentation has occurred. The control messages are sent without fragmentation (Bit B=1 and Bit E=1). The message consists of a Message Type element and multiple variable-length Information Element fields. The Multilink Frame Relay Link Integrity Protocol defines seven control messages for link management. The Message Type field in the Multilink Frame Relay Link Integrity Protocol message identifies the type of control message. The purposes of each Message Type value are described in Table 14-1.

Table 14-1. Values of Message Type Fields in Multilink Frame Relay Link Integrity Protocol Message

Message Type

Description

ADD_LINK

Notifies the peer endpoint that the local endpoint supports frame processing and is ready to become operational

ADD_LINK_ACK

Notifies the peer endpoint that the local endpoint has received a valid ADD_LINK message

ADD_LINK_REJ

Notifies the peer endpoint that the local endpoint has received an invalid ADD_LINK message

HELLO

Notifies the peer endpoint periodically that the local endpoint remains in the UP state

HELLO_ACK

Notifies the peer endpoint that the local endpoint has received a valid HELLO message

REMOVE_LINK

Notifies the peer endpoint that the local endpoint and layer management function is removing the bundle link from bundle operation

REMOVE_LINK_ACK

Notifies the peer endpoint that the local endpoint has received a REMOVE_LINK message

A Multilink Frame Relay Link Integrity Protocol message can consist of one or more Information Element fields, depending on the type of information it carries. Furthermore, Link Integrity Protocol Control messages are exchanged between peers independently on each link of a bundle.

Figure 14-3 shows the basic format of an Information Element field in the Multilink Frame Relay Link Integrity Protocol message. Table 14-2 explains the purpose of the various Information Element fields.

Table 14-2. Information Element Fields in Multilink Frame Relay Link Integrity Protocol

Information Element

Description

Bundle Identification

Provides information used to associate a local endpoint and a remote endpoint of a bundle link

Link Identification

Provides information used to report the identity of a bundle link when error conditions arise at an endpoint

Magic Number

Provides information for looped-back bundle link detection

Reserved

Reserved for future use; not used in this current implementation

Timestamp Information

Represents the time of transmission

Vendor Extension

Includes vendor-specific information

Cause

Used to inform peer endpoints of the reason for the transmission of ADD_LINK_REJ or REMOVE_LINK message

Figure 14-3. Format of the Multilink Frame Relay Link Integrity Protocol Information Element

Initialization and Bundle Setup

This section explains the basic operation involving bundle initialization and setup, management, and tearing down of the bundle link.

Bundle Link Establishment

The ADD_LINK, ADD_LINK_ACK, and ADD_LINK_REJ messages in the Multilink Frame Relay Link Integrity Control Protocol are used to negotiate the setup of a bundle link between two associated peers or endpoints. When a physical interface is configured as a bundle link, the bundle link setup process is invoked, and an ADD_LINK message is sent out to the peer device on the new bundle link. At the same time, the N_MAX_RETRY counter is cleared and the T_ACK timer is started.

The bundle link establishment process is considered complete when an ADD_LINK_ACK message is received. When this happens, the T_ACK timer is reset and the T_HELLO timer is started. The T_HELLO timer is used to pace the exchange of periodic HELLO and HELLO_ACK messages between the peers for bundle management. However, if the T_ACK timer expires before the endpoint receives an ADD_LINK_ACK message, the bundle link endpoint retransmits the ADD_LINK message.

In the event of errors, the ADD_LINK_REJ message is used to indicate that an invalid ADD_LINK message has been received. For example, this can happen when the received bundle identification is not consistent with the bundle identification received from the other bundle link. The ADD_LINK_REJ message contains the cause for the rejection for diagnostic purposes.

Figure 14-4 shows the basic steps involved in establishing a bundle link between two endpoints.

Figure 14-4. Bundle Establishment Between Two Endpoints

Bundle Management

When the bundle link is up, the peers exchange HELLO and HELLO_ACK messages in order to maintain the link. The periodic exchange of the HELLO and HELLO_ACK messages acts as a keepalive mechanism for the link. The HELLO message is used by a local endpoint to notify its peer that the bundle link is in the UP state. Both ends of a bundle link generate this message periodically based on the T_HELLO timer. The T_HELLO timer can be adjusted to control the rate at which HELLO messages are sent out. For example, reducing the value of the T_HELLO timer increases the frequency at which the Multilink peers poll each other. On Cisco routers, the default T_HELLO timer is set to 10 seconds, and the supported range is from 1 to 180 seconds.

On receiving a HELLO message, the remote peer responds with a HELLO_ACK message to indicate that it has received a valid HELLO message. If a peer does not receive a HELLO_ACK message from its peer after the T_HELLO timer expires, it retransmits the HELLO message, up to the maximum number of attempts specified by the N_MAX_RETRY counter. On Cisco routers, the N_MAX_RETRY counter is set to two tries, and the configurable range is from one to five tries.

Tearing Down the Bundle Link

The Multilink Frame Relay Link Integrity Protocol also specifies a set of rules for tearing down the bundle link. The REMOVE_LINK and REMOVE_LINK_ACK control messages are used to notify the remote peer that the local peer is removing the bundle link from bundle operation. A bundle link can be brought down by configurations. In this case, the bundle link sends a REMOVE_LINK message to its peer that it is releasing this bundle link member interface. On receiving the REMOVE_LINK message, the peer responds with the REMOVE_LINK_ACK message to indicate that it has received the REMOVE_LINK message request. At this time, the endpoint resets the N_MAX_RETRY counter, starts the T_ACK timer, and enters the idle state.

However, if the peer sending out the REMOVE_LINK message does not receive a REMOVE_LINK_ACK message from its peer before its T_ACK timer expires, it retransmits the REMOVE_LINK message up to the maximum number of attempts specified in the N_MAX_RETRY counter. If the local peer tearing down the bundle link does not receive the REMOVE_LINK_ACK message from its peer after the N_MAX_RETRY counter is exceeded, it continues to deactivate the bundle link at its local end.

Multilink Frame Relay System Parameters

The FRF.16 specification defines three system parameters for the basic Multilink Frame Relay operation. As mentioned, these parameters are the T_HELLO timer, the T_ACK timer, and the N_MAX_RETRY counter. The T_HELLO timer is used to control the rate at which HELLO messages are sent out for link management. The T_ACK timer indicates the period for which the peer should wait for ADD_LINK_ACK, HELLO_ACK, or REMOVE_LINK_ACK messages. Finally, the N_MAX_RETRY counter specifies the maximum number of retransmission attempts for HELLO or REMOVE_LINK messages after the T_ACK timer has expired.

Table 14-3 shows the default values of the Multilink Frame Relay system parameters. It is recommended to use the default values for the Multilink system parameters.

Table 14-3. Default Values of the Multilink Frame Relay System Parameters

System Parameter

Default Value

Minimum Value

Maximum Value

T_HELLO

10 seconds

1 second

180 seconds

T_ACK

4 seconds

1 second

10 seconds

N_MAX_RETRY

2 tries

1 try

5 tries


Cisco Implementation of Multilink Frame Relay

This section takes a closer look at Cisco's implementation of the Multilink Frame Relay feature in its Cisco IOS software.

Cisco's implementation of the Multilink Frame Relay feature is compliant with the Frame Relay Forum's FRF.16 standard specifications.

NOTE

The Multilink Frame Relay feature is released in Cisco IOS 12.2(8)T. It is supported on c2600, c3600, c3700, and c7200 series routers. The following Cisco Connection Online (CCO) site also lists the Cisco platforms supported by this feature: http://www.cisco.com/en/US/products/sw/iosswrel/ps1839/products_feature_guide09186a0080087cbf.html#1042570.

Note that Cisco's current phase of the Multilink Frame Relay feature implementation has the following restrictions:

  • ISDN interface and any other type of virtual interfaces cannot become part of the bundle link.

  • Frame Relay fragmentation (FRF.12) is not supported. Hence, the Multilink frames cannot be transmitted in fragments.

  • Multilink Frame Relay MIB (RFC 3020) is not supported.

  • FRF.9 hardware compression over Multilink Frame Relay is not supported.

  • The number of bundles that can be supported on a router is platform-dependent.

The FRF.16 specifications define four different classes of bandwidth (A, B, C, and D) to represent the trigger point of activating or deactivating the bundle. Class A is the default class of bandwidth. It brings up the bundle as long as one bundle link is active, and it brings down the bundle only when all bundle links are down. By contrast, Class B brings up the bundle only when all bundle links are up, and it brings down the bundle as long as one bundle link goes down. Class C is based on threshold, and Class D is implementation-specific. Cisco currently fully supports Class A, and it complies with the Class A bandwidth requirements in FRF.16. The remaining classes of bandwidth are not supported by Cisco in this phase of the Multilink Frame Relay implementation. For this reason, Classes B, C, and D are not addressed in this text.

The next section discusses the creation and use of the Multilink Frame Relay bundle interface involving its bundle links on Cisco routers.

Definition of Multilink Frame Relay Interface and Bundle Links

A new virtual interface type was created in the Cisco IOS software in order to support the new Multilink Frame Relay feature. The Multilink Frame Relay interface is a multilink Frame Relay bundle interface, or logical interface. The Multilink Frame Relay interface is used to represent the bundle on which the Frame Relay data link protocols run and all Frame Relay VCs are built. In a nutshell, the Multilink Frame Relay interface emulates a physical interface for the transport of frames.

The bundle comprises two or more physical serial links, called bundle links. The bundle links are transparent to the Frame Relay data link layer, and thus, Frame Relay functionality cannot be enabled on them. On the other hand, Frame Relay functionality must be configured on the master bundle interface (Multilink Frame Relay interface). After the master bundle interface is created, the peer devices exchange Multilink Frame Relay Link Integrity Protocol Control messages to monitor the operation of the bundle links. Because more than one bundle interface can be created, the Multilink Frame Relay Link Integrity Protocol Control messages also serve to synchronize which bundle links should be associated with which bundles. The Multilink Frame Relay interface, or master bundle interface, is configured on a Cisco router with the following global configuration command:

Router(config)#interface mfr mfr-number

An Multilink Frame Relay interface supports Cisco or IETF Frame Relay encapsulations. The default Frame Relay encapsulation of the Multilink Frame Relay interface is Cisco. No other encapsulation types are allowed on the Multilink Frame Relay interface. To use Multilink Frame Relay between a Cisco device and a non-Cisco device, the IETF Frame Relay encapsulation type should be used. The regular Frame Relay supported functionalities can be configured directly on the Multilink Frame Relay interface or subinterface.

To associate a physical serial interface with the Multilink Frame Relay interface, the following interface level configuration command is used:

Router(config-if)#encapsulation frame-relay mfr mfr-number

This command configures the selected physical interface as an Multilink Frame Relay bundle link associated with the Multilink Frame Relay interface specified in the mfr-number parameter.


Configuring Multilink Frame Relay on Cisco Routers

This section looks at the configuration tasks required to configure the Multilink Frame Relay feature on a Cisco router. In addition, all Multilink Frame Relay-related commands supported by the Cisco IOS are discussed.

The following procedures outline the steps required to create a bundle interface, configure the physical serial interfaces as bundle links, and associate the bundle links with the bundle interface. The optional configuration commands for tuning Multilink Frame Relay parameters on a Cisco router running Multilink Frame Relay are also explained.

Step 1. | Beginning in the global configuration mode, configure a Multilink Frame Relay bundle interface with the interface mfr number global configuration command. This creates a logical Multilink Frame Relay interface that represents the bundle.
Step 2. | Determine the physical Frame Relay serial interfaces to be configured as the bundle links and associated with the bundle interface. Select the physical interface and enter the interface configuration mode.
Step 3. | Configure the physical Frame Relay serial interface as a bundle link with the encapsulation frame-relay mfr number interface configuration command. The Multilink Frame Relay number parameter in the command is used to associate the bundle link with the bundle interface created. The number parameter must match the bundle interface number created.
Step 4. | (optional) The bundle interface can be assigned a Bundle Identification Name (BID) with the frame-relay multilink bid name bundle interface configuration command. This name is used to identify the bundle to the peer router so that the peer can synchronize itself with the local router. This command can only be configured at the Multilink Frame Relay interface. By default, the name of the Multilink Frame Relay interface is the "Multilink Frame Relay<number>" string.
Step 5. | (optional) The bundle link can be assigned a Link Identification Name (LID) with the frame-relay multilink lid name interface configuration command. The name is used to identify the bundle link to the peer router so that the peer can synchronize its physical link with the local router. The name can be up to 50 characters of alphanumeric and special characters. By default, the LID name is the physical interface name.

Tuning Multilink Frame Relay Parameters

This section describes a few optional configuration commands for tuning Multilink Frame Relay behavior on a Cisco router.

Step 1. | The frame-relay multilink output-threshold bytes interface configuration command is an optional command. This command can be configured at the bundle interface or the bundle link level. When the command is enabled at the bundle interface level, all associated bundle links inherit the configured value. With this command, when a bundle link has transmitted at least the number of configured bytes, the next nonbusy bundle link in the bundle is used. The default value is 300 bytes.
Step 2. | The frame-relay multilink hello seconds interface configuration command is used to adjust the interval at which a bundle link sends out HELLO messages. The default value is 10 seconds (refer to Table 14-2).
Step 3. | The frame-relay multilink ack seconds interface configuration command is used to adjust the number of seconds a bundle link waits for a HELLO_ACK message before it retransmits the HELLO message. The default value is 4 seconds.
Step 4. | The frame-relay multilink retry number interface configuration command is used to configure the maximum number of retries for which the router resends a HELLO message while waiting for the HELLO_ACK. The default value is 2 tries.

Load Balancing Effectively Across the Bundle Links

As discussed earlier, the default value for the frame-relay multilink output-threshold command is 300 bytes. Note that the no form of the frame-relay multilink output-threshold command does not disable or turn off the command. The no form of the command merely resets the threshold to its default 300 bytes.

In situations where the true physical access speeds of the individual bundle links are identical or very close, load balancing can occur across the bundle links in the bundle without much user intervention. When a particular heavily loaded bundle link is busy transmitting a large packet, the load balancing mechanism rolls over to the next waiting bundle link. Without changing the default value of the frame-relay multilink output-threshold command, the number of bytes a bundle link transmits before rolling over to the next bundle link is 300 bytes.

On the contrary, in situations where the physical access speeds of individual bundle links vary greatly, the frame-relay multilink output-threshold command should be used to adjust the number of bytes each bundle link can transmit. To efficiently use the varied access speeds of the bundle links, the higher-speed bundle links should be configured with a proportionately larger transmit size. This should be taken into consideration to ensure load balancing works effectively across the bundle links.

The operation of the Multilink Frame Relay feature enabled on Cisco routers is covered with the help of some configuration examples. For the purpose of this discussion, the Frame Relay network illustrated in Figure 14-5 is used.

Figure 14-5. Frame Relay Network Used to Monitor Multilink Frame Relay Operation

Figure 14-5 presents a simple scenario where Multilink Frame Relay can become very useful. In the network depicted in Figure 14-5, a typical customer connects its remote spoke office to its central hub office via a Frame Relay service provider. In this hub-and-spoke topology, the central hub site is connected to the provider's Frame Relay network via a high-speed T3 access link. Because of a surge in users' demand for more bandwidth, the customer has decided to purchase additional access links to cater to that need. However, in some situations, a T3 line might not be readily available in many regions. Likewise, the cost of a T3 line for a remote spoke office might prove to be too expensive. Under these circumstances, the customer can purchase an additional T1 line and make use of the Multilink Frame Relay feature to achieve the aggregate bandwidth required.

NOTE

The Cisco IOS Release used for these examples is 12.2(8)T. Note that different IOS releases might have slightly varying display output compared with what is observed in these examples.

Example 14-1 shows the running configurations of the routers illustrated in Figure 14-5.

Example 14-1. Running Configurations of R1 and R2 in Figure 14-5
! R1

<output omitted>

ip routing
!
interface MFR0
 no ip address
!
interface MFR0.1 point-to-point
 ip address 172.16.1.1 255.255.255.0
 frame-relay interface-dlci 103
!
interface Serial0
 no ip address
 encapsulation frame-relay MFR0
!
interface Serial3
 no ip address
 encapsulation frame-relay MFR0

! R2

<output omitted>

frame-relay switching
!
interface MFR0
 no ip address
 frame-relay intf-type dce
!
interface Serial3/0
 no ip address
 encapsulation frame-relay
 frame-relay intf-type dce
!
interface Serial3/3
 no ip address
 encapsulation frame-relay MFR0
!
interface Serial4/3
 no ip address
 encapsulation frame-relay MFR0
!
connect MFR MFR0 103 Serial3/0 301

! R3

<output omitted>

ip routing
!
interface Serial1/1
 no ip address
 encapsulation frame-relay
!
interface Serial1/1.1 point-to-point
 ip address 172.16.1.2 255.255.255.0
 frame-relay interface-dlci 301

As shown in Example 14-1, Multilink Frame Relay is configured between R1 and the service provider's Frame Relay switch R2 (a Cisco router configured with the Frame Relay switching feature). A bundle interface is created on each of the R1 and R2 routers. On R1, the bundle links that are configured as members of the bundle are serial0 and serial3. Similarly, serial3/3 and serial4/3 are the bundle links belonging to the bundle interface created on R2. After the bundle interface's status is in the UP state, only the master bundle interface is visible to the peers at the endpoints. The bundle links are transparent, and legacy Frame Relay functionalities are now configured on the bundle interface. The bundle interface acts like a normal Frame Relay serial interface, and logical subinterfaces can be created, as shown in the configuration example.

At R2, the Frame Relay switch provisions a Frame Relay connection between DLCI 103, on the Multilink Frame Relay interface, and DLCI 301, the T3 uplink connected to the router R3 at the central office.

An extended ping test is performed from router R1 to router R3 via the Multilink bundle. The extended ping, contents of the route table at R1, and the display of the show frame-relay map command are shown in Example 14-2.

Example 14-2. Connectivity Test Between R1 and R3 by Sending Packets Through the Bundle
R1#show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
       i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
       * - candidate default, U - per-user static route, o - ODR
       P - periodic downloaded static route

Gateway of last resort is not set

     172.16.0.0/24 is subnetted, 1 subnets
C       172.16.1.0 is directly connected, MFR0.1

R1#show frame-relay map
MFR0.1 (up): point-to-point dlci, dlci 103(0x67,0x1870), broadcast
status defined, active

R1#ping
Protocol [ip]:
Target IP address: 172.16.1.2
Repeat count [5]: 10
Datagram size [100]: 1500
Timeout in seconds [2]:
Extended commands [n]:
Sweep range of sizes [n]:
Type escape sequence to abort
Sending 10, 1500-byte ICMP Echos to 172.16.1.2, timeout is 2 seconds:
!!!!!!!!!!
Success rate is 100 percent (10/10), round-trip min/avg/max = 392/393/396 ms

Recall that earlier in this chapter, it was mentioned that Frame Relay is the only encapsulation allowed for the Multilink Frame Relay interface. Example 14-3 verifies this. Likewise, observe in the same example that Cisco Frame Relay encapsulation is the default, but IETF Frame Relay encapsulation is also supported.

Example 14-3. Encapsulation Type Allowed for Multilink Frame Relay Interface
R1#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z
R1(config)#interface mfr0
R1(config-if)#encapsulation ?
  frame-relay  Frame Relay networks

R1(config-if)#encapsulation frame-relay ?
  ietf  Use RFC1490/RFC2427 encapsulation
  <cr>

The Frame Relay commands available to the Multilink Frame Relay interface are shown in Example 14-4. Compare this with the Frame Relay commands configurable under a regular Frame Relay serial interface in Example 14-5. From both examples, you should notice that both the regular serial interface setup with Frame Relay encapsulation and the virtual Multilink Frame Relay interface support the same set of Frame Relay commands.

Example 14-4. Frame Relay Commands Available to an Multilink Frame Relay Interface
R1(config)#interface mfr0
R1(config-if)#frame-relay ?
  address-reg            ELMI address registration
  broadcast-queue        Define a broadcast queue and transmit rate
  class                  Define a map class on the interface
  congestion-management  Enable Frame Relay congestion management
  de-group               Associate a DE group with a DLCI
  interface-dlci         Define a DLCI on an interface/subinterface
  interface-queue        configure PVC interface queueing
  intf-type              Configure a FR DTE/DCE/NNI interface
  inverse-arp            Enable/disable inverse ARP on a DLCI
  ip                     Frame Relay Internet Protocol config commands
  lapf                   set LAPF parameter
  lmi-n391dte            set full status polling counter
  lmi-n392dce            LMI error threshold
  lmi-n392dte            LMI error threshold
  lmi-n393dce            set LMI monitored event count
  lmi-n393dte            set LMI monitored event count
  lmi-t392dce            set DCE polling verification timer
  lmi-type               Use CISCO-ANSI-CCITT type LMI
  local-dlci             Set source DLCI when LMI is not supported
  map                    Map a protocol address to a DLCI address
  multicast-dlci         Set DLCI of a multicast group
  multilink              Set Multilink FR parameters
  payload-compression    Use payload compression
  policing               Enable Frame Relay policing
  priority-dlci-group    Define a priority group of DLCIs
  qos-autosense          enable QOS autosense
  route                  frame relay route for pvc switching
  svc                    Enable frame relay SVCs
  traffic-shaping        Enable Frame Relay Traffic Shaping
  traps-maximum          set max traps FR generates at link up or when getting
                         LMI Full Status message

Example 14-5. Frame Relay Commands Available to a Regular Frame Relay Serial Interface
R1(config)#interface serial2
R1(config-if)#frame-relay ?
  address-reg            ELMI address registration
  broadcast-queue        Define a broadcast queue and transmit rate
  class                  Define a map class on the interface
  congestion-management  Enable Frame Relay congestion management
  de-group               Associate a DE group with a DLCI
  interface-dlci         Define a DLCI on an interface/subinterface
  interface-queue        configure PVC interface queueing
  intf-type              Configure a FR DTE/DCE/NNI interface
  inverse-arp            Enable/disable inverse ARP on a DLCI
  ip                     Frame Relay Internet Protocol config commands
  lapf                   set LAPF parameter
  lmi-n391dte            set full status polling counter
  lmi-n392dce            LMI error threshold
  lmi-n392dte            LMI error threshold
  lmi-n393dce            set LMI monitored event count
  lmi-n393dte            set LMI monitored event count
  lmi-t392dce            set DCE polling verification timer
  lmi-type               Use CISCO-ANSI-CCITT type LMI
  local-dlci             Set source DLCI when LMI is not supported
  map                    Map a protocol address to a DLCI address
  multicast-dlci         Set DLCI of a multicast group
  payload-compression    Use payload compression
  policing               Enable Frame Relay policing
  priority-dlci-group    Define a priority group of DLCIs
  qos-autosense          enable QOS autosense
  route                  frame relay route for pvc switching
  svc                    Enable frame relay SVCs
  traffic-shaping        Enable Frame Relay Traffic Shaping
  traps-maximum          set max traps FR generates at link up or when getting
                         LMI Full Status message


Monitoring and Troubleshooting Multilink Frame Relay

This section discusses the various show commands for monitoring and maintaining Multilink Frame Relay on a Cisco router. The end of this section looks at the IOS debug commands available for troubleshooting Multilink Frame Relay. The network diagram portrayed in Figure 14-1 and the base configurations shown in Example 14-1 are used for this discussion.

Example 14-6 shows the output of the show interface mfr [mfr_number] command. This is executed on router R1 after the bundle interface has been created.

Example 14-6. Output of the show interface mfr Command at R1
R1#show interface mfr0
MFR0 is up, line protocol is up
  Hardware is Multilink Frame Relay bundle interface
  MTU 1500 bytes, BW 100000 Kbit, DLY 100000 usec,
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation FRAME-RELAY, loopback not set
  Keepalive set (10 sec)
  DTR is pulsed for 2 seconds on reset
  LMI enq sent  781, LMI stat recvd 777, LMI upd recvd 0, DTE LMI up
  LMI enq recvd 10, LMI stat sent  0, LMI upd sent  0
  LMI DLCI 1023  LMI type is CISCO  frame relay DTE
  FR SVC disabled, LAPF state down
  Broadcast queue 0/64, broadcasts sent/dropped 96/0, interface broadcasts 0
  Last input 00:00:07, output never, output hang never
  Last clearing of "show interface" counters 02:11:37
  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
  Queueing strategy: fifo
  Output queue :0/120 (size/max)
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
     902 packets input, 59517 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
     898 packets output, 57829 bytes, 0 underruns
     0 output errors, 0 collisions, 0 interface resets
     0 output buffer failures, 0 output buffers swapped out
     0 carrier transitions

From the show output in Example 14-6, observe that the interface is a Multilink Frame Relay bundle interface, and LMI packets are being exchanged on the Multilink Frame Relay interface. Compare this with the show interface output of one of the bundle links (physical serial interface) in Example 14-7.

Example 14-7. show interface Output of a Bundle Link
R1#show interface serial0
Serial0 is up, line protocol is up
  Hardware is HD64570
  MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec,
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation FRAME-RELAY, loopback not set
  Bundle Link of bundle MFR0
  Last input 00:00:05, output 00:00:05, output hang never
  Last clearing of "show interface" counters 02:40:36
  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
  Queueing strategy: fifo
  Output queue :0/40 (size/max)
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
     2466 packets input, 55992 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
     2467 packets output, 54252 bytes, 0 underruns
     0 output errors, 0 collisions, 2 interface resets
     0 output buffer failures, 0 output buffers swapped out
     5 carrier transitions
DCD=up  DSR=up  DTR=up  RTS=up  CTS=up

The output in Example 14-7 indicates that the bundle link (physical serial interface 0) is a member of the bundle MFR0.

The show frame-relay multilink command allows information of the Multilink Frame Relay interface and the associated bundle links to be displayed. The show frame-relay multilink command also offers other options. The detailed option provides the most information to the user, which includes the status of the bundle interface, the number of bundle links configured under the bundle, the name of the bundle identification and bundle link identifications, and detailed information of the Multilink Frame Relay Link Integrity Protocol Control messages exchanged. Example 14-8 shows the options available to the show frame-relay multilink command and a sample output of show frame-relay multilink detailed executed at R1.

Example 14-8. Output of show frame-relay multilink detailed Command at R1
R1#show frame-relay multilink ?
  Multilink Frame Relay       Multilink Frame Relay bundle interface
  Serial    Serial
  detailed  Detailed mfr interface info
  |         Output modifiers
  <cr>

R1#show frame-relay multilink detailed
Bundle: MFR0, State = up, class = A, fragmentation disabled
 BID = MFR0
 No. of bundle links = 2, Peer's bundle-id = MFR0
 Bundle links:

  Serial0, HW state = up, link state = Up, LID = Serial0
    Cause code = none, Ack timer = 4, Hello timer = 10,
    Max retry count = 2, Current count = 0,
    Peer LID = Serial4/3, RTT = 4 ms
    Statistics:
    Add_link sent = 2, Add_link rcv'd = 1,
    Add_link ack sent = 1, Add_link ack rcv'd = 2,
    Add_link rej sent = 0, Add_link rej rcv'd = 0,
    Remove_link sent = 0, Remove_link rcv'd = 0,
    Remove_link_ack sent = 0, Remove_link_ack rcv'd = 0,
    Hello sent = 1105, Hello rcv'd = 1106,
    Hello_ack sent = 1106, Hello_ack rcv'd = 1105,
    outgoing pak dropped = 0, incoming pak dropped = 0

  Serial3, HW state = up, link state = Up, LID = Serial3
    Cause code = none, Ack timer = 4, Hello timer = 10,
    Max retry count = 2, Current count = 0,
    Peer LID = Serial3/3, RTT = 4 ms
    Statistics:
    Add_link sent = 2, Add_link rcv'd = 1,
    Add_link ack sent = 1, Add_link ack rcv'd = 2,
    Add_link rej sent = 0, Add_link rej rcv'd = 0,
    Remove_link sent = 0, Remove_link rcv'd = 0,
    Remove_link_ack sent = 0, Remove_link_ack rcv'd = 0,
    Hello sent = 1106, Hello rcv'd = 1107,
    Hello_ack sent = 1107, Hello_ack rcv'd = 1106,
outgoing pak dropped = 0, incoming pak dropped = 0

Example 14-9 shows the corresponding output of the show frame-relay multilink detailed command executed at R2.

Example 14-9. Output of show frame-relay multilink detailed Command at R2
R2#show frame-relay multilink detailed
Bundle: MFR0, State = up, class = A, fragmentation disabled
 BID = MFR0
 No. of bundle links = 2, Peer's bundle-id = MFR0
 Bundle links:

  Serial4/3, HW state = up, link state = Up, LID = Serial4/3
    Cause code = none, Ack timer = 4, Hello timer = 10,
    Max retry count = 2, Current count = 0,
    Peer LID = Serial0, RTT = 4 ms
    Statistics:
    Add_link sent = 2, Add_link rcv'd = 2,
    Add_link ack sent = 2, Add_link ack rcv'd = 1,
    Add_link rej sent = 0, Add_link rej rcv'd = 0,
    Remove_link sent = 0, Remove_link rcv'd = 0,
    Remove_link_ack sent = 0, Remove_link_ack rcv'd = 0,
    Hello sent = 1135, Hello rcv'd = 1134,
    Hello_ack sent = 1134, Hello_ack rcv'd = 1135,
    outgoing pak dropped = 0, incoming pak dropped = 0

  Serial3/3, HW state = up, link state = Up, LID = Serial3/3
    Cause code = none, Ack timer = 4, Hello timer = 10,
    Max retry count = 2, Current count = 0,
    Peer LID = Serial3, RTT = 4 ms
    Statistics:
    Add_link sent = 2, Add_link rcv'd = 2,
    Add_link ack sent = 2, Add_link ack rcv'd = 1,
    Add_link rej sent = 0, Add_link rej rcv'd = 0,
    Remove_link sent = 0, Remove_link rcv'd = 0,
    Remove_link_ack sent = 0, Remove_link_ack rcv'd = 0,
    Hello sent = 1136, Hello rcv'd = 1135,
    Hello_ack sent = 1135, Hello_ack rcv'd = 1136,
    outgoing pak dropped = 0, incoming pak dropped = 0

In the next example, the bundle identification and bundle link identification are assigned to the bundle interface and bundle links, respectively. This is achieved with the frame-relay multilink bid name and frame-relay multilink lid name configuration commands. Note that as shown in Example 14-8 and Example 14-9, the default bundle identification is the name of the Multilink Frame Relay interface created and the default bundle link identification is the name of the member physical serial interface.

The bid and lid are changed by adding the frame-relay multilink bid and frame-relay multilink lid commands to the base configurations in Example 14-1. The resultant configurations of the new commands are shown in Example 14-10.

Example 14-10. Assigning bid and lid to the Bundle Interface and Bundle Links at R1
R1#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z
R1(config)#interface mfr0
R1(config-if)#frame-relay multilink bid Multilink Frame Relay_BUNDLE
R1(config-if)#exit
R1(config)#interface Serial0
R1(config-if)#frame-relay multilink lid REMOTE_LINK_1
R1(config-if)#interface Serial3
R1(config-if)#frame-relay multilink lid REMOTE_LINK_2
R1(config-if)#end
R1#

R1#show running-config

<output omitted>
!
interface MFR0
 no ip address
 frame-relay multilink bid Multilink Frame Relay_BUNDLE
!
interface MFR0.1 point-to-point
 ip address 172.16.1.1 255.255.255.0
 frame-relay interface-dlci 103
!
interface Serial0
 no ip address
 encapsulation frame-relay MFR0
 frame-relay multilink lid REMOTE_LINK_1
!
interface Serial3
 no ip address
 encapsulation frame-relay MFR0
 frame-relay multilink lid REMOTE_LINK_2

Example 14-11 shows the output of the show frame-relay multilink detailed command at R2 after the bid and lid are changed at R1. Note that R2 still shows the same output as in Example 14-9. In order for the changes to go into effect, reset the Multilink Frame Relay interface by performing a shut, followed by a no shut.

Example 14-11. Output of show frame-relay multilink detailed at R2 After Changing bid and lid at R1
R2#show frame-relay multilink detailed
Bundle: MFR0, State = up, class = A, fragmentation disabled
 BID = MFR0
 No. of bundle links = 2, Peer's bundle-id = MFR0
 Bundle links:

  Serial4/3, HW state = up, link state = Up, LID = Serial4/3
    Cause code = none, Ack timer = 4, Hello timer = 10,
    Max retry count = 2, Current count = 0,
    Peer LID = Serial0, RTT = 4 ms
    Statistics:
    Add_link sent = 2, Add_link rcv'd = 2,
    Add_link ack sent = 2, Add_link ack rcv'd = 1,
    Add_link rej sent = 0, Add_link rej rcv'd = 0,
    Remove_link sent = 0, Remove_link rcv'd = 0,
    Remove_link_ack sent = 0, Remove_link_ack rcv'd = 0,
    Hello sent = 1220, Hello rcv'd = 1219,
    Hello_ack sent = 1219, Hello_ack rcv'd = 1220,
    outgoing pak dropped = 0, incoming pak dropped = 0

  Serial3/3, HW state = up, link state = Up, LID = Serial3/3
    Cause code = none, Ack timer = 4, Hello timer = 10,
    Max retry count = 2, Current count = 0,
    Peer LID = Serial3, RTT = 4 ms
    Statistics:
    Add_link sent = 2, Add_link rcv'd = 2,
    Add_link ack sent = 2, Add_link ack rcv'd = 1,
    Add_link rej sent = 0, Add_link rej rcv'd = 0,
    Remove_link sent = 0, Remove_link rcv'd = 0,
    Remove_link_ack sent = 0, Remove_link_ack rcv'd = 0,
    Hello sent = 1221, Hello rcv'd = 1220,
    Hello_ack sent = 1220, Hello_ack rcv'd = 1221,
outgoing pak dropped = 0, incoming pak dropped = 0

The show frame-relay multilink detailed command is executed again at R2 after performing a shut/no shut at R1. The whole process is illustrated in Example 14-12.

Example 14-12. Resetting the Multilink Frame Relay Interface at R1 in Order for Changes to bid and lid to Kick In
R1#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z
R1(config)#interface mfr0
R1(config-if)#shutdown
R1(config-if)#no shutdown
R1(config-if)#end

R2#show frame-relay multilink detailed
Bundle: MFR0, State = up, class = A, fragmentation disabled
 BID = MFR0
 No. of bundle links = 2, Peer's bundle-id = Multilink Frame Relay_BUNDLE
 Bundle links:

  Serial4/3, HW state = up, link state = Up, LID = Serial4/3
    Cause code = none, Ack timer = 4, Hello timer = 10,
    Max retry count = 2, Current count = 0,
    Peer LID = REMOTE_LINK_1, RTT = 12 ms
    Statistics:
    Add_link sent = 3, Add_link rcv'd = 3,
    Add_link ack sent = 3, Add_link ack rcv'd = 2,
    Add_link rej sent = 0, Add_link rej rcv'd = 0,
    Remove_link sent = 0, Remove_link rcv'd = 1,
    Remove_link_ack sent = 1, Remove_link_ack rcv'd = 0,
    Hello sent = 1233, Hello rcv'd = 1231,
    Hello_ack sent = 1231, Hello_ack rcv'd = 1233,
    outgoing pak dropped = 0, incoming pak dropped = 0

  Serial3/3, HW state = up, link state = Up, LID = Serial3/3
    Cause code = none, Ack timer = 4, Hello timer = 10,
    Max retry count = 2, Current count = 0,
    Peer LID = REMOTE_LINK_2, RTT = 12 ms
    Statistics:
    Add_link sent = 3, Add_link rcv'd = 3,
    Add_link ack sent = 3, Add_link ack rcv'd = 2,
    Add_link rej sent = 0, Add_link rej rcv'd = 0,
    Remove_link sent = 0, Remove_link rcv'd = 1,
    Remove_link_ack sent = 1, Remove_link_ack rcv'd = 0,
    Hello sent = 1234, Hello rcv'd = 1232,
    Hello_ack sent = 1232, Hello_ack rcv'd = 1234,
outgoing pak dropped = 0, incoming pak dropped = 0

The next example looks at the configuration commands for tuning the Multilink Frame Relay system parameters. These are the frame-relay multilink hello seconds, frame-relay multilink ack seconds, and frame-relay multilink retry number interface configuration commands. Observe in the show frame-relay multilink detailed command output in Example 14-12 that the default values are 10 seconds, 4 seconds, and 2 tries, respectively.

Example 14-13 shows the configuration command executed at R2 for adjusting the default system parameters.

Example 14-13. Adjusting the Default System Parameters
R2#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z
R2(config)#interface s3/3
R2(config-if)#frame-relay multilink hello 30
R2(config-if)#frame-relay multilink retry 1
R2(config-if)#frame-relay multilink ack 2
R2(config-if)#end
R2#

R2#show frame-relay multilink detailed
Bundle: MFR0, State = up, class = A, fragmentation disabled
 BID = MFR0
 No. of bundle links = 2, Peer's bundle-id = Multilink Frame Relay_BUNDLE
 Bundle links:

  Serial4/3, HW state = up, link state = Up, LID = Serial4/3
    Cause code = none, Ack timer = 4, Hello timer = 10,
    Max retry count = 2, Current count = 0,
    Peer LID = REMOTE_LINK_1, RTT = 4 ms
    Statistics:
    Add_link sent = 4, Add_link rcv'd = 5,
    Add_link ack sent = 4, Add_link ack rcv'd = 3,
    Add_link rej sent = 0, Add_link rej rcv'd = 0,
    Remove_link sent = 0, Remove_link rcv'd = 1,
    Remove_link_ack sent = 1, Remove_link_ack rcv'd = 0,
    Hello sent = 1318, Hello rcv'd = 1315,
    Hello_ack sent = 1315, Hello_ack rcv'd = 1315,
    outgoing pak dropped = 0, incoming pak dropped = 0

  Serial3/3, HW state = up, link state = Up, LID = Serial3/3
    Cause code = none, Ack timer = 2, Hello timer = 30,
    Max retry count = 1, Current count = 0,
    Peer LID = REMOTE_LINK_2, RTT = 4 ms
    Statistics:
    Add_link sent = 3, Add_link rcv'd = 3,
    Add_link ack sent = 3, Add_link ack rcv'd = 2,
    Add_link rej sent = 0, Add_link rej rcv'd = 0,
    Remove_link sent = 0, Remove_link rcv'd = 1,
    Remove_link_ack sent = 1, Remove_link_ack rcv'd = 0,
    Hello sent = 1313, Hello rcv'd = 1317,
    Hello_ack sent = 1317, Hello_ack rcv'd = 1313,
outgoing pak dropped = 0, incoming pak dropped = 0

The output of the show frame-relay multilink detailed command reflects the new system parameters (ACK = 2, Hello = 30, and retry = 1) after the commands are configured on the second bundle link at R2. The configuration commands undertaken in Example 14-13 at R2 only affect the individual bundle link where they are configured. They do not affect the other bundle links in the bundle.

NOTE

It is recommended to keep the system parameter values at their default unless it becomes absolutely necessary to change them.

Verifying Resiliency Across a Bundle

One of the main functionalities of the Multilink Frame Relay feature is the ability to failover to an alternate bundle link in the bundle should a bundle link go down. Referring again to the diagram in Figure 14-5, you can verify resiliency by shutting down one of the bundle links between R1 and R2 while traffic is being carried across the bundle from R1 to R3. To carry out this experiment, an extended ping to R3 with a large number of packets is performed at R1. While active packets are traversing over the bundle, you can shut down one of the bundle links between routers R1 and R2. In this case, the traffic should not be disrupted as long as there is at least one active bundle link in the bundle.

Example 14-14 shows what happens when a bundle link is shut down at the same time that an extended ping with a count of 1000 packets is performed across the Multilink bundle. The purpose of this example is to simulate a bundle link failure and to verify that there is no disruption to normal traffic flow as long as there are other active bundle links in the bundle.

Example 14-14. Verifying Bundle Resiliency by Shutting Down a Bundle Link While Traffic Is Transmitting
R1#ping
Protocol [ip]:
Target IP address: 172.16.1.2
Repeat count [5]: 1000
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]:
Sweep range of sizes [n]:
Type escape sequence to abort
Sending 1000, 100-byte ICMP Echos to 172.16.1.2, timeout is 2 seconds:
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Note: Ping is continuing at this point

R2#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z
R2(config)#interface s3/3
R2(config-if)#shutdown
R2(config-if)#end
R2#

R2#show frame-relay multilink detailed
Bundle: MFR0, State = up, class = A, fragmentation disabled
 BID = MFR0
 No. of bundle links = 2, Peer's bundle-id = Multilink Frame Relay_BUNDLE
 Bundle links:

  Serial4/3, HW state = up, link state = Up, LID = Serial4/3
    Cause code = none, Ack timer = 4, Hello timer = 10,
    Max retry count = 2, Current count = 0,
    Peer LID = REMOTE_LINK_1, RTT = 4 ms
    Statistics:
    Add_link sent = 5, Add_link rcv'd = 6,
    Add_link ack sent = 5, Add_link ack rcv'd = 4,
    Add_link rej sent = 0, Add_link rej rcv'd = 0,
    Remove_link sent = 1, Remove_link rcv'd = 1,
    Remove_link_ack sent = 1, Remove_link_ack rcv'd = 0,
    Hello sent = 1440, Hello rcv'd = 1438,
    Hello_ack sent = 1438, Hello_ack rcv'd = 1437,
    outgoing pak dropped = 0, incoming pak dropped = 0

  Serial3/3, HW state = Administratively down, link state = Down_idle, LID = Serial3/3
    Cause code = bundle link idle, Ack timer = 4, Hello timer = 10,
    Max retry count = 2, Current count = 0,
    Peer LID = , RTT = 4 ms
    Statistics:
    Add_link sent = 5, Add_link rcv'd = 5,
    Add_link ack sent = 5, Add_link ack rcv'd = 4,
    Add_link rej sent = 0, Add_link rej rcv'd = 0,
    Remove_link sent = 3, Remove_link rcv'd = 1,
    Remove_link_ack sent = 1, Remove_link_ack rcv'd = 0,
    Hello sent = 1374, Hello rcv'd = 1439,
    Hello_ack sent = 1439, Hello_ack rcv'd = 1374,
outgoing pak dropped = 0, incoming pak dropped = 0

R1#ping
Protocol [ip]:
Target IP address: 172.16.1.2
Repeat count [5]: 1000
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 1000, 100-byte ICMP Echos to 172.16.1.2, timeout is 2 seconds:
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!
Success rate is 100 percent (1000/1000), round-trip min/avg/max = 28/30/56 ms

The last configuration command discussed here is the frame-relay multilink output-threshold bytes interface configuration command. This command is always active and cannot be turned off when Multilink Frame Relay is configured. The default value is 300 bytes. The default value should be used when all bundle links in the bundle are of the same type and speed. However, if the bundle links are of varying speeds, the frame-relay multilink output-threshold command can be used to assign a higher byte size to the higher-speed bundle link, with the configured byte size on the higher-speed bundle link proportionally larger than the lower-speed bundle link. This helps to ensure that the traffic load is evenly distributed between the highest and lowest speed bundle links.

Troubleshooting Multilink Frame Relay

This section looks at the debug commands available for troubleshooting Multilink Frame Relay-specific issues on a Cisco router. The debug frame-relay multilink command can be used to display all debug messages related to Multilink Frame Relay bundles and bundle links. All Multilink Frame Relay data and control packets are captured, which might negatively impact the performance of the router. In its place, the more specific debug frame-relay multilink control command can be used to capture only Multilink Frame Relay control packets. The more specific debug frame-relay multilink control command should be used instead of the generic debug frame-relay multilink command when troubleshooting standard Multilink Frame Relay link negotiation issues.

Example 14-15 shows a sample output of the debug frame-relay multilink control command turned on at R1.

Example 14-15. Turning on debug frame-relay multilink control Command and Observing the debug Output at R1
[View full width]
R1#debug frame-relay multilink control
 Displaying Multilink FR control packets

04:23:35: Serial0(i) : msg = Add_link, Link = Serial0, Bundle = MFR0, Link id =
   REMOTE_LINK_1, BL state = Ack_rx
E1 00 01 01 07 4D 46 52 30 00
04:23:35: Serial0(o) : msg = Add_link_ack, Link = Serial0, Bundle = MFR0, Link id =
   REMOTE_LINK_1, BL state = Ack_rx
E1 00 02 01 0D 4D 46 52 5F 42
04:23:35: %LINK-3-UPDOWN: Interface MFR0, changed state to up
04:23:35: Serial3(i) : msg = Add_link, Link = Serial3, Bundle = MFR0, Link id =
   REMOTE_LINK_2, BL state = Ack_rx
E1 00 01 01 07 4D 46 52 30 00
04:23:35: Serial3(o) : msg = Add_link_ack, Link = Serial3, Bundle = MFR0, Link id =
   REMOTE_LINK_2, BL state = Ack_rx
E1 00 02 01 0D 4D 46 52 5F 42
04:23:35: Serial0(i) : msg = Hello, Link = Serial0, Bundle = MFR0, Link id = REMOTE_LINK_1
  , BL state = Up
E1 00 04 03 06 10 0D E8 DF 05
04:23:35: Serial0(o) : msg = Hello_ack, Link = Serial0, Bundle = MFR0, Link id =
   REMOTE_LINK_1, BL state = Up
E1 00 05 03 06 60 40 7F B2 06
04:23:35: Serial3(i) : msg = Hello, Link = Serial3, Bundle = MFR0, Link id = REMOTE_LINK_2
  , BL state = Up
E1 00 04 03 06 10 0D E8 DF 05
04:23:35: Serial3(o) : msg = Hello_ack, Link = Serial3, Bundle = MFR0, Link id =
   REMOTE_LINK_2, BL state = Up
E1 00 05 03 06 60 40 7F B2 06
04:23:36: %LINEPROTO-5-UPDOWN: Line protocol on Interface MFR0, changed state to up
04:23:45: Serial0(o) : msg = Hello, Link = Serial0, Bundle = MFR0, Link id = REMOTE_LINK_1
  , BL state = Up
E1 00 04 03 06 60 40 7F B2 06
04:23:45: Serial0(i) : msg = Hello_ack, Link = Serial0, Bundle = MFR0, Link id =
   REMOTE_LINK_1, BL state = Up
E1 00 05 03 06 10 0D E8 DF 01
04:23:45: Serial3(o) : msg = Hello, Link = Serial3, Bundle = MFR0, Link id = REMOTE_LINK_2
  , BL state = Up
E1 00 04 03 06 60 40 7F B2 05
04:23:45: Serial3(i) : msg = Hello_ack, Link = Serial3, Bundle = MFR0, Link id =
   REMOTE_LINK_2, BL state = Up

The debug output in Example 14-15 shows the exchange of Multilink Frame Relay Link Integrity Protocol Control messages between R1 and R2 after the Multilink Frame Relay interface is administratively enabled with no shut.


Summary

This chapter covered Cisco's implementation of the Multilink Frame Relay feature, which is based on the Frame Relay Forum Implementation Agreement Document Number FRF.16. This chapter looked at the advantages provided by the Multilink Frame Relay feature and the benefits of bandwidth aggregation that it brings to certain Frame Relay users. Then this chapter explained the mechanisms and basic operation of Multilink Frame Relay, including the Link Integrity Control Protocol, which is used to set up Multilink Frame Relay bundles. This chapter also presented a simple scenario involving the Multilink Frame Relay feature. The scenario described how the Multilink Frame Relay feature is typically used through the use of practical configuration examples. The chapter discussed the necessary Cisco IOS configuration tasks and configuration commands for configuring the Multilink Frame Relay feature. The closing sections of this chapter covered the Cisco IOS show and debug commands for monitoring and maintaining Multilink Frame Relay on a Cisco router.

The next chapter discusses Frame Relay compression. Both software- and hardware-based compression are covered.


Review Questions

1: | Compare the use of Multilink Frame Relay with that of separate physical interfaces to aggregate bandwidth.
2: | Name the protocol that Multilink Frame Relay uses to establish a bundle.
3: | How many classes of bandwidth are defined in the FRF.16 implementation agreement? Name the class of bandwidth implemented by Cisco.
4: | What is the restriction for the maximum number of Multilink Frame Relay interfaces that can be created?
5: | What is the Cisco IOS configuration command to configure a physical interface as a bundle link or a member of the bundle?
6: | How is load balancing performed across the bundle links of a Multilink bundle? What is the Cisco IOS configuration command to adjust the load balancing threshold across the bundle links?


References

  • Frame Relay Forum Implementation Agreement FRF.16.1: Multilink Frame Relay UNI/NNI Implementation Agreement, May 2002: http://www.mplsforum.org/frame/Approved/FRF.16/frf16.1.pdf

  • Cisco IOS Release 12.2(8)T New Features configuration guide: http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122newft/122t/122t8/ft_mfr.htm


Chapter 15. Compression over Frame Relay

Many techniques and Quality of Service (QoS) features are supported by the Cisco IOS software to manage congestion and to optimize the transmission of traffic over Frame Relay networks. Among these, depending on the user's requirements, Frame Relay Traffic Shaping with custom or priority queuing and Frame Relay Traffic Policing are common examples of Traffic Conditioning and Congestion Management features that improve overall performance. Data compression is a Link-Efficiency tool that reduces the size of a frame by compressing it prior to transmission. With effective Compression algorithms, the number of actual bytes that need to be sent across a Frame Relay link is dramatically reduced and this helps to achieve greater utilization of the available bandwidth over low-speed links.

This chapter presents the Frame Relay compression features in the Cisco IOS software for optimizing traffic for transmission over low-speed Frame Relay links. Several compression methods for Frame Relay are discussed. The compression techniques covered in this chapter include Cisco proprietary Frame Relay payload compression, Frame Relay Implementation Agreement Document Number FRF.9 payload compression, TCP/IP header compression, and Real-Time Transport Protocol (RTP) header compression. Only compression performed internally within the Cisco IOS software and Cisco router firmware is discussed in this chapter. External compression techniques using third-party external devices are not addressed.

To begin, this chapter addresses current problems on Frame Relay networks and then presents compression as a key solution to these issues. Then the chapter presents an overview of each of the compression techniques introduced. A technical explanation is provided on how each data compression method works, as well as practical examples of how each method is configured on Cisco routers.

This chapter offers a basic design guideline for implementing compression schemes on Frame Relay networks. The examples and information presented are not cast in stone, and the design should be viewed only as common best practices. This information should be used bearing in mind the characteristics of your network.

The chapter finishes with the Frame Relay compression monitoring commands and basic troubleshooting techniques, which are demonstrated with configuration examples on Cisco routers.

The topics and questions that this chapter addresses include the following:

  • Overview of compression and its application on Frame Relay networks

  • Basic operation of compression and the differences of header versus data payload compression schemes

  • Configuring Cisco Frame Relay proprietary compression, Frame Relay FRF.9 payload compression, TCP/IP header compression over Frame Relay, and RTP header compression over Frame Relay

  • Configuring Express Header Compression for Cisco IOS Release 12.1

  • Basic guidelines on deploying Frame Relay compression schemes

  • Monitoring and maintaining Frame Relay compression configurations on Cisco routers

After completing this chapter, readers will recognize the benefits of using compression over Frame Relay or over other data link technologies. In addition, readers will understand the basic operation of compression, as well as the different types of compression schemes and techniques. Readers will become familiar with the design guidelines associated with the use of compression. Readers will also become familiar with the compression schemes supported by the Cisco IOS software and the configuration tasks and Cisco IOS configuration commands required to configure them. Finally, readers will learn how to monitor and maintain compression over Frame Relay configurations on Cisco routers using Cisco IOS show commands.


Current Issues

This section addresses the current issues and problems on Frame Relay networks that can be resolved through the proper use of compression.

Today, the demand from users for increased bandwidth is in accordance with the rapid growth of data-intensive LAN-based client-server applications. The expansion of bandwidth demand is concurrent with the availability of higher-speed and lower-priced Fast Ethernet (100 Mbps) or even Gigabit (1000 Mbps) Ethernet switch ports. These shared applications usually consume a large portion of the bandwidth available on the network. Typical examples of traffic generated by such applications include e-mail, file server applications, relational database queries, or bulk transfers of files. These LAN-based shared applications are commonly connected to each other and to the corporate backbone networks via WAN links, such as over Frame Relay virtual circuits. As such, the new LAN traffic trend places greater demands on the Frame Relay WAN network to provide more bandwidth.

In order to control or to manage the operating cost of networks (Frame Relay virtual circuits or traditional point-to-point leased lines), deploying compression is necessary to fully optimize the use of existing links.

Why Use Compression?

The Cisco IOS software supports many features that improve the performance of Frame Relay networks. Some of these features are designed to optimize WAN bandwidth and to ease congestion on the WAN links. For example, when Frame Relay Traffic Shaping is deployed at a customer's Frame Relay access router, it can be used to alleviate the congestion problem on slow Frame Relay access links by rate limiting frames sent into the Frame Relay network. When Frame Relay Traffic Shaping is used with Frame Relay adaptive shaping, Frame Relay Traffic Shaping can dynamically throttle the output rate and thus prevent congestion from developing in the Frame Relay network. Refer to Chapter 5, "Frame Relay Traffic Shaping," for more details.

In another example, custom queuing with Frame Relay Traffic Shaping can be implemented to set up a custom queuing scheme on the router to allocate a percentage of the total bandwidth to every traffic type on a Frame Relay permanent virtual circuit (PVC). Using custom queuing, a user normally allocates a percentage of the total bandwidth based on the bandwidth requirement of each type of traffic identified on the Frame Relay PVC. For instance, users typically assign a larger percentage of the total bandwidth to mission-critical traffic.

In spite of the benefits of the mentioned Frame Relay features, compression remains one of the most effective methods to increase optimization of bandwidth over WAN links. In general, compression reduces the size of data transmitted by compressing it over the network. Reducing the overall size of the data transmitted by using compression allows more data to be sent across the line. Hence, compression helps to increase the overall throughput of existing lines.

Cisco supports several compression methods in Frame Relay. One type of compression method compresses the packet header size, whereas the other type condenses the size of the payload within a packet. Both compression types help to increase the efficiency of data transmission across any network.

Compression can be performed with software or hardware. The software compression approach is CPU-intensive, because it uses the CPU on the router to perform the compression computations. On the other hand, the hardware compression method requires users to install dedicated hardware compression modules on the router that performs the compression computations. The hardware compression module offloads the computations from the CPU, thus saving CPU resources and allowing it to support other important tasks.

Saving and Optimizing Bandwidth

Compression is particularly useful at remote sites where the access bandwidth is typically much lower than the central site. By sending compressed data, more information can be sent over the line in the same period of time. Conversely, the same information can be sent over in a shorter period of time. Thus, compression ensures that slower-speed remote sites can continue to operate effectively without incurring additional operating costs by adding more bandwidth.

Reducing the Existing Committed Information Rate (CIR) Requirements

When compression is suitably deployed in a Frame Relay network, most of the time it effectively results in a reduction in the customer's CIR requirements. When compression is used on a network, the same exact data is sent over, but it is now represented with a smaller amount of bits. A good compression technique allows a higher data throughput to be attained over the WAN link. Therefore, compression can effectively reduce the customer's CIR requirements. Most often, a lower CIR rate means direct savings and lower operating costs for the customer.


Solutions to Current Issues

The Cisco Frame Relay compression techniques assist in resolving issues that were addressed in the previous section. Cisco supports several different forms of compression solutions for Frame Relay. Among these compression techniques are payload compression and header compression.

Both general categories of compression schemes enable Frame Relay networks to efficiently optimize the bandwidth by allowing a greater volume of compressed traffic to be sent at a time. The supported Frame Relay compression schemes are the proprietary packet-by-packet payload compression, the FRF.9 standards-based payload compression, the TCP/IP header compression, and RTP header compression. In the coming sections of this chapter, more details on each compression scheme are presented as the discussion moves ahead.


How Compression Works

This section begins the discussion on compression by presenting technical details of how compression generally works. The two different types of compression techniques, Stacker and Predictor, are explained in this section. The concept of compression ratios and how they affect the compression performance are discussed. The software and hardware compression methods are also compared.

Compression Defined

The basic function of compression is to reduce the size of a frame to be transmitted over a Frame Relay link. By the laws of mathematics, reducing the size of a frame reduces the time required to transmit the frame across the network. Compression usually happens between two endpoints. It uses a coding scheme at each end of the transmission link. At the sending end, the coding scheme allows characters to be removed from the frames and then to be replaced correctly at the receiving side. Compression condenses the frames. As the smaller frames now use less bandwidth, bandwidth is saved on the transport network.

There are basically two types of data compression schemes, namely, nonreversible and loss-less compression algorithms.

Nonreversible Data Compression Scheme

Data compression schemes used for voice and image data are generally referred to as nonreversible. This type of compression results in some loss of data and degradation in exchange for greater compression and lower bandwidth requirements needed to handle these transmissions. An example of nonreversible compression schemes is the Joint Photographic Experts Group (JPEG) image compression scheme. The JPEG compression format allows a large picture image to be compressed significantly without much loss in the image quality.

Loss-less Compression Algorithm Data Compression Scheme

The data compression schemes used in internetworking devices are commonly referred to as loss-less compression algorithms. These compression schemes reproduce the original bit stream exactly, without degradation or loss. This is required by routers and other internetworking devices to transport data across the network. Therefore, the compression schemes used on Cisco routers which are discussed in this chapter are loss-less compression algorithms.

Stacker Versus Predictor

The most commonly used compression schemes are the Stacker and the Predictor data compression algorithms. The Cisco IOS software support both Stacker and Predictor compression algorithms. Each of these is described in the following sections.

Stacker Compression Algorithm

The Stacker compression algorithm is based on the Lempel-Ziv compression algorithm. The Cisco IOS software uses an enhanced version of the Stacker algorithm that provides good compression ratios, but it places a greater demand on CPU cycles to perform the required compression.

The Stacker compression scheme works by building an encoded dictionary of symbols and tokens, which is then used to replace redundant strings of characters. The Stacker algorithm builds the dictionary, or tables, consisting of these string matches and tokens and stores them in the memory. Usually, the contents of the dictionary can adapt to changes in the data to accommodate the different types of traffic transmitted over the network. Figure 15-1 illustrates the dictionary involved during data compression performed between two peers.

Figure 15-1. Synchronization and Use of Dictionary for Data Compression

Predictor Compression Scheme

The Predictor compression scheme works by predicting the next sequence of characters in a data stream by using an index to look up a sequence in a compression dictionary. Then it examines the next sequence in the data stream to check whether it matches. If it does, the sequence is replaced with the sequence that was looked up in the dictionary. Otherwise, the algorithm searches again for the next sequence in the data stream. The index updates itself by hashing a few of the most recent character sequences from the input data stream.

The Predictor compression algorithm is publicly available. Compared with the Stacker compression scheme, Predictor is more efficient because it uses fewer CPU cycles. However, it requires more memory than the Stacker compression algorithm.

Compression Ratios

The efficiency and effectiveness of a compression algorithm is often measured by its compression ratio. The compression ratio is the ratio of the size of uncompressed data to compressed data. A compression ratio of 3:1 means the compressed data is a third of the size of the original data. The average compression ratio for Cisco IOS compression schemes is 2:1.

Software Versus Hardware Compression

The compression schemes for Frame Relay supported by the Cisco IOS software are software-based. However, hardware-assisted compression is possible on some Cisco router platforms with the use of special hardware compression modules.

NOTE

Refer to the following link for details on the Data Compression Advanced Integration Modules (AIM) for the Cisco c2600, c3660, and c3700 series:

http://www.cisco.com/en/US/products/hw/routers/ps274/products_data_sheet09186a0080091b8a.html

Refer to the following link for information on the Compression Service Adaptors (CSA) for the Cisco c7200, c7500, and Route Switch Processor (RSP) series platforms:

http://www.cisco.com/en/US/products/hw/modules/ps2957/prod_brochure09186a0080091d33.html

In software-based compression, the compression algorithm is performed in the main CPU as a software process. In hardware-based compression, the compression computations are offloaded to the hardware compression modules, thus freeing up critical CPU resources for other important tasks, such as route table computation and management.

Cisco supports different types of hardware compression modules for a few router platforms. The CSA is a high-performance hardware module that performs hardware compression on the c7200 series, c7500 series, and RSP 7000-equipped c7000 series routers. CSA maximizes the router performance by offloading compression algorithm computations from the CPU and allows the CPU to remain dedicated to routing and specialized tasks. Figure 15-2 shows the CSA module for the c7000, c7200, and c7500 platforms.

Figure 15-2. CSA Modules (c7000, c7200, and c7500 Platforms)

Similarly, on the c3620 and c3640 platforms, the compression network module performs hardware-based compression to improve the performance by offloading the compression computations from the CPU. The AIM performs data compression functions for the c2600 and c3660 router platforms. Figure 15-3 illustrates the AIM module for the c2600 routers.

Figure 15-3. AIM-COMPR2= Module

NOTE

Presently, Cisco hardware compression modules only support Point-to-Point stacker compression and Frame Relay FRF.9 compression using the Stacker algorithm. The Cisco Frame Relay hardware compression feature is discussed in Chapter 16, "Frame Relay Fragmentation."

Table 15-1 summarizes the hardware compression support available on Cisco router platforms.

Table 15-1. Cisco Routers with Hardware Compression Support

Router Series

Hardware Compression Module

c7000 (RSP), c7200, and c7500

SA-COMP/1= and SA-COMP/4=

c3620 and c3640

NM-COMPR=

c3660

AIM-COMPR4=

c2600

AIM-COMPR2=


Technical Overview of Cisco IOS Frame Relay Compression Schemes

This section introduces the different compression schemes for Frame Relay that are supported by the Cisco IOS software. In general, users select a compression scheme that falls under either the payload compression scheme or packet header compression scheme.

Data Payload Compression Schemes

The Cisco IOS software supports a packet-by-packet payload compression scheme using Stacker compression. The Cisco packet-by-packet payload compression for Frame Relay feature is Cisco proprietary, so it is compatible only between Cisco devices.

In addition to packet-by-packet payload compression, the Cisco IOS software now supports the data compression scheme based on the Frame Relay Forum Implementation Agreement FRF.9. The FRF.9 standard compression scheme uses the Stacker algorithm and provides multivendor compatibility. The FRF.9 compression scheme also has a better compression ratio than packet-by-packet payload compression.

Packet Header Compression

The Cisco IOS software supports compression features that allow packet headers to be compressed to reduce packet overheads and increase throughput. The Cisco TCP/IP header compression feature, based on RFC 1144, enables the disproportionately large TCP/IP headers to be compressed as the packets are transmitted across a Frame Relay network.

RTP, based on RFC 1889, is a protocol used for transporting audio and video packets over an IP network. The Cisco RTP header compression scheme for Frame Relay allows the RTP header to be compressed and sent efficiently over a Frame Relay network.

Figure 15-4 depicts the main difference between data payload and header compression algorithms.

Figure 15-4. Payload Versus Header Compression

Previous Page
Next Page


Configuring Frame Relay Proprietary Payload Compression

The Cisco packet-by-packet payload compression can be configured on Frame Relay physical interface or on Frame Relay logical point-to-point or multipoint subinterfaces. This proprietary scheme uses the Stacker algorithm to predict the next character in a frame on a packet-by-packet basis. Hence, the dictionary is not conserved across packet boundaries. A single dictionary is used for all packets compressed on a line. This results in a lower compression ratio compared with the FRF.9 standards-based payload compression scheme. The payload compression on each Frame Relay virtual circuit consumes approximately 40 kilobytes for dictionary memory.

To configure the Cisco Frame Relay packet-by-packet payload compression, perform the following steps, beginning in global configuration mode:

Step 1. | Enter the interface configuration mode of the router for a Frame Relay physical interface, a multipoint logical subinterface, or a point-to-point logical subinterface.
Step 2. | On a multipoint interface, enable Frame Relay packet-by-packet payload compression with the frame-relay map protocol protocol-address dlci payload-compress packet-by-packet interface configuration command.
Step 3. | On a point-to-point subinterface, enable Frame Relay packet-by-packet payload compression with the frame-relay payload-compress packet-by-packet interface configuration command.

Example 15-1 illustrates the configuration examples for Frame Relay packet-by-packet payload compression on a Cisco router.

Example 15-1. Configuration Examples for Cisco Payload Compression
<output omitted>

interface Serial3/0
 ip address 172.16.1.3 255.255.255.0
 encapsulation frame-relay
 frame-relay map ip 172.16.1.1 100 payload-compression packet-by-packet
!
interface Serial3/0.200 point-to-point
 ip address 172.16.2.2 255.255.255.0
 frame-relay interface-dlci 200
 frame-relay payload-compression packet-by-packet


Configuring Frame Relay FRF.9 Payload Compression

The Cisco packet-by-packet payload compression scheme for Frame Relay is a proprietary compression algorithm that does not work too well in a multivendor environment. As such, a need for a new compression algorithm that is multivendor compatible arises.

The Frame Relay FRF.9 payload compression, based on the implementation agreement for data compression over Frame Relay (FRF.9) approved by the Frame Relay Forum, provides a higher compression performance compared with the packet-by-packet payload compression scheme. FRF.9 defines a standard compression algorithm to ensure multivendor interoperability. FRF.9 also has higher compression ratios and allows more data to be compressed for faster transmission. FRF.9 compression provides the ability to maintain multiple compression and decompression histories on a per-DLCI basis by maintaining a dictionary per DLCI. The compressed payload is transported through the Frame Relay network and decompressed at its termination point. Hence, FRF.9 is configured end-to-end, as illustrated in Figure 15-5.

Figure 15-5. FRF.9 Payload Compression

FRF.9 supports hardware-assisted compression using specialized hardware compression modules installed on Cisco routers. The role of the hardware compression modules is to offload the compression calculations from the router's CPU as much as possible. This frees up CPU resources for other CPU-intensive router operations, such as performing Border Gateway Protocol routes calculations.

To configure the FRF.9 payload compression on a Cisco router, perform the following steps, beginning in global configuration mode:

Step 1. | Enter the interface configuration mode of the router for a Frame Relay physical interface, a multipoint logical subinterface, or a point-to-point logical subinterface.
Step 2. | On a multipoint interface, enable Frame Relay FRF.9 payload compression with the frame-relay map protocol protocol-address dlci payload-compress FRF9 stac [hardware-options] interface configuration command.
Step 3. | On a point-to-point subinterface, enable Frame Relay FRF.9 payload compression with the frame-relay payload-compress FRF9 stac [hardware-options] interface configuration command.
Step 4. | (optional) The FRF.9 configuration command shown in Step 2 and Step 3 allows hardware-options to be specified. The hardware-options available are caim and csa keywords for using hardware-assisted compression, the distributed keyword for enabling compression on VIP2 or higher, and the software keyword for compression using CPU.

FRF.9 compression is supported on VCs and interfaces that are using Internet Engineering Task Force (IETF) encapsulation type (RFC 1490/2427). When the frf9 stac keyword is specified, IETF encapsulation is automatically enabled.

When FRF.9 is chosen as the compression scheme, it allows users to select the type of compression method desired. However, if the compression method for FRF.9 is not selected and a CSA module is detected on the Cisco router, the router defaults to performing compression calculations in the CSA hardware. If a CSA module is not installed, but the router is a c7500 series router with a second generation Versatile Interface Processor (VIP2) line card or higher, the compression is performed in software on the VIP2 line card. This mode of compression is also known as distributed compression. If both CSA and VIP2 are not available on the router, compression is performed in the router's CPU using software compression.

Example 15-2 shows the output of the show version command on a c3640 router with a CSA module installed. The example also displays the list of compression options available under the physical main interface. The distributed option is only available on c7500 series platforms.

Example 15-2. Available Hardware Options for FRF.9 Payload Compression
Cisco Internetwork Operating System Software
IOS (tm) 3600 Software (C3640-JS-M), Version 12.1(5)T5, RELEASE SOFTWARE (fc2)
TAC Support: http://www.cisco.com/tac
Copyright  1986-2002 by cisco Systems, Inc.
Compiled Thu 14-Feb-02 01:33 by ccai
Image text-base: 0x60008930, data-base: 0x61816000

ROM: System Bootstrap, Version 11.1(20)AA2, EARLY DEPLOYMENT RELEASE SOFTWARE (fc1)

kachin6 uptime is 1 week, 1 day, 21 hours, 53 minutes
System returned to ROM by reload
System image file is "flash:c3640-js-mz.121-5.T5"

cisco 3640 (R4700) processor (revision 0x00) with 124928K/6144K bytes of memory.
Processor board ID 21353407
R4700 CPU at 100Mhz, Implementation 33, Rev 1.0
Bridging software.
X.25 software, Version 3.0.0.
SuperLAT software (copyright 1990 by Meridian Technology Corp).
TN3270 Emulation software.
Primary Rate ISDN software, Version 1.1.
4 Ethernet/IEEE 802.3 interface(s)
4 Serial network interface(s)
2 Channelized T1/PRI port(s)
1 Compression service adapter(s)
DRAM configuration is 64 bits wide with parity disabled.
125K bytes of non-volatile configuration memory.
32768K bytes of processor board System flash (Read/Write)
16384K bytes of processor board PCMCIA Slot0 flash (Read/Write)

R1(config-if)#frame-relay map ip 172.16.1.2 100 payload-compression frf9 stac ?
  caim                 Specify CAIM compressor
  csa                  specify csa compressor
  software             force software compression
<cr>

Example 15-3 shows another configuration example for payload compression on a Cisco router using FRF.9 compression.

Example 15-3. Configuration Examples of FRF.9 Payload Compression on Cisco Routers
<output omitted>

interface Serial3/0
 ip address 172.16.1.3 255.255.255.0
 encapsulation frame-relay
 frame-relay map ip 172.16.1.1 100 payload-compression frf9 stac
!
interface Serial3/0.200 point-to-point
 ip address 172.16.2.2 255.255.255.0
 frame-relay interface-dlci 200
 frame-relay payload-compression frf9 stac software

The configuration examples presented in Example 15-3 configure FRF.9 payload compression at the physical (multipoint) serial interface 3/0 on DLCI 100. On DLCI 200 residing on point-to-point subinterface serial3/0.200, FRF.9 mode software compression is forced.


Configuring TCP/IP Header Compression over Frame Relay

This section discusses the TCP/IP header compression scheme for Frame Relay virtual circuits. TCP/IP header compression is also commonly known as the Van Jacobson's algorithm, designed and defined in RFC 1144. The TCP/IP header compression scheme relies on the redundant nature of many fields within the TCP/IP headers of a packet after a connection has been established. For the entire duration of the TCP session, the header details for the connection are maintained at both the origination and the destination. As such, the header can be reconstructed at the destination based on the knowledge of the TCP connection in use. In a typical user session involving TCP connection, hundreds of packets are exchanged over the link. Header compression results in efficient transmission of each datagram, thereby freeing up the bandwidth over the link. On remote slow speed Frame Relay links (typically on 56-kbps or 64-kbps lines), TCP/IP header compression helps to improve the efficiency of bandwidth utilization.

An average TCP/IP packet typically includes a 40-byte header. However, once the TCP connection is established, the header information becomes redundant for the subsequent data transmissions. With TCP/IP header compression, the size of the header can be reduced from its initial 40 bytes to a smaller size, between 3 and 18 bytes. The average size of a compressed header is about 10 bytes. The TCP/IP header compression algorithm condenses the TCP/IP headers but leaves the data payload in the packet completely uncompressed. This greatly reduces the overhead in the TCP/IP traffic transported over the Frame Relay network for common TCP services such as Telnet, rlogin, and XWindows. Statistics have shown that an average of a 50 percent improvement in the throughput can be obtained with Telnet traffic over a 64-kbps line. The compression ratios for other traffic types are largely dependent on the nature of the data.

It is important to note that TCP/IP header compression is a hop-by-hop compression scheme. The TCP/IP header must be replaced at each node, or hop, for routing or switching to be possible. The compression and decompression processing at each hop adds latency and also considerably increases the processing load of the CPU.

Active Versus Passive TCP/IP Header Compression

The Cisco IOS software allows TCP/IP header compression over Frame Relay to work in active or passive mode. When active compression mode is selected, all outgoing packets are subjected to TCP/IP header compression. On the other hand, passive compression mode subjects an outgoing TCP/IP packet to header compression only if a packet had a compressed TCP/IP header when it was received. The active compression mode is the default mode on Cisco routers.

TCP/IP header compression on a Cisco router requires the Cisco Frame Relay encapsulation to be used. The IETF Frame Relay encapsulation cannot be used with TCP/IP header compression over Frame Relay on the Cisco IOS software. An error message is generated by the Cisco IOS software whenever this is attempted, as shown in Example 15-4.

Example 15-4. Error Message When Using IETF Encapsulation with TCP/IP Header Compression over Frame Relay
Router#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router (config)#interface serial2/0
Router (config-if)#encapsulation frame-relay ietf
Router (config-if)#frame-relay ip tcp header-compression
%Interface is set for IETF encapsulation! IP
%header compression is supported only over CISCO
%encapsulation!

Configuring TCP/IP Header Compression over Frame Relay

To configure TCP/IP header compression over Frame Relay on a Cisco router, perform the following configurations, beginning in the global configuration mode:

Step 1. | Enter the interface configuration mode of the router for the physical interface, the multipoint logical subinterface, or the point-to-point logical subinterface. Frame Relay encapsulation for either the default Cisco or ietf mode must be configured on the main interface. To configure TCP/IP Header Compression on the main interface, Cisco Frame Relay encapsulation must be configured.
Step 2. | On the main interface or subinterface, TCP/IP header compression over Frame Relay can be enabled with the frame-relay ip tcp header-compression [passive] interface configuration command. The default compression mode is the active mode. This command can be used on physical interfaces or logical subinterfaces. When this command is configured, the applied TCP/IP header compression characteristics are inherited by all DLCIs created under the main interface or subinterface.
Step 3. | TCP/IP header compression over Frame Relay can be enabled explicitly with the frame-relay map ip protocol-address dlci [broadcast] cisco tcp header-compression [active | passive] interface configuration command. This command should be used when you need to use IETF encapsulation on the main interface as a whole, but a specific DLCI needs to use Cisco encapsulation and TCP/IP header compression. This command can be used when TCP/IP header compression needs to be configured on a specific DLCI, but it is not required on other DLCIs created under the main interface. Note that only IP protocol can be used with TCP/IP header compression.
Step 4. | (optional) To remove or disable TCP/IP header compression, two commands can be used. The no frame-relay ip tcp header-compression interface configuration command effectively disables TCP/IP header compression on all DLCIs not explicitly configured for TCP header compression. Then the frame-relay map ip ip-address dlci nocompress interface configuration command can be used to disable TCP/IP header compression only on a specified DLCI.
Step 5. | (optional) To specify the maximum number of TCP/IP header compression connections that can exist on a Frame Relay interface, the frame-relay ip tcp compression-connections interface configuration command is used. There is no default value associated with the maximum number of allowed TCP/IP header compression connections over Frame Relay. The ip tcp compression-connections number interface configuration command for PPP or HDLC interfaces, however, has a default value of 32 allowed connections.

Example 15-5 shows a configuration example for TCP/IP header compression on a Cisco router.

Example 15-5. Configuration Example of TCP/IP Header Compression on a Cisco Router
interface Serial2/3
 ip address 172.16.1.1 255.255.255.0
 encapsulation frame-relay
 frame-relay map ip 172.16.1.3 101 broadcast nocompress
 frame-relay map ip 172.16.1.2 100 broadcast
 frame-relay ip tcp header-compression
!
interface Serial2/3.200 multipoint
 ip address 192.168.1.1 255.255.255.0
 frame-relay map ip 192.168.1.2 300 CISCO tcp header-compression passive

The configuration example in Example 15-5 shows that TCP/IP header compression is explicitly configured for DLCI 100 under the main interface using active compression mode (default). This is inherited by all DLCIs created under the main interface. However, the nocompress keyword is used with the frame-relay map command for DLCI 101 to explicitly disable TCP/IP header compression for this specific DLCI. TCP/IP header compression with passive compression mode is applied to DLCI 200 on the multipoint subinterface. More configuration examples are provided in the "Verifying and Monitoring Frame Relay Compressions on Cisco Routers" section found later in this chapter.


Configuring Frame Relay RTP Header Compression

RTP, defined in RFC 1889, is designed specifically for transporting audio and video traffic in packets over an IP-based network. RTP provides end-to-end transport for applications that support audio, video, multicast, or unicast network services.

The RTP protocol format includes both header and data portions. The data portion of RTP provides support for real-time applications, such as continuous media streaming, loss detection, timing reconstruction, and content identification.

The header portion of an RTP is considerably large compared with the data portion. The RTP header protocol header is depicted in Figure 15-6. It comprises a minimal 12-byte RTP header, combined with a 20-byte IP header, and another 8-byte User Datagram Protocol (UDP) header.

Figure 15-6. RTP Protocol Header Format

As shown in Figure 15-6, this combination effectively creates a 40-byte IP/UDP/RTP header. For most audio and video applications, the average RTP payload size is small, resulting in a considerably high header-to-data ratio. Because of the large size of the IP/UDP/RTP header combinations, it becomes inefficient to send the IP/UDP/RTP header over a link without first performing compression.

RTP header compression, also commonly referred to as Compressed RTP (CRTP), is used to avoid the unnecessary consumption of bandwidth. CRTP is defined in RFC 2508. Header compression of RTP packets is possible because there is very little difference in the header information of every packet of an RTP traffic flow. As such, the decompressor at the destination can easily reconstruct the original header without any loss of information.

CRTP helps to compress the RTP header from the original 40 bytes to approximately 2 to 5 bytes. CRTP is also a hop-by-hop compression scheme similar to TCP/IP header compression. The RTP header compression process is illustrated in Figure 15-7.

Figure 15-7. RTP Header Compression Process

[View full size image]

The Cisco IOS software supports the RTP header compression algorithm over Frame Relay, over HDLC or PPP encapsulation, and also on ISDN interfaces. Because of the absence of a standard, CRTP for Frame Relay was developed for Cisco proprietary encapsulation. Hence, on Frame Relay interfaces using CRTP, the Cisco proprietary encapsulation must be used. The IETF standard for Frame Relay encapsulation is not supported with CRTP. However, recent developments in FRF.20 were finalized to make RTP header compression possible on IETF encapsulation.

On Frame Relay networks, CRTP should be used when bandwidth is a major concern and the potential of a high volume of RTP traffic exists. CRTP can support real-time applications, such as voice and video conferencing multicast backbone. CRTP also works well with telephony voice applications running over slow links.

To configure RTP header compression over Frame Relay on a Cisco router, perform the following configurations, beginning in the global configuration mode:

Step 1. | Enter the interface configuration mode of the router for the physical interface, the multipoint logical subinterface, or the point-to-point logical subinterface. Frame Relay encapsulation for either the default Cisco or ietf mode must be configured on the main interface.
Step 2. | On the main interface or subinterface, RTP header compression over Frame Relay can be enabled with the frame-relay ip rtp header-compression [passive] interface configuration command. The default compression mode is the active mode. This command can be used on physical interfaces or logical subinterfaces. When this command is configured, the applied RTP header compression characteristics are inherited by all DLCIs created under the main interface or subinterface.
Step 3. | RTP header compression over Frame Relay can be enabled explicitly with the frame-relay map ip protocol-address dlci [broadcast] rtp header-compression [active | passive] interface configuration command. This command should be used when you need to use IETF (RFC 1490/2427) encapsulation on the main interface as a whole, but a specific DLCI needs to use Cisco encapsulation and RTP header compression. This command can be used when RTP header compression needs to be configured on a specific DLCI, but it is not required on other DLCIs created under the main interface. Note that only IP protocol can be used with RTP header compression.
Step 4. | (optional) To remove or disable RTP header compression, the no frame-relay ip rtp header-compression interface configuration command effectively disables RTP header compression on all DLCIs not explicitly configured for RTP header compression. The no form of the frame-relay map ip protocol-address dlci [broadcast] rtp header-compression [active | passive] interface configuration command can also be used to explicitly remove the configured RTP header compression for the specified DLCI.
Step 5. | (optional) To specify the maximum number of RTP header compression connections that can exist on a Frame Relay interface, the frame-relay ip rtp compression-connections interface configuration command is used. There is no default value associated with the maximum number of allowed RTP header compression connections over Frame Relay. The ip rtp compression-connections number configuration command for PPP or HDLC interfaces, however, has a default value of 32 (16 calls) allowed RTP connections.

Example 15-6 shows a configuration example for RTP header compression on a Cisco router.

Example 15-6. Configuration Example of RTP Header Compression on a Cisco Router
interface Serial2/3
 ip address 172.16.1.1 255.255.255.0
 encapsulation frame-relay
 frame-relay map ip 172.16.1.2 100 broadcast
 frame-relay ip rtp header-compression
!
interface Serial2/3.200 multipoint
 ip address 192.168.1.1 255.255.255.0
 frame-relay map ip 192.168.1.2 300 CISCO rtp header-compression passive

It is possible to configure both TCP/IP and RTP header compression on a Frame Relay interface with a single command. The frame-relay map ip protocol-address dlci [broadcast] compress [active | passive] interface configuration command can be used to enable both TCP/IP and RTP header compression for the specified link.

Table 15-2 shows the supported Cisco IOS software releases for the various Frame Relay compression algorithms discussed.

Table 15-2. Summary of Cisco IOS Software Release Support for Compression Algorithms

Compression Algorithm

Released in Cisco IOS Software Version

Frame Relay Encapsulation Type Supported

TCP/IP header compression

10.0

Cisco only

Cisco proprietary payload compression

11.2

Cisco or IETF

FRF.9 payload compression

11.3

Cisco or IETF

RTP header compression

11.3

Cisco only

Cisco data-stream hardware compression (discussed in Chapter 16)

12.1(5)T

Cisco or IETF only


Express Header Compression for Cisco IOS Release 12.1

Before Cisco IOS Software Release 12.0(7)T, TCP/IP or RTP header compression was performed in the process switching path. This adds considerable load to the router's CPU, because packets traversing a TCP/IP or RTP header compression-enabled interface have to be queued and passed to the router's CPU for the packets to be switched. This slowed down the transmission of the packets considerably because of the slow process-switching path.

With Cisco IOS Software Release 12.1, fast switching of uncompressed TCP and RTP packets is possible. The Express Header Compression feature performs TCP/IP or RTP header compression in the fast-switched path (by default) or in the Cisco Express Forwarding (CEF) path, if the latter is configured. This helps to reduce the processing overhead and to increase the speed of TCP and RTP packet transmission.

IP CEF is configured on Cisco routers with the ip cef global or interface configuration command. Fast switching is enabled with the ip route-cache interface configuration command. If neither fast switching nor CEF switching are enabled, then TCP/IP or RTP header compression is performed in the process-switched path.

In order for Express Header Compression to work, CEF switching or fast switching must be configured on the interface where TCP or RTP header compression is used. For PPP or HDLC interfaces, the maximum number of RTP compression connections has been increased to 1000.


Frame Relay Compression Design Guidelines

There are many conditions to consider when deploying data compression on WAN connections. Very often, the main cause for using compression is when bandwidth is a major concern. The whole purpose of using compression is to reduce transmission overheads and maximize the available bandwidth.

This section takes a look at several compression design issues network administrators typically encounter when faced with the decision of whether to use compression.

Design of the Existing Network

The hub-and-spoke is the most common and popular physical topology in many Frame Relay networks. When using a dictionary-based compression algorithm, such as FRF.9, each point-to-point connection between the spokes and the hub site must have dedicated memory to support the compression. As the number of remote sites grows, greater memory requirements are placed on the hub site. The added processing burden places additional load on the hub site and results in increased network latency. Network managers or administrators should consider the processing power of the router that is used. This is especially important on the central site, which typically receives heavy compressed traffic from the spoke sites.

For example, high-end routers, such as the Cisco c7200 series platforms with fast CPU processors and large memory capacities, are often installed at the central sites to handle the compressed (or uncompressed) traffic on the network.

On peer routers supporting a point-to-point serial link, the potential of resource overloading on a peer router is usually lower than in the case of the hub router supporting numerous spoke routers on a hub-and-spoke topology network. Nonetheless, when a point-to-point link is saturated with heavy traffic load, the point-to-point network is still susceptible to the problems of overloading and congestion. Therefore, compression should be deployed on the routers to improve the effective throughput and the overall performance over the link.

Types of Traffic and Traffic Patterns

Network managers should observe the type of data traffic traversing their network when using compression. Data compression is very dependent on the type of data sent on the network. For example, some types of traffic, such as encrypted or previously compressed data, do not compress well on the network. Compression of this kind of data usually results in the expansion of the data, and thus, more bandwidth can be used instead of saved.

Network managers should also consider the pattern of the traffic on their network when using compression. In a typical network involving a few LAN sites connected to each other via a Frame Relay network, a mix of bursty file transfer traffic, relational database queries, and sporadic IP telephony traffic can be observed. As such, deploying RTP header compression between the various sites might not yield substantial gains in terms of bandwidth saved but may instead add considerable processing load to the routers.

CPU and Memory Constraints

The processing power of the CPU and the amount of memory installed on the router are factors that a network manager should consider and plan when using compression. The amount of memory and the CPU power required varies, depending on the traffic or protocol being compressed, the compression algorithm used, and the number of connections on the routers.

Typically, the Predictor algorithm uses more memory than Stacker algorithm. On Frame Relay networks, more memory is required on the router if the compression scheme is configured on per-PVC basis than on a per-interface basis.

Hardware compression modules can be used on some Cisco router platforms to improve the compression performance. Hardware-assisted compression modules offload the compression computations from the routers' CPU, thereby reliving the routers from CPU-intensive compression calculations.

In general, network managers study the requirements. Usually additional memory or special hardware-assisted compression modules can be added to improve the compression performance on the routers.

Latency and Speed

Inadvertently, compression does add a certain amount of latency to the network. When compression is enabled on an ingress interface receiving data, the input data stream has to be analyzed and processed by the router for compression. Process switching of compressed packets results in processing overheads and adds latency and delay to the transmission. This latency can be detrimental to delay-sensitive protocols, such as Systems Network Architecture (SNA) or voice.

The latency can also be due to other factors, such as the dictionary size, the CPU cycles, the incoming data, and line rates. To avert or reduce the amount of latency introduced by the use of compression, Cisco IOS Release 12.1 supports fast switching and CEF switching of compressed TCP/IP or RTP packets.

Generally, compression algorithms have varying performance at different rates. For example, a fast compression algorithm can process more compression instructions per CPU cycle and thus is able to achieve higher line rates. The network manager must choose the right algorithm that has a good balance between compression speed and latency.

Compression Ratios

The compression ratio is a way to measure the effectiveness of a compression algorithm. The compression ratio is expressed as a ratio that compares the original size of the string to the size of the compressed string. A number such as 2:1, which is also known as the static compression ratio, represents the compression ratio.

Network managers often use the compression ratio of the data as a reflection of the efficiency of the compression algorithm used. However, the compression ratio can vary with the type of data input and the amount of redundancy in the data. The redundancy in the input determines how compressible the data can be. Studies have shown that in LAN environments where many types of applications and protocols are running, the compression ratio is usually lower than those environments where only one type of application exists.


Verifying and Monitoring Frame Relay Compressions on Cisco Routers

In this section, the various Cisco IOS show commands for verifying and monitoring Cisco proprietary payload compression, FRF.9 payload compression, TCP/IP header compression, and RTP header compression are discussed.

NOTE

Some of these examples might show varying outputs compared with what you might see on your routers. This is largely due to different Cisco IOS versions and releases loaded onto the routers. The version used here is Cisco IOS Release 12.1(5)T. Also, note that some Cisco IOS show commands for each compression algorithm do overlap. For instance, the same show compress command can be used for monitoring both TCP/IP and RTP header compression on a Cisco router.

In this section, practical examples are used to conduct a couple of tests to observe the effects of all the compression schemes discussed so far. The examples illustrated in this section are based on the basic Frame Relay network depicted in Figure 15-8, whose topology represents a typical hub-and-spoke arrangement. In the figure, R1 is a remote office router connected to the central office router, R2, on a slower speed link.

Figure 15-8. Network Diagram for Verifying Compression on Cisco Routers

The main approach is based on verifying how compression affects the throughput at R1 before and after it is enabled. Two Windows laptop computers with the Test TCP (TTCP) utility software are connected to the routers for the purpose of measuring the throughput through the Frame Relay network. TTCP is a common benchmarking tool for measuring network performance. It is used to assist in observing the effects of the various compression schemes.

As this discussion moves forward, the various IOS show commands for verifying compression on a Cisco router will be shown and explained.

Example 15-7 shows the basic running configurations of the routers in Figure 15-8.

Example 15-7. Running Configurations of Routers in Figure 15-8
! R1

<output omitted>

ip routing
!
interface Ethernet1/0
 ip address 10.0.0.1 255.255.255.0
!
interface Serial3/2
 no ip address
 encapsulation frame-relay
 no fair-queue
 frame-relay traffic-shaping
!
interface Serial3/2.100 point-to-point
 ip address 172.16.1.1 255.255.255.252
 frame-relay interface-dlci 100
  class SHAPING
!
router eigrp 1
 passive-interface Ethernet1/0
 network 10.0.0.0
 network 172.16.1.0 0.0.0.3
 no auto-summary
 no eigrp log-neighbor-changes
!
map-class frame-relay SHAPING
 frame-relay cir 38400
 frame-relay bc 4800
 frame-relay be 0
 no frame-relay adaptive-shaping

! R2

<output omitted>

ip routing
!
interface Ethernet0
 ip address 20.0.0.1 255.255.255.0
 !
interface Serial1
 no ip address
 encapsulation frame-relay
!
interface Serial1.200 point-to-point
 ip address 172.16.1.2 255.255.255.252
 frame-relay interface-dlci 200
!
router eigrp 1
 passive-interface Ethernet0
 network 20.0.0.0
 network 172.16.1.0 0.0.0.3
 no auto-summary
 no eigrp log-neighbor-changes

As shown in the configuration of R1 and R2 in Example 15-7, a PVC is set up across the Frame Relay network connecting R1 to R2. The Cisco Enhanced IGRP routing protocol is used to enable dynamic routing on the network.

Note that in our setup, the CIR rate allocated to the central office site is set at 64 kbps. In most installations, the speed at the central site is fractional T1 or higher and dependent on the number of remote sites it is connected to. On the other hand, the CIR of DLCI 100 is set up at R1's side to a lower rate of 38,400 bps. Frame Relay Traffic Shaping is applied at R1's Frame Relay interface to rate limit the throughput to the "guaranteed rate." For simplicity, the Cisco routers and the switch are not configured with adaptive traffic shaping.

Verifying the Effects of Cisco Proprietary Payload Compression

To begin the test, the TTCP utility is started at the laptop hosts connected to router R1. Using TTCP, the transmitting host nearest to R1 is set up to send a specified number of TCP packets to the receiving side. At the end of the test, both hosts display the number of bytes transmitted and the time elapsed for the packets to pass from one end to the other. The results can then be used to derive the actual throughput of the Frame Relay link.

Approximately 1 MB of data is generated and sent down the Frame Relay link in the direction of R1 to R2. At this traffic rate, an oversubscription at R1 is anticipated, and Traffic Shaping kicks in to rate limit the output rate to the configured CIR value. Example 15-8 shows the output of the show interface command after transmission is completed. This is performed without enabling compression on both sides of the Frame Relay network.

Example 15-8. show interface Output at R1 Without Any Compression Enabled
R1#show interface serial3/2
#show inter s3/2
Serial3/2 is up, line protocol is up
  Hardware is M8T-V.35
  MTU 1500 bytes, BW 32 Kbit, DLY 20000 usec,
     reliability 255/255, txload 30/255, rxload 7/255
  Encapsulation FRAME-RELAY, crc 16, loopback not set
  Keepalive set (10 sec)
  LMI enq sent  29, LMI stat recvd 29, LMI upd recvd 0, DTE LMI up
  LMI enq recvd 0, LMI stat sent  0, LMI upd sent  0
  LMI DLCI 1023  LMI type is CISCO  frame relay DTE
  FR SVC disabled, LAPF state down
  Broadcast queue 0/64, broadcasts sent/dropped 65/0, interface broadcasts 61
  Last input 00:00:01, output 00:00:01, output hang never
  Last clearing of "show interface" counters 00:04:44
  Queueing strategy: fifo
  Output queue 0/40, 0 drops; input queue 0/75, 0 drops
  5 minute input rate 1000 bits/sec, 4 packets/sec
  5 minute output rate 36000 bits/sec, 5 packets/sec
     1191 packets input, 52789 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
     1375 packets output, 1109949 bytes, 0 underruns
     0 output errors, 0 collisions, 0 interface resets
     0 output buffer failures, 0 output buffers swapped out
0 carrier transitions     DCD=up  DSR=up  DTR=up  RTS=up  CTS=up

The observed output in Example 15-8 confirms the expected behavior. The output rate at R1 does not exceed the configured CIR value because of Frame Relay Traffic Shaping acting on the PVC. Example 15-9 shows the results of the TTCP at the hosts. As shown, the total time required to transfer 1 MB of traffic across the Frame Relay link without any compression is approximately 233 seconds. Using the figures, the calculated throughput is 36 kbps (2000 packets x 1048 bytes x 8 bits / 234 sec).

Example 15-9. Results of TTCP Tests Without Compression
D:\Downloads\Sharewares>WSTTCP -t -l1048 n1000 20.0.0.2
wsttcp-t: buflen=1048, nbuf=1000, align=16384/0, port=5001  tcp  -> 20.0.0.2
wsttcp-t: connect (mss 1460, sndwnd 4128, rcvwnd 4128)
wsttcp-t: 1048000 bytes in 233356 ms (233.356 real seconds) (~3 kB/s) +++
wsttcp-t: 1000 I/O calls
wsttcp-t: 0 sleeps (0 ms total) (0 ms average)
Local host: 10.0.0.2, Local port: 11011
Foreign host: 20.0.0.2, Foreign port: 5001

C:\Programs\Sharewares>WSTTCP r l1048
wsttcp-r: buflen=1048, align=16384/0, port=5001
rcvwndsize=4128, delayedack=yes  tcp
wsttcp-r: accept from 10.0.0.2 (mss 1460, sndwnd 4128, rcvwnd 4128)
wsttcp-r: 1048000 bytes in 234052 ms (234.052 real seconds) (~3 kB/s) +++
wsttcp-r: 1276 I/O calls
wsttcp-r: 0 sleeps (0 ms total) (0 ms average)
Connection state is ESTAB, I/O status: 1, unread input bytes: 0
Local host: 20.0.0.2, Local port: 11011
Foreign host: 10.0.0.2, Foreign port: 5001

Next, observe how Cisco proprietary payload compression can be added to improve the performance. The Cisco propriety payload compression commands are added to R1 and R2 as shown in Example 15-10.

Example 15-10. Enabling Cisco Proprietary Payload Compression at R1 and R2
R1#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
R1(config)#interface serial3/2.100
R1(config-subif)#frame-relay payload-compression packet-by-packet

R2#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
R2(config)#interface s1.200
R2(config-subif)#frame-relay payload-compression packet-by-packet

The same test involving file transfers the laptop computers (in the direction of R1 to R2) is performed again after compression has been configured. Example 15-11 illustrates the output of the show interface commands after the clear counters command is performed and the same TTCP test is completed.

Example 15-11. Output of the show interface Command at R1 After Cisco Proprietary Payload Compression Is Enabled
R1#show interface s3/2
Serial3/2 is up, line protocol is up
  Hardware is M8T-V.35
  MTU 1500 bytes, BW 32 Kbit, DLY 20000 usec,
     reliability 255/255, txload 87/255, rxload 15/255
  Encapsulation FRAME-RELAY, crc 16, loopback not set
  Keepalive set (10 sec)
  LMI enq sent  6, LMI stat recvd 6, LMI upd recvd 0, DTE LMI up
  LMI enq recvd 0, LMI stat sent  0, LMI upd sent  0
  LMI DLCI 1023  LMI type is CISCO  frame relay DTE
  FR SVC disabled, LAPF state down
  Broadcast queue 0/64, broadcasts sent/dropped 14/0, interface broadcasts 13
  Last input 00:00:02, output 00:00:02, output hang never
  Last clearing of "show interface" counters 00:00:58
  Queueing strategy: fifo
  Output queue 0/40, 0 drops; input queue 0/75, 0 drops
  5 minute input rate 2000 bits/sec, 9 packets/sec
  5 minute output rate 11000 bits/sec, 11 packets/sec
     521 packets input, 22846 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
     1025 packets output, 195379 bytes, 0 underruns
     0 output errors, 0 collisions, 0 interface resets
0 output buffer failures, 0 output buffers swapped out
0 carrier transitions     DCD=up  DSR=up  DTR=up  RTS=up  CTS=up

From the output gathered in Example 15-11, the output rate at R1 has dropped from the initial 36,000 bps without compression to a lower rate of around 11,000 bps. This indicates that less bandwidth is being consumed as compared with the case without any compression. Note that the show interface command is performed after the TTCP test is completed and some time has elapsed. Example 15-12 shows the results of the TTCP test with Cisco proprietary payload compression.

Example 15-12. Results of TTCP Test with Cisco Proprietary Payload Compression
D:\Downloads\Sharewares>WSTTCP -t -l1048 n1000 20.0.0.2
wsttcp-t: buflen=1048, nbuf=1000, align=16384/0, port=5001  tcp  -> 20.0.0.2
wsttcp-t: connect (mss 1460, sndwnd 4128, rcvwnd 4128)
wsttcp-t: 1048000 bytes in 48692 ms (48.692 real seconds) (~20 kB/s) +++
wsttcp-t: 1000 I/O calls
wsttcp-t: 0 sleeps (0 ms total) (0 ms average)
Local host: 10.0.0.2, Local port: 11011
Foreign host: 20.0.0.2, Foreign port: 5001

C:\Programs\Sharewares>WSTTCP r l1048
wsttcp-r: buflen=1048, align=16384/0, port=5001
rcvwndsize=4128, delayedack=yes  tcp
wsttcp-r: accept from 10.0.0.2 (mss 1460, sndwnd 4128, rcvwnd 4128)
wsttcp-r: 1048000 bytes in 48856 ms (48.856 real seconds) (~20 kB/s) +++
wsttcp-r: 1002 I/O calls
wsttcp-r: 0 sleeps (0 ms total) (0 ms average)
Connection state is ESTAB, I/O status: 1, unread input bytes: 0
Local host: 20.0.0.2, Local port: 11011
Foreign host: 10.0.0.2, Foreign port: 5001

Compare the results in Example 15-9 with those in Example 15-12. The time it takes for TTCP to complete the transmission test across the Frame Relay link has been noticeably reduced to approximately 49 seconds. The throughput rate has also seen a marked improvement to exactly 170 kbps (versus 36 kbps without compression).

This simple comparison clearly illustrates the benefits of using compression on low-bandwidth links. With compression enabled, the output rate at R1 has dropped as condensed data is now sent across the link. As a result, less bandwidth is consumed, and a higher throughput can be attained.

The show compress global EXEC command can be used to display a number of useful fields relating to the compression scheme enabled on the router. Example 15-13 shows the output of the show compress command at R1 and R2.

Example 15-13. Output of the show compress Command
R1#show compress
Serial3/2
         Software compression enabled
         uncompressed bytes xmt/rcv 1089240/1200
         1  min avg ratio xmt/rcv 5.564/0.049
         5  min avg ratio xmt/rcv 5.563/0.051
         10 min avg ratio xmt/rcv 5.563/0.051
         no bufs xmt 0 no bufs rcv 0
         resyncs 0
       Additional Stacker Stats:
       Transmit bytes:  Uncompressed =        0 Compressed = 189045
Received bytes:  Compressed =        920 Uncompressed = 0

R2#show compress
Serial1
         Software compression enabled
         uncompressed bytes xmt/rcv 1020/1089060
         1  min avg ratio xmt/rcv 0.044/5.566
         5  min avg ratio xmt/rcv 0.044/5.566
         10 min avg ratio xmt/rcv 0.044/5.566
         no bufs xmt 0 no bufs rcv 0
         resyncs 0
       Additional Stacker Stats:
       Transmit bytes:  Uncompressed =        0 Compressed = 782
       Received bytes:  Compressed =     188907 Uncompressed = 0

The first field in the show compress command output indicates the name and number of the interface configured with compression, followed by the type of compression algorithm in use. The output of the show compress command also indicates that software compression method is in use.

The "uncompressed bytes" shows the total number of uncompressed bytes sent and received. This field indicates the number of packets handled by the router that cannot be compressed. Then the 1, 5, and 10 "min avg ratio" shows the static compression ratio for bytes sent and received. In this example, the compression ratio at R1 is approximately 5.5:1. Typically, on many production networks where a greater mix of different traffic types exists, a compression ratio of around 2:1 is realistic.

The final fields represent information related to the Stacker compression algorithm. This information shows the total number of transmitted and received bytes handled by Stacker compression.

Verifying the Effects of FRF.9 Payload Compression (Software)

In the next example, the compression scheme configured at R1 and R2 is switched to the FRF.9 payload compression method. A comparison between FRF.9 payload compression and Cisco proprietary payload compression is performed.

NOTE

You are recommended to temporarily shut down the Frame Relay interface or subinterface with the shutdown command before adding or changing the compression scheme on the router. After the compression configurations or changes are completed, the interface should be enabled with the no shutdown command. This entire procedure allows the Cisco IOS code to recognize the new configuration changes and enables the compression commands to take effect.

The Cisco proprietary payload compression commands are unconfigured and replaced with FRF.9 payload compression commands on R1 and R2, as shown in Example 15-14.

Example 15-14. Unconfiguring Cisco Proprietary Payload Compression and Enabling FRF.9 Payload Compression at R1 and R2
R1#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
R1(config)#interface serial3/2.100
R1(config-subif)#no frame-relay payload-compression packet-by-packet
R1(config-subif)#frame-relay payload-compression frf9 stac software

R2#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
R2(config)#interface serial1.200
R2(config-subif)#no frame-relay payload-compression packet-by-packet
R2(config-subif)#frame-relay payload-compression frf9 stac software

The same test case in the no-compression and Cisco proprietary compression sections is performed again for FRF.9 payload compression. Example 15-15 shows the output of the show interface command at router R1 after the TTCP test is completed.

Example 15-15. Output of show interface Command at R1 with FRF.9 Payload Compression
R1#show interface s3/2
Serial3/2 is up, line protocol is up
  Hardware is M8T-V.35
  MTU 1500 bytes, BW 32 Kbit, DLY 20000 usec,
     reliability 255/255, txload 55/255, rxload 31/255
  Encapsulation FRAME-RELAY, crc 16, loopback not set
  Keepalive set (10 sec)
  LMI enq sent  5, LMI stat recvd 5, LMI upd recvd 0, DTE LMI up
  LMI enq recvd 0, LMI stat sent  0, LMI upd sent  0
  LMI DLCI 1023  LMI type is CISCO  frame relay DTE
  FR SVC disabled, LAPF state down
  Broadcast queue 0/64, broadcasts sent/dropped 13/0, interface broadcasts 12
  Last input 00:00:02, output 00:00:00, output hang never
  Last clearing of "show interface" counters 00:00:53
  Queueing strategy: fifo
  Output queue 0/40, 0 drops; input queue 0/75, 0 drops
  5 minute input rate 4000 bits/sec, 7 packets/sec
  5 minute output rate 7000 bits/sec, 7 packets/sec
     524 packets input, 22529 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
     1028 packets output, 66769 bytes, 0 underruns
     0 output errors, 0 collisions, 0 interface resets
     0 output buffer failures, 0 output buffers swapped out
     0 carrier transitions     DCD=up  DSR=up  DTR=up  RTS=up  CTS=up

Example 15-16 shows the result of the TTCP test at the hosts with Frame Relay FRF.9 payload compression enabled at both routers.

Example 15-16. Results of TTCP with FRF.9 Payload Compression
D:\Downloads\Sharewares>WSTTCP -t -l1048 n1000 20.0.0.2
wsttcp-t: buflen=1048, nbuf=1000, align=16384/0, port=5001  tcp  -> 20.0.0.2
wsttcp-t: connect (mss 1460, sndwnd 4128, rcvwnd 4128)
wsttcp-t: 1048000 bytes in 28468 ms (28.468 real seconds) (~35 kB/s) +++
wsttcp-t: 1000 I/O calls
wsttcp-t: 0 sleeps (0 ms total) (0 ms average)
Local host: 10.0.0.2, Local port: 11011
Foreign host: 20.0.0.2, Foreign port: 5001

C:\Programs\Sharewares>WSTTCP r l1048
wsttcp-r: buflen=1048, align=16384/0, port=5001
rcvwndsize=4128, delayedack=yes  tcp
wsttcp-r: accept from 10.0.0.2 (mss 1460, sndwnd 4128, rcvwnd 4128)
wsttcp-r: 1048000 bytes in 28496 ms (28.496 real seconds) (~35 kB/s) +++
wsttcp-r: 1006 I/O calls
wsttcp-r: 0 sleeps (0 ms total) (0 ms average)
Connection state is ESTAB, I/O status: 1, unread input bytes: 0
Local host: 20.0.0.2, Local port: 11011
Foreign host: 10.0.0.2, Foreign port: 5001

Comparing the two results from both Cisco proprietary and FRF.9 payload compression, the elapsed time for FRF.9 payload compression is even lower, at exactly 28 seconds (compared to 49 seconds with Cisco proprietary compression). The attained throughput rate is higher at approximately 294 kbps. FRF.9 payload compression offers a higher performance, but it is more CPU intensive because a dictionary is now maintained for every Frame Relay connection.

Verifying the Effects of TCP/IP Header Compression

This section provides examples to demonstrate the effects of TCP/IP header compression on the Frame Relay network. The TTCP network utility tool is again used to compare the effects of TCP/IP header compression on the network.

The frame-relay ip tcp header-compression command is now used to enable TCP/IP header compression on the point-to-point subinterface on routers R1 and R2. Example 15-17 shows the configuration commands added to R1 and R2 to enable TCP/IP header compression. Note that before doing this change, if the Frame Relay interfaces are using the IETF encapsulation, they must be reset to use the Cisco proprietary encapsulation, otherwise the TCP/IP header compression will not be accepted.

Example 15-17. Configuring TCP/IP Header Compression on R1 and R2
R1#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
R1(config)#interface s3/2.100
R1(config-subif)#frame-relay ip tcp header-compression

R2#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
R2(config)#interface s1.200
R2(config-subif)#frame-relay ip tcp header-compression

TCP/IP header compression over Frame Relay using the default active mode is now enabled at both R1 and R2. After the commands have been added, this can be verified by using the show frame-relay map command on R1 and R2 to confirm that TCP/IP header compression is correctly enabled on the desired DLCI. This is shown in Example 15-18.

Example 15-18. show frame-relay map Command Indicates TCP/IP Header Compression Information
R1#show frame-relay map
Serial3/2.100 (up): point-to-point dlci, dlci 100(0x64,0x1840), broadcast
          status defined, active,
TCP/IP Header Compression  (inherited), connections: 256

R2#show frame-relay map
Serial1.200 (up): point-to-point dlci, dlci 200(0xC8,0x3080), broadcast
          status defined, active,
TCP/IP Header Compression  (inherited), connections: 256

The same test is performed again by sending TCP packets across the Frame Relay link using the TTCP utility at the hosts. Example 15-19 reveals the results of the test after the TCP/IP header compression configurations are added.

Example 15-19. Output of show interface Command at R1 with TCP/IP Header Compression
R1#show interface s3/2
Serial3/2 is up, line protocol is up
  Hardware is M8T-V.35
  MTU 1500 bytes, BW 32 Kbit, DLY 20000 usec,
     reliability 255/255, txload 30/255, rxload 1/255
  Encapsulation FRAME-RELAY, crc 16, loopback not set
  Keepalive set (10 sec)
  LMI enq sent  24, LMI stat recvd 24, LMI upd recvd 0, DTE LMI up
  LMI enq recvd 0, LMI stat sent  0, LMI upd sent  0
  LMI DLCI 1023  LMI type is CISCO  frame relay DTE
  FR SVC disabled, LAPF state down
  Broadcast queue 0/64, broadcasts sent/dropped 56/0, interface broadcasts 52
  Last input 00:00:01, output 00:00:04, output hang never
  Last clearing of "show interface" counters 00:03:59
  Queueing strategy: fifo
  Output queue 0/40, 0 drops; input queue 0/75, 0 drops
  5 minute input rate 0 bits/sec, 4 packets/sec
  5 minute output rate 36000 bits/sec, 4 packets/sec
     1170 packets input, 18208 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
     1358 packets output, 1063337 bytes, 0 underruns
     0 output errors, 0 collisions, 0 interface resets
     0 output buffer failures, 0 output buffers swapped out
0 carrier transitions     DCD=up  DSR=up  DTR=up  RTS=up  CTS=up

Example 15-20 shows the result of the TTCP test at the hosts with TCP/IP header compression enabled at both routers.

Example 15-20. Results of TTCP with TCP/IP Header Compression over Frame Relay
D:\Downloads\Sharewares>WSTTCP -t -l1048 n1000 20.0.0.2
wsttcp-t: buflen=1048, nbuf=1000, align=16384/0, port=5001  tcp  -> 20.0.0.2
wsttcp-t: connect (mss 1460, sndwnd 4128, rcvwnd 4128)
wsttcp-t: 1048000 bytes in 223900 ms (223.900 real seconds) (~3 kB/s) +++
wsttcp-t: 1000 I/O calls
wsttcp-t: 0 sleeps (0 ms total) (0 ms average)
Local host: 10.0.0.2, Local port: 11011
Foreign host: 20.0.0.2, Foreign port: 5001

C:\Programs\Sharewares>WSTTCP r l1048
wsttcp-r: buflen=1048, align=16384/0, port=5001
rcvwndsize=4128, delayedack=yes  tcp
wsttcp-r: accept from 10.0.0.2 (mss 1460, sndwnd 4128, rcvwnd 4128)
wsttcp-r: 1048000 bytes in 224552 ms (224.552 real seconds) (~3 kB/s) +++
wsttcp-r: 1274 I/O calls
wsttcp-r: 0 sleeps (0 ms total) (0 ms average)
Connection state is ESTAB, I/O status: 1, unread input bytes: 0
Local host: 20.0.0.2, Local port: 11011
Foreign host: 10.0.0.2, Foreign port: 5001

When TCP/IP header compression is used, the time it takes to complete the transaction is approximately the same as the results for the no-compression case. As seen in this test, because of the relatively large size of the packet payload generated, TCP/IP header compression offers little benefit. In this case, compressing the headers alone without condensing the large payload size adds little improvement to the overall performance. TCP/IP header compression is most useful in situations where the ratio of headers to data payload is relatively large.

The show ip tcp header-compression global EXEC command can be used to provide detailed statistics and information related to TCP/IP header compression. The show ip tcp header-compression command output at R1 is provided in Example 15-21.

Example 15-21. Output of show ip tcp header-compression Command at R1
R1#show ip tcp header-compression
TCP/IP header compression statistics:
 DLCI 100        Link/Destination info: point-to-point dlci
  Interface Serial3/2:
    Rcvd:    2182 total, 2180 compressed, 0 errors
             0 dropped, 0 buffer copies, 0 buffer failures
    Sent:    2549 total, 2547 compressed,
             91682 bytes saved, 2106198 bytes sent
             1.4 efficiency improvement factor
    Connect: 256 rx slots, 256 tx slots,
             2 long searches, 2 misses 0 collisions
             99% hit ratio, five minute miss rate 0 misses/sec, 0 max

R2#show ip tcp header-compres
TCP/IP header compression statistics:
 DLCI 200        Link/Destination info: point-to-point dlci
  Interface Serial1:
    Rcvd:    2549 total, 2547 compressed, 0 errors
             0 dropped, 0 buffer copies, 0 buffer failures
    Sent:    2182 total, 2180 compressed,
             67150 bytes saved, 20050 bytes sent
             4.34 efficiency improvement factor
    Connect: 256 rx slots, 256 tx slots,
             2 long searches, 2 misses 0 collisions
             99% hit ratio, five minute miss rate 0 misses/sec, 0 max

Referring to Example 15-21 and the highlighted fields, the "number of bytes compressed" field indicates the total number of compressed TCP packets sent and received. The value in the "efficiency improvement factor" field shows the improvement in line efficiency because of TCP header compression. The "hit ratio" field points out the percentage of times that the software found a match and was able to compress the header.

Verifying and Monitoring RTP Header Compression

Enabling RTP header compression (CRTP) on both ends of a low-bandwidth Frame Relay link can greatly reduce the network overhead if a substantial amount of RTP traffic is expected on the line. For example, if voice traffic and other data traffic types are sent on a Frame Relay link, CRTP ensures that the available bandwidth on the line is managed and optimized. CRTP is now configured on routers R1 and R2, as shown in Example 15-22.

Example 15-22. Configuring RTP Header Compression on R1 and R2
R1#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
R1(config)#interface s3/2.100
R1(config-subif)#frame-relay ip rtp header-compression

R2#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
R2(config)#interface s1.200
R2(config-subif)#frame-relay ip rtp header-compression

To observe CRTP, you need to send active voice traffic over the Frame Relay network. The network depicted in Figure 15-8 is modified slightly by adding FXS voice ports to the routers to make voice calls. This also requires dial-peers to be configured on both routers R1 and R2. Figure 15-9 shows the modified Frame Relay network diagram for observing CRTP.

Figure 15-9. Frame Relay Network with Added Voice Components

Example 15-23 shows the configurations of routers R1 and R2 in Figure 15-9.

Example 15-23. Configurations of Routers R1 and R2
! R1

<output omitted>

ip routing
!
interface Serial3/2
 no ip address
 encapsulation frame-relay
 no fair-queue
 frame-relay traffic-shaping
!
interface Serial3/2.100 point-to-point
 ip address 172.16.1.1 255.255.255.252
 frame-relay interface-dlci 100
 frame-relay ip rtp header-compression
!
dial-peer voice 1 pots
 destination-pattern 1001
 port 1/0
!
dial-peer voice 2 voip
 destination-pattern 2001
 session target ipv4:172.16.1.2

! R2

<output omitted>

ip routing
!
interface Serial1
 no ip address
 encapsulation frame-relay
!
interface Serial1.200 point-to-point
 ip address 172.16.1.2 255.255.255.252
 frame-relay interface-dlci 200
 frame-relay ip rtp header-compression
!
dial-peer voice 1 pots
 destination-pattern 2001
 port 2/0
!
dial-peer voice 2 voip
 destination-pattern 1001
 session target ipv4:172.16.1.1

The show frame-relay map command can be used on R1 and R2 to confirm that RTP header compression is correctly enabled on the desired DLCI. This is shown in Example 15-24.

Example 15-24. show frame-relay map Command Indicates RTP Header Compression Information
R1#show frame-relay map
Serial3/2.100 (up): point-to-point dlci, dlci 100(0x64,0x1840), broadcast
          status defined, active,
RTP Header Compression  (inherited), connections: 256

R2#show frame-relay map
Serial1.200 (up): point-to-point dlci, dlci 200(0xC8,0x3080), broadcast
          status defined, active,
RTP Header Compression  (inherited), connections: 256

Using the installed voice modules and phones connected directly to the routers, a voice call is placed in the direction from R1 to R2. The show frame-relay ip rtp header-compression [interface type number] global EXEC command can be used to display useful information and statistics related to CRTP. An example is given in Example 15-25.

Example 15-25. Output of show frame-relay ip rtp header-compression Command
R1#show frame-relay ip rtp header-compression interface Serial3/2
 DLCI 100        Link/Destination info: point-to-point dlci
  Interface Serial3/2: (passive, compression on)
    Rcvd:    703 total, 699 compressed, 2 errors
             2 dropped, 0 buffer copies, 0 buffer failures
    Sent:    716 total, 713 compressed,
             27073 bytes saved, 115527 bytes sent
             1.23 efficiency improvement factor
    Connect: 101 rx slots, 101 tx slots,
             0 long searches, 3 misses 0 collisions, 0 negative cache hits
99% hit ratio, five minute miss rate 0 misses/sec, 0 max

Frame Relay IP RTP Priority

The Frame Relay IP RTP Priority feature, available in Cisco IOS Release 12.0(7)T, is based on a model similar to priority queuing, where a strict priority queue is reserved on a Frame Relay virtual circuit for delay-sensitive traffic. The Frame Relay IP RTP Priority feature can be used with the Frame Relay RTP header compression feature to improve the performance on a Frame Relay network for real-time applications, such as voice. The real-time traffic can be classified by its RTP port numbers and allocated to the priority queue, in preference over other non-voice traffic.

Before configuring the Frame Relay IP RTP Priority feature, both Frame Relay Traffic Shaping and Frame Relay Fragmentation (FRF.12) must be enabled. Use the frame-relay ip rtp priority starting-rtp-port-number port-number-range bandwidth map-class configuration command to configure Frame Relay IP RTP Priority. With this command, a strict priority queue on the Frame Relay PVC is reserved for a set of RTP packet flows belonging to a range of UDP destination ports. Example 15-26 shows a configuration where both RTP header compression and Frame Relay IP RTP Priority are configured.

Example 15-26. Configuration Example for Frame Relay IP RTP Priority
interface Serial3/2
 no ip address
 encapsulation frame-relay
 frame-relay traffic-shaping
!
interface Serial3/2.100 point-to-point
 ip address 172.16.1.1 255.255.255.252
 frame-relay interface-dlci 100
  class SHAPING
 frame-relay ip rtp header-compression
!
map-class frame-relay SHAPING
 frame-relay cir 38400
 frame-relay bc 4800
 frame-relay be 0
 no frame-relay adaptive-shaping
 frame-relay fragment 250
 frame-relay ip rtp priority 16384 16383 1024

In this example, RTP traffic matching UDP port numbers in the range of 16384 to 32767 is allocated a reserved bandwidth of 1024 kbps in the priority queue.


Troubleshooting Frame Relay Compression

This final section discusses several common compression issues encountered by users and the most probable causes of these problems.

One of the most common causes of compression failures is mismatched Cisco IOS software versions running on the routers involved in performing compression. It is highly recommended to have the same IOS software version on both sides of the compression link. This reduces the likelihood of compatibility problems.

In other cases, compression problems are usually caused by misconfigurations by users. Always ensure that the same type of compression scheme is used on both sides of the link.

When performing software compression, the current utilization of the CPU should be monitored closely to ensure that compression is not using up all the CPU cycles and overloading it. Some compression calculations are particularly CPU intensive. As such, attention should be given to ensure that the router has a fast CPU and sufficient memory required to perform the compression computation tasks. Hardware-assisted compression should be considered when the router is unable to handle the load of software compression computations.

Sometimes the compression ratio obtained can be less than one. This occurs when the data is actually expanded instead of being compressed, caused by compressing data that is already compressed or an overly busy CPU. In the latter case, hardware-based compression usually solves the problem.


Summary

This chapter presented compression over Frame Relay. It focused on the Cisco IOS Frame Relay features that support compression on Frame Relay networks. Compression allows users to reduce the size of their data for transmission, which effectively allows more data to be transmitted with the same bandwidth. In this way, compression helps to achieve higher throughput and better network performance.

This chapter looked at the various compression algorithms and schemes for Frame Relay that are supported by the Cisco IOS software. The compression techniques discussed include the Cisco proprietary payload compression, FRF.9 vendor-independent payload compression, TCP/IP header compression, and RTP header compression with the Frame Relay IP RTP Priority feature.

This chapter also compared the differences between software compression via the router CPU and hardware compression using specialized hardware compression modules. Then this chapter presented a basic guide to the appropriate use of compression on Frame Relay networks. This chapter also covered the configuration tasks and Cisco IOS configuration commands required to enable every compression scheme discussed in this chapter on Cisco routers. Finally, this chapter demonstrated the Cisco IOS show commands for monitoring and maintaining compression configurations on Cisco routers and discussed the most common causes of problems related to compression.

In the next chapter, the Cisco Frame Relay Fragmentation feature will be discussed.


Review Questions

1: | How does compression help to achieve higher overall throughput on the link, and how does it benefit Frame Relay networks?
2: | How do header compression and payload compression compare?
3: | How do Stacker and Predictor compression algorithms compare?
4: | What are the Cisco IOS configuration commands for Frame Relay required to enable payload compression on multipoint interfaces and point-to-point subinterfaces?
5: | What are the benefits associated with using hardware compression instead of software compression?
6: | What is the Cisco IOS show command that allows users to monitor the payload compression configurations on Cisco routers?


References

  • RFC 1144: Compressing TCP/IP Headers for Low-Speed Serial Links, by Van Jacobson: http://www.faqs.org/rfcs/rfc1144.html

  • RFC 1889: RTP: A Transport Protocol for Real-Time Applications, by Henning Schulzrinne, Stephen L. Casner, Ron Frederick, and Van Jacobson: http://www.faqs.org/rfcs/rfc1889.html

  • RFC 2508: Compressing IP/UDP/RTP Headers for Low-Speed Serial Links, by Stephen L. Casner, Van Jacobson: http://www.faqs.org/rfcs/rfc2508.html

  • Frame Relay Forum Implementation Agreement FRF.9: Data Compression over Frame Relay Implementation Agreement, edited by Don Cantwell: http://www.mplsforum.org/frame/Approved/FRF.9/frf9.pdf

  • Cisco IOS Release 12.1 WAN Configuration Guide: http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121cgcr/wan_c/wcdfrely.htm

  • Cisco IOS Release 12.1 WAN Command Reference: http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121cgcr/wan_r/wrdfrely.htm


Chapter 16. Frame Relay Fragmentation

Recent years have seen the rapid emergence of voice technologies and the increasing trend of integrating voice onto data networks. Frame Relay Fragmentation has an important role in ensuring the quality of service (QoS) for real-time delay-sensitive traffic.

This chapter discusses Cisco's Frame Relay Fragmentation solutions. Generally, Fragmentation is a Link-Efficiency tool which helps to reduce the delay experienced by smaller packets when the smaller packets are transmitted together with larger packets over a slow-speed link. Frame Relay Fragmentation allows large data frames to be segmented into smaller frames, in an effort to reduce the variable delay or jitters experienced by the usually smaller and delay-sensitive voice frames. This chapter discusses Cisco's implementations of the Frame Relay Fragmentation feature based on the Frame Relay Forum Implementation Agreement FRF.12 for Frame Relay Fragmentation (on both End-to-End and Switched Permanent Virtual Circuits (PVCs)), Frame Relay Fragmentation using FRF.11 Annex C, and Cisco Proprietary Fragmentation. The end of the chapter looks at using the Frame Relay Fragmentation feature with hardware-assisted compression. Cisco Frame Relay compression solutions are discussed in Chapter 15, "Compression over Frame Relay."

This chapter begins by looking at the issues faced by network managers today to support delay-sensitive applications, such as Voice over IP (VoIP), over slow-speed Frame Relay links and explains how Frame Relay Fragmentation can be a viable solution to overcome these challenges. Next, this chapter introduces the different Frame Relay Fragmentation schemes that are supported on Cisco routers. Then, a sample scenario with practical configuration examples is used to explain how each supported Frame Relay Fragmentation feature can be used to achieve the required level of QoS for real-time traffic. The configuration tasks for enabling Frame Relay Fragmentation on a Cisco router, as well as the Cisco IOS commands for monitoring and troubleshooting Frame Relay Fragmentation, are also explained.

The topics and questions that this chapter addresses include the following:

  • Overview of Frame Relay Fragmentation and its benefits

  • Cisco's implementation of Frame Relay Fragmentation: Cisco proprietary Frame Relay Fragmentation, Frame Relay Fragmentation using FRF.11 Annex C, and FRF.12 Frame Relay Fragmentation

  • Use of hardware compression modules with Frame Relay Fragmentation

  • Configuring Frame Relay Fragmentation on Cisco routers with the Cisco IOS software

  • Monitoring and maintaining Frame Relay Fragmentation on Cisco routers with the Cisco IOS show commands

After completing this chapter, readers will recognize the importance and the benefits of deploying fragmentation to support integrated voice and data traffic on Frame Relay networks. Readers will understand the operation of Frame Relay Fragmentation, the different types of Frame Relay Fragmentation supported by Cisco devices, and how performance can be optimized by combining Frame Relay Fragmentation with Frame Relay hardware compression. Readers will learn how to configure the Frame Relay Fragmentation types supported by the Cisco IOS software. Readers will also learn how to use the Cisco IOS show commands to monitor and maintain the Frame Relay Fragmentation configurations on Cisco routers.


Current Issues

In the early 1990s, Frame Relay technology was conceived to address users' demand for a higher-speed data link layer protocol with much less overhead. Frame Relay was designed to operate over higher-quality physical media with low error rates. This design significantly reduced the error correction overhead associated with legacy data-link protocols, such as X.25. The development of Frame Relay was driven by users' requirements, mainly on data networks. Voice technologies were still pretty much dormant until the recent advent of IP and multimedia applications, such as voice and video, changed the landscape. The basic Frame Relay protocol was not designed to offer the QoS features required to support real-time traffic.

The integration of voice onto data networks presents a host of new challenges to network engineers. Because the nature of data and voice traffic differs greatly, mixing them on the same network generally does not work out well. Unlike data traffic, voice traffic is delay-sensitive and extremely susceptive to latency. For example, a network with inconsistent performance with respect to latency could cause delay variation in its delivery of voice packets, or at worst, the complete loss of voice packets. This could cause jitters, echoes, or broken voice conversation for the users of the application.

NOTE

For good voice quality, the end-to-end one-way delay should be less than 150 msec.

To support a multimedia application such as video voice conferencing, the underlying network should provide a seamless transport for the audio and video packets exchanged between the hosts with minimal end-to-end delay. If network latency causes time-sensitive packets to arrive late or packets to be lost, this can result in jitters, echoes, or glitches in the heard conversation. In the worst case, the voice quality can become so bad that the users are not able to comprehend each other at all.

Because the average data frames are normally longer than the average voice frames, mixing both types of traffic on the same network could potentially cause network delays to the voice traffic and seriously jeopardize the voice quality. When the network is transmitting data frames, the longer data frames occupy an access link for a relatively longer period of time than voice frames. This could cause voice frames to be delayed behind the data frames while waiting for their turn for transmission onto the access link. Figure 16-1 illustrates this problem.

Figure 16-1. Smaller Voice Frames Held Up Behind Larger Data Frames

An important part of the end-to-end delay encountered by voice frames is because of the serialization delay. The serialization delay is defined as the time it takes to place the bits of an entire frame onto an interface.

The serialization delay is governed by the following formula:

serialization delay = frame size (in bits) / link bandwidth (in bits/sec)

For example, a 1500-byte frame takes approximately 214 ms to leave the router on a 56-kbps line. For voice traffic, the serialization delay ideally should not exceed 20 ms. A high serialization delay can cause delay and latency for voice traffic. Some form of network control needs to be used.


Solutions to Current Issues

The Frame Relay Forum's standard for fragmenting large Frame Relay frames into smaller pieces is defined in the FRF.12 Implementation Agreement. The FRF.12 Implementation Agreement defines a fragmentation scheme for Frame Relay to support voice and other real-time or delay-sensitive data on low-speed Frame Relay links. The FRF.12 Implementation Agreement can be downloaded from the Frame Relay Forum public web site at this address: http://www.mplsforum.org/frame/Approved/FRF.12/frf12.pdf.

Two other fragmentation schemes are supported by the Cisco IOS software on Cisco devices. They are the Frame Relay Fragmentation using FRF.11 Annex C and the Cisco proprietary fragmentation. FRF.11 is the Frame Relay Forum's standard for supporting Voice over Frame Relay (VoFR). FRF.11 can be downloaded from the Frame Relay Forum public web site at this address: http://www.mplsforum.org/frame/Approved/FRF.11/frf_11.1.pdf.

In general, Frame Relay Fragmentation supports the transport of mixed voice and data traffic across the same interface without the longer data frames causing excessive delay to the normally smaller-sized voice packets. On Frame Relay networks, fragmentation is especially beneficial on low-speed links where the serialization delay can be very high. The longer data frames are fragmented by the router into a sequence of shorter frames at the sending end. Eventually, the fragments are received and reassembled at the receiving end. By limiting the maximum frame size of the data packets, the fragmentation process allows the smaller fragmented data frames to be interleaved with the real-time delay-sensitive voice frames. This interleaving procedure is shown in Figure 16-2.

Figure 16-2. Interleaving of Voice and Smaller Fragmented Data Packets

As illustrated in the diagram in Figure 16-2, using a fragmentation scheme in a mixed voice and data traffic environment allows network managers to control the size of the data frames and decreases the network latency experienced by delay-sensitive traffic. The longer data frames are segmented into a series of smaller fragments and are interleaved together with the similar-sized voice packets. Subsequently, the data fragments are reassembled at the receiving end. As a result, the wait time of the smaller voice packets is reduced, achieving the appropriate level of QoS required by real-time traffic.


Cisco Implementations of Frame Relay Fragmentation

This section discusses the few fragmentation schemes supported by Cisco. Cisco has developed three different methods of performing fragmentation with Frame Relay: FRF.12 Fragmentation, Frame Relay Fragmentation using FRF.11 Annex C, and the Cisco Proprietary Fragmentation. Each fragmentation scheme uses a different data format or encapsulation. Frame Relay frames are fragmented based on one of the three formats, depending on how the Frame Relay PVC was set up.

It is important to note that when Frame Relay End-to-End FRF.12 Fragmentation is configured, Weighted Fair Queuing (WFQ) or Low Latency Queuing (LLQ) is required. If Frame Relay End-to-End FRF.12 Fragmentation is configured in a Frame Relay map class, but the queuing type enabled is not WFQ or LLQ, the configured queuing type is automatically overridden by WFQ using the default values. WFQ for Frame Relay is configured with the frame-relay fair-queue map-class configuration command.

The following sections look at each supported fragmentation type.

Frame Relay Fragmentation Implementation Agreement FRF.12

The Cisco IOS software supports Frame Relay Fragmentation based on the Frame Relay Forum Implementation Agreement on Fragmentation FRF.12. FRF.12 defines standards for three types of Frame Relay Fragmentation: User-to-Network Interface (UNI), Network-to-Network Interface (NNI) and End-to-End between two Frame Relay DTE devices. The Frame Relay End-to-End FRF.12 Fragmentation feature is available in Cisco IOS Software Release 12.1(2)T or later.

FRF.12 Fragmentation supports the transport of both real-time and non-real-time traffic across the same interface without causing excessive delay to the real-time traffic. An example of real-time traffic that is delay-sensitive is voice. FRF.12 is used to fragment the larger data frames into a sequence of shorter frames so that they can be interleaved with the real-time traffic for transmission. The fragmented data frames are reassembled at the receiving end.

Cisco supports End-to-End FRF.12 Fragmentation and FRF.12 Fragmentation on switched PVCs.

End-to-End FRF.12 Fragmentation

For End-to-End FRF.12 Fragmentation, a two-octet Frame Relay Fragmentation header follows the Frame Relay header (with multiprotocol encapsulations over Frame Relay options). A value of 0xB1 is specially assigned to the Network Layer Protocol ID (NLPID) field to identify the fragmentation header format. The data format for End-to-End FRF.12 Fragmentation is shown in Figure 16-3.

Figure 16-3. End-to-End FRF.12 Fragmentation Format

Within the fragmentation header, the B, E, and C bits represent beginning fragment, ending fragment, and control bit, respectively. The B bit is a 1-bit field that is set to the value of 1 when this is the first data fragment. For the remaining fragments from the same frame, this value is set to 0. The E bit is also a 1-bit field that is used to represent the last fragment of the frame. The E bit is set to the value of 1 for the last fragment and 0 for all other data fragments. If both the B and E bits are set to 1, this means that the fragment is the first and the last of the frame. The last C bit is set to 0 in all fragments, and it is reserved for future control functions.

The sequence number is a 12-bit binary number that is incremented for every data fragment transmitted on a virtual circuit (VC). The sequence number is used for reassembly after all fragments have been received.

End-to-End FRF.12 Fragmentation is configured on a per-PVC basis using a Frame Relay map class on a Cisco router. The frame-relay fragment fragment_size map-class configuration command sets up FRF.12 Fragmentation in the map class. The valid range for the fragment_size is from 16 to 1600 bytes, and the default value is 53 bytes. After configuring the Frame Relay map class, it can be applied to one or many PVCs to turn on FRF.12 Fragmentation. However, note that Frame Relay Traffic Shaping must be enabled at the main interface in order for Frame Relay Fragmentation to work. This is accomplished by configuring the frame-relay traffic-shaping command at the main interface level.

Figure 16-4 illustrates End-to-End FRF.12 Fragmentation between two peers in a Frame Relay network.

Figure 16-4. End-to-End FRF.12 Fragmentation

FRF.12 Support on Switched PVC

On Cisco routers configured as Frame Relay switches, the FRF.12 Fragmentation feature can be enabled on switched PVCs. Presently, only FRF.12 Fragmentation can be configured on switched PVCs on Cisco routers. Neither FRF.11 Annex C Fragmentation nor Cisco proprietary fragmentation are currently supported.

In a mixed voice and data network, Frame Relay access devices can transmit large data packets that can cause long serialization delays across low-speed trunks in switched Frame Relay networks. This problem is depicted in Figure 16-5.

Figure 16-5. Frame Relay Switched Network Without Fragmentation

There are many Frame Relay access devices that do not support the FRF.12 standard for End-to-End Fragmentation. An alternative is to perform the Frame Relay Fragmentation in the Frame Relay network. FRF.12 can be used between Frame Relay switches to reduce the serialization delay. This is shown in Figure 16-6.

Figure 16-6. Using FRF.12 Fragmentation on Switched PVCs

As shown in Figure 16-6, when a Frame Relay switch (referred to as an edge router) receives large data frames that exceed the configured fragment size, it fragments those packets before transmitting them across the switched network. In most cases, the larger data frames are fragmented by the Frame Relay switch, while the voice frames that are smaller than the chosen fragment size pass through without fragmentation.

The edge router that receives the fragmented packets reassembles them before forwarding them to the Frame Relay access device that does not support FRF.12. However, if the Frame Relay access device supports FRF.12, the edge router forwards the fragmented packets to the Frame Relay access device without performing the reassembly. The destination Frame Relay access device itself reassembles the received fragmented packets. The configuration tasks and examples of FRF.12 fragmentation on switched PVCs is presented in the next section.

Figure 16-7 shows the data format of FRF.12 Fragmentation for switched PVCs.

Figure 16-7. FRF.12 Fragmentation on Switched PVC Format

Unlike the End-to-End Fragmentation format, the format illustrated in Figure 16-7 begins with a two-octet fragmentation header followed by the Frame Relay header. The function of the B, E, and C bits here is identical to that in the End-to-End Fragmentation format. These bits represent the beginning, end, and control bit, respectively. The use of the sequence number field is similar to that in the End-to-End Fragmentation format.

Comparing Figure 16-7 with the End-to-End Fragmentation format in Figure 16-3, observe the lowest order bit of the first octet is set to 1. This distinguishes the fragmentation header from the normal Frame Relay header. It also allows peers to detect misconfiguration, because both sides must agree on whether fragmentation is used or not. If an invalid frame is received, the frame is discarded.

Configuring FRF.12 Fragmentation on Switched PVCs

To configure FRF.12 Fragmentation on switched PVCs, the switched keyword must be specified with the frame-relay fragment command on the routers configured as Frame Relay switches. The frame-relay fragment fragment_size switched map-class configuration command is used to enable FRF.12 Fragmentation on switched Frame Relay PVCs. The valid range for the fragment_size is from 16 to 1600 bytes, and the default value is 53 bytes. The map class is then applied to the switched Frame Relay PVC. Before this, Frame Relay Traffic Shaping must be enabled.

The conditions and restrictions on FRF.12 Fragmentation on switched PVCs are as follows:

  • Frame Relay Traffic Shaping must be enabled.

  • Interface queuing must be dual FIFO queuing or PVC interface priority queuing.

  • Switched PVCs must be configured with the connect command. The frame-relay route command will not work.

  • If the Frame Relay access device does not support FRF.12, no fragmentation occurs on the interface between the Frame Relay access device and the edge router. In this case, FRF.12 is performed on the interface between the edge router and the switched Frame Relay network.

  • If the Frame Relay access device is sending both voice and data on the same PVC, voice quality will suffer. This is because the edge router does not perform reordering of the packets on the switched PVCs. Send voice and data on separate PVCs.

FRF.12 Fragmentation with Hardware Compression Support

Before Cisco IOS Release 12.1(5)T, Frame Relay Fragmentation could not be used together with hardware-assisted compression on a Cisco router. Frame Relay Fragmentation worked with software compression only. The added Frame Relay Fragmentation with hardware compression feature allows FRF.12, FRF.11 Annex C, and Cisco proprietary fragmentation to work with hardware compression. Both Cisco and IETF Frame Relay encapsulation types are supported.

The feature enables hardware compression to be used on Frame Relay networks that transmit voice and use fragmentation. Hardware compression has a higher performance compared with software compression. The hardware method offloads the CPU-intensive compression calculations from the CPUs of the routers, thereby freeing up CPU cycles for other processes.

In addition, the Frame Relay Fragmentation with hardware compression feature allows header compression (TCP/IP and RTP headers) to be used on the same VC or interface. Before this feature was added, it was not possible to configure both payload compression and header compression. The header compression schemes worked only with Cisco proprietary encapsulation, and hardware compression (FRF.9) worked only with IETF encapsulation.

This feature introduces a new proprietary hardware and software compression protocol called data-stream compression, which can be used on the same VC or interface as header compression. The new data-stream compression is functionally equivalent to FRF.9 compression, but Cisco proprietary encapsulation must be used. When either data-stream or FRF.9 compression is used, Frame Relay FRF.12, FRF.11 Annex C, or Cisco proprietary fragmentation can be configured. However, on IETF encapsulated PVCs or interfaces, FRF.9 (both hardware and software) works with fragmentation, but header compression is not possible. As such, the new data-stream compression method and Cisco encapsulation must be used if header compression is also required.

Hardware and Software Compression Compatibility

The Frame Relay Fragmentation with hardware compression feature provides compatibility between hardware and software compression. This allows one peer to use hardware compression while the remote peer is using software compression.

Table 16-1 shows that Frame Relay Fragmentation with hardware compression is supported on the following platforms and requires the corresponding hardware compression modules.

Table 16-1. Supported Platforms and Hardware Compression Modules

Platforms

Compression Module

Cisco 2600 series

AIM-COMPR2

Cisco 3620 and Cisco 3640 series

NM-COMPR

Cisco 3660 series

AIM-COMPR4

Cisco 7200 series

SA-COMPR

Configuring Hardware Compression with Fragmentation

Two different Frame Relay commands can be used to configure hardware compression with fragmentation. If header compression (for example, TCP/IP header compression) is required, Cisco proprietary encapsulation must be used.

To configure hardware compression on a point-to-point Frame Relay subinterface, the frame-relay payload-compress data-stream stac configuration command is used. For a multipoint interface or subinterface, the frame-relay map protocol protocol-address dlci payload-compress data-stream stac configuration command can be used.

The following steps describe the configuration tasks required to enable hardware compression on a Cisco router. The configuration tasks begin in the global configuration mode.

Step 1. | Enter the interface configuration mode of the router for a Frame Relay physical interface, a multipoint logical subinterface, or a point-to-point logical subinterface.
Step 2. | On a multipoint interface, enable Frame Relay hardware compression with the frame-relay map protocol protocol-address dlci payload-compress hardware stac [hardware-options] interface configuration command.
Step 3. | On a point-to-point subinterface, enable Frame hardware compression with the frame-relay payload-compress hardware stac [hardware-options] interface configuration command.
Step 4. | (optional) Select the hardware options for Frame Relay hardware compression. The hardware-options keyword is part of the frame-relay payload-compress command shown in Step 2 and Step 3. The options available are csa keyword for using a compression service adaptor, or distributed keyword for enabling compression on a VIP2.
Step 5. | (optional) If Cisco encapsulation is used, it is possible to enable header compression using either frame-relay ip tcp header-compression [passive] for TCP/IP header compression or frame-relay ip rtp header-compression [passive] for RTP header compression.

NOTE

The Frame Relay compression features that encompass FRF.9 payload compression (software), TCP/IP header compression, and RTP header compression are explained in Chapter 15.

It is important to note that VoFR and Voice over IP (VoIP) packets are not payload compressed when Frame Relay Fragmentation is used.

Example 16-1 and Example 16-2 show a configuration example of Frame Relay hardware compression and the resultant output of the show compress command, respectively. The hardware compression examples are based on the diagram in Figure 16-8.

Example 16-1. Configuration Example of Frame Relay Hardware
R1#show version
Cisco Internetwork Operating System Software
IOS (tm) 7200 Software (C7200-JS-M), Version 12.1(5)T10,  RELEASE SOFTWARE (fc2)
TAC Support: http://www.cisco.com/tac
Copyright  1986-2001 by cisco Systems, Inc.
Compiled Tue 07-Aug-01 18:02 by ccai
Image text-base: 0x60008960, data-base: 0x616F8000

ROM: System Bootstrap, Version 11.1(13)CA, EARLY DEPLOYMENT RELEASE SOFTWARE (fc1)
BOOTFLASH: 7200 Software (C7200-BOOT-M), Version 12.0(5), RELEASE SOFTWARE (fc1)

R1 uptime is 49 minutes
System returned to ROM by reload at 21:36:53 UTC Thu Apr 10 2003
System image file is "tftp://172.19.192.50/c7200-js-mz.121-5.T10"

cisco 7206 (NPE200) processor (revision B) with 114688K/16384K bytes of memory.
Processor board ID 6626210
R5000 CPU at 200Mhz, Implementation 35, Rev 2.1, 512KB L2 Cache
6 slot midplane, Version 1.3

Last reset from power-on
Bridging software.
X.25 software, Version 3.0.0.
SuperLAT software (copyright 1990 by Meridian Technology Corp).
TN3270 Emulation software.
Primary Rate ISDN software, Version 1.1.
8 Ethernet/IEEE 802.3 interface(s)
1 FastEthernet/IEEE 802.3 interface(s)
8 Serial network interface(s)
2 Channelized T1/PRI port(s)
1 Compression service adapter(s)
125K bytes of non-volatile configuration memory.
4096K bytes of packet SRAM memory.

4096K bytes of Flash internal SIMM (Sector size 256K).
Configuration register is 0x0

R1#show running-config
<output omitted>

interface Serial4/2
 no ip address
 encapsulation frame-relay
 frame-relay class fr_hwcomp
 frame-relay traffic-shaping
!
interface Serial4/2.102 point-to-point
 ip address 172.16.1.1 255.255.255.252
 frame-relay interface-dlci 102 CISCO
 frame-relay ip tcp header-compression
 frame-relay payload-compression data-stream stac
 !
map-class frame-relay fr_hwcomp
 frame-relay cir 128000
 no frame-relay adaptive-shaping
 frame-relay fair-queue
 frame-relay fragment 120
________________________________________________________________

R2#show running-config

<output omitted>

interface Serial1/0
 no ip address
 encapsulation frame-relay
 frame-relay class hw_comp
 frame-relay traffic-shaping
!
interface Serial1/0.201 point-to-point
 ip address 172.16.1.2 255.255.255.252
 frame-relay interface-dlci 201 CISCO
 frame-relay ip tcp header-compression
 frame-relay payload-compression data-stream stac
 !
map-class frame-relay hw_comp
 frame-relay cir 128000
 no frame-relay adaptive-shaping
 frame-relay fair-queue
 frame-relay fragment 120

Example 16-2. Compression Output of show compress Command from the Setup in Example 16-1
R1#ping
Protocol [ip]:
Target IP address: 172.16.1.2
Repeat count [5]: 20
Datagram size [100]: 500
Timeout in seconds [2]:
Extended commands [n]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 20, 500-byte ICMP Echos to 172.16.1.2, timeout is 2 seconds:
!!!!!!!!!!!!!!!!!!!!
Success rate is 100 percent (20/20), round-trip min/avg/max = 180/180/180 ms

R1#show compress
 Serial4/2 - DLCI: 102
     Hardware compression enabled
     CSA in slot 2 in use
     Compressed bytes sent:     11400 bytes   1 Kbits/sec  ratio: 0.884
     Compressed bytes recv:     10160 bytes   1 Kbits/sec  ratio: 0.000
     restarts: 27
last clearing of counters: 54 seconds
________________________________________________________________
R2#show compress
 Serial1/0 - DLCI: 201
     Hardware compression enabled
     CSA in slot 2 in use
     Compressed bytes sent:     11999 bytes   0 Kbits/sec  ratio: 0.883
     Compressed bytes recv:     10700 bytes   0 Kbits/sec  ratio: 0.000
     restarts: 27
last clearing of counters: 3456 seconds
________________________________________________________________
R1#show frame-relay ip tcp header-compression
DLCI 102        Link/Destination info: point-to-point dlci
  Interface Serial4/2:
    Rcvd:    0 total, 0 compressed, 0 errors
             0 dropped, 0 buffer copies, 0 buffer failures
    Sent:    0 total, 0 compressed,
             0 bytes saved, 0 bytes sent
    Connect: 256 rx slots, 256 tx slots,
             0 long searches, 0 misses 0 collisions

Figure 16-8. FRF.12 End-to-End Fragmentation and Hardware Compression Configured Between Two Peer Routers

[View full size image]

As seen in Example 16-2, an extended ping is performed directly to router R2's interface from R1. This generates an ICMP traffic stream across DLCI 102, which is compressed by the hardware compression module on R1 using the data-stream compression method. At R2, the compressed packets are received. The show compress command indicates "Hardware compression enabled." This implies that compression is now performed in the hardware compression module installed on the router. For example, on R1, this is performed on the Compression Service Adaptor (CSA) module installed in Slot 2.

Additionally, FRF.12 End-to-End Fragmentation is configured between routers R1 and R2. Observe that TCP/IP header compression is now enabled together with payload compression (via data-stream compression), and the Cisco encapsulation type must be used. The output of the show ip tcp header-compression command does not reveal that any active TCP/IP header compression took place because only ICMP packets were sent.

Frame Relay Fragmentation Using FRF.11 Annex C

The Frame Relay Forum Implementation Agreement FRF.11 defines the standards for VoFR. The VoFR implementation uses FRF.11 to define how voice and data are encapsulated on a Frame Relay DLCI. On a Frame Relay DLCI that is configured to carry voice, all packets, including data, use the FRF.11 encapsulation. FRF.11 also supports a fragmentation scheme in FRF.11 Annex C.

FRF.11 Annex C defines the way data is carried on an FRF.11 DLCI configured for VoFR. A Frame Relay device supporting fragmentation using FRF.11 Annex C is able to distinguish real-time voice frames from the data frames. The FRF.11 payload indicates the specific traffic type. Thus, only frames with a data payload type are fragmented. The real-time voice frames bypass fragmentation regardless of the voice frame's size.

When VoFR (FRF.11) and fragmentation are both enabled on a Frame Relay PVC, the Frame Relay fragments are transmitted on the DLCI in the FRF.11 Annex C format. When FRF.11 is enabled on a PVC configured with fragmentation, all data packets use the FRF.11 Annex C format. As such, all data packets, including VoIP packets, contain the fragmentation headers, regardless of the size. For VoIP, FRF.11 Fragmentation is not recommended; FRF.12 Fragmentation is the preferred method. Figure 16-9 shows the FRF.11 Annex C format.

Figure 16-9. FRF.11 Annex C Format

The use of the B, E, C bits and the sequence field are identical to those in the FRF.12 Fragmentation format.

The vofr Frame Relay DLCI configuration command is used to enable FRF.11 on a Frame Relay DLCI. It is also used to instruct the router to use FRF.11 Annex C format if fragmentation has been configured with the frame-relay fragment map-class configuration command. This feature is available in Cisco IOS Release 12.1(2)T or later.

Cisco Proprietary Fragmentation

Cisco supports a proprietary fragmentation format, which was implemented on the earlier releases of the Cisco MC3810 multiservice access concentrator platform. The Cisco proprietary form of fragmentation is used on data packets on a Frame Relay PVC that is also used for voice traffic. Cisco proprietary fragmentation is enabled with the vofr cisco DLCI configuration command. When the vofr cisco command is configured on a DLCI and fragmentation is enabled on a map class, the Cisco 2600, 3600, and 7200 series routers can interoperate as tandem nodes with Cisco MC3810 running Cisco IOS Releases before 12.0(3)XG or 12.0(4)T.


Monitoring and Troubleshooting Frame Relay Fragmentation

This section provides configuration examples of the Frame Relay Fragmentation features introduced in this chapter. The discussion in this section involves FRF.12 (both End-to-End and switched), FRF.11 Annex C, and Cisco proprietary fragmentation. The configuration tasks required to enable each type of fragmentation are introduced, in addition to the relevant IOS commands for monitoring and troubleshooting Frame Relay Fragmentation on Cisco devices.

Example 16-3 shows a typical configuration example of FRF.12 Fragmentation on switched PVCs. This configuration is based on the network depicted in Figure 16-10. In Figure 16-10, routers R2 and R3 are Cisco routers configured as Frame Relay switches on the edge of a switched Frame Relay network. In the earlier discussion about FRF.12 on switched PVCs, routers R2 and R3 were referred to as the edge routers. The Network-to-Network Interface (NNI) LMI is used between R2 and R3. Routers R1 and R4 represent Frame Relay access routers unable to support End-to-End FRF.12 Fragmentation.

Figure 16-10. Network for Verifying FRF.12 Fragmentation on Switched PVCs

In the future, remote LANs supporting real-time delay-sensitive applications will probably be joined to the Frame Relay network. To reduce serialization delay on the low-speed trunk between R2 and R3 in the switched Frame Relay network, FRF.12 Fragmentation is enabled on the switched PVCs between them. Frame fragmentation and reassembly takes place on routers R2 and R3.

Example 16-3. Configuration Examples of Routers in Figure 16-10
Router R1:

<output omitted>

ip routing
!
interface Serial1/1
 no ip address
 encapsulation frame-relay
!
interface Serial1/1.104 multipoint
 ip address 172.16.1.1 255.255.255.252
 frame-relay map ip 172.16.1.2 104 broadcast
________________________________________________________________
Router R2:

<output omitted>

frame-relay switching
!
interface Serial3/1
 no ip address
 encapsulation frame-relay
 clockrate 64000
 frame-relay interface-dlci 104 switched
 frame-relay intf-type dce
 !
interface Serial3/3
 no ip address
 encapsulation frame-relay
 clockrate 64000
 frame-relay traffic-shaping
 frame-relay interface-dlci 200 switched
  class fr_frag
 frame-relay intf-type nni
 !
map-class frame-relay fr_frag
 frame-relay cir 64000
 frame-relay bc 1000
 no frame-relay adaptive-shaping
 frame-relay fair-queue
 frame-relay fragment 100 switched
 !
connect FRF12 Serial3/1 104 Serial3/3 200
________________________________________________________________
Router R3:

<output omitted>

frame-relay switching
!
interface Serial2
 no ip address
 encapsulation frame-relay
 clockrate 64000
 frame-relay interface-dlci 401 switched
 frame-relay intf-type dce
 !
interface Serial3
 no ip address
 encapsulation frame-relay
 clockrate 64000
 frame-relay traffic-shaping
 frame-relay interface-dlci 200 switched
  class fr_frag
 frame-relay intf-type nni
 !
map-class frame-relay fr_frag
 frame-relay cir 64000
 frame-relay bc 1000
 no frame-relay adaptive-shaping
 frame-relay fair-queue
 frame-relay fragment 100 switched
 !
connect FRF12 Serial2 401 Serial3 200
________________________________________________________________
Router R4:

<output omitted>

ip routing
!
interface Serial1/0
 no ip address
 encapsulation frame-relay
!
interface Serial1/0.401 multipoint
 ip address 172.16.1.2 255.255.255.252
 frame-relay map ip 172.16.1.1 401 broadcast

After the routers are properly set and FRF.12 Fragmentation is configured, the show frame-relay fragment global EXEC command can be used to observe information regarding fragmentation on the router. Example 16-4 shows the output of the show frame-relay fragment command performed at R2.

Example 16-4. Output of the show frame-relay fragment Command at R2
R2#show frame-relay fragment
interface         dlci  frag-type    frag-size  in-frag    out-frag   dropped-frag
Serial3/3         200   end-to-end   100        0          0          0

The output of the show frame-relay fragment command indicates the type of fragmentation used on the specific DLCI. In this case, it shows that End-to-End FRF.12 Fragmentation is enabled on DLCI 200, though it doesn't indicate that FRF.12 is configured on a switched DLCI. "VoFR" in the "frag-type" field represents FRF.11 Annex C Fragmentation, whereas "VoFR-cisco" means Cisco proprietary fragmentation is used. The show frame-relay fragment command also shows the fragment size configured and the number of input, output, and dropped fragments. A large number of "dropped frag" is likely to be caused by a misconfiguration.

A more detailed version of the show frame-relay fragment command is available. The show frame-relay fragment interface type/number dlci command can be used to show additional fragmentation information besides the basic information. Example 16-5 shows the output of the more detailed version.

Example 16-5. Output of the show frame-relay fragment interface s3/3 200 Command at R2
R2#show frame-relay fragment interface Serial3/3 200

 fragment size 100                      fragment type end-to-end
 in fragmented pkts 20                  out fragmented pkts 20
 in fragmented bytes 1140               out fragmented bytes 1140
 in un-fragmented pkts 0                out un-fragmented pkts 0
 in un-fragmented bytes 0               out un-fragmented bytes 0
 in assembled pkts 10                   out pre-fragmented pkts 10
 in assembled bytes 1040                out pre-fragmented bytes 1040
 in dropped reassembling pkts 0         out dropped fragmenting pkts 0
 in timeouts 0
 in out-of-sequence fragments 0
 in fragments with unexpected B bit set 0
 in fragments with skipped sequence number 0
 out interleaved packets 0

If there are no errors encountered along the fragmentation path between the peers, some of the fragmentation information observed on the peers should match. For example, the total number of "in" and "out" fragmented packets between the peers should tally, as shown in the output of the show frame-relay fragment command performed on R2 and R3 in Example 16-6.

Example 16-6. Output of the show frame-relay fragment Command at R2 and R3 After Fragmentation Has Taken Place
R2#show frame-relay fragment interface Serial3/3 200

 fragment size 100                      fragment type end-to-end
 in fragmented pkts 20                  out fragmented pkts 20
 in fragmented bytes 1140               out fragmented bytes 1140
 in un-fragmented pkts 0                out un-fragmented pkts 0
 in un-fragmented bytes 0               out un-fragmented bytes 0
 in assembled pkts 10                   out pre-fragmented pkts 10
 in assembled bytes 1040                out pre-fragmented bytes 1040
 in dropped reassembling pkts 0         out dropped fragmenting pkts 0
 in timeouts 0
 in out-of-sequence fragments 0
 in fragments with unexpected B bit set 0
 in fragments with skipped sequence number 0
 out interleaved packets 0
________________________________________________________________
R3#show frame-relay fragment interface Serial3 200

 fragment size 100                      fragment type end-to-end
 in fragmented pkts 20                  out fragmented pkts 20
 in fragmented bytes 1140               out fragmented bytes 1140
 in un-fragmented pkts 0                out un-fragmented pkts 0
 in un-fragmented bytes 0               out un-fragmented bytes 0
 in assembled pkts 10                   out pre-fragmented pkts 10
 in assembled bytes 1040                out pre-fragmented bytes 1040
 in dropped reassembling pkts 0         out dropped fragmenting pkts 0
 in timeouts 0
 in out-of-sequence fragments 0
 in fragments with unexpected B bit set 0
 in fragments with skipped sequence number 0
 out interleaved packets 0

In the remaining examples, the network depicted in Figure 16-11 is used to verify End-to-End FRF.12, FRF.11 Annex C, and Cisco proprietary fragmentation on Cisco routers.

Figure 16-11. Network for Verifying End-to-End FRF.12, FRF.11 Annex C, and Cisco Proprietary Fragmentation

In Figure 16-11, routers R1 and R2 represent fragmentation peers at the edge of the Frame Relay network. Three DLCIs are configured at each end of the Frame Relay network, terminating at the routers. The three different fragmentation data formatsEnd-to-End FRF.12, FRF.11 Annex C, and Cisco proprietary fragmentationare configured on a per-VC basis on each DLCI. Example 16-7 shows the configurations of routers R1 and R2 in Figure 16-11.

Example 16-7. Configurations of Routers R1 and R2 in Figure 16-11
Router R1:

<output omitted>

ip routing
!
interface Serial2/1
 no ip address
 encapsulation frame-relay
 frame-relay class fragment
 frame-relay traffic-shaping
!
interface Serial2/1.102 point-to-point
 ip address 172.16.1.1 255.255.255.252
 frame-relay interface-dlci 102
!
interface Serial2/1.103 point-to-point
 ip address 172.16.1.5 255.255.255.252
 frame-relay interface-dlci 103
  vofr data 4 call-control 5
!
interface Serial2/1.104 point-to-point
 ip address 172.16.1.9 255.255.255.252
 frame-relay interface-dlci 104
vofr cisco
!
map-class frame-relay fragment
 frame-relay cir 64000
 no frame-relay adaptive-shaping
 frame-relay fair-queue
 frame-relay voice bandwidth 16000
 frame-relay fragment 100
________________________________________________________________
Router R2:

<output omitted>

ip routing
!
interface Serial3/1
 no ip address
 encapsulation frame-relay
 frame-relay class fragment
 frame-relay traffic-shaping
!
interface Serial3/1.201 point-to-point
 ip address 172.16.1.2 255.255.255.252
 frame-relay interface-dlci 201
!
interface Serial3/1.301 point-to-point
 ip address 172.16.1.6 255.255.255.252
 frame-relay interface-dlci 301
  vofr data 4 call-control 5
!
interface Serial3/1.401 point-to-point
 ip address 172.16.1.10 255.255.255.252
 frame-relay interface-dlci 401
  vofr cisco
!
map-class frame-relay fragment
 frame-relay cir 64000
 no frame-relay adaptive-shaping
 frame-relay fair-queue
 frame-relay voice bandwidth 16000
 frame-relay fragment 100

When Frame Relay Fragmentation is configured with the frame-relay fragment command under the Frame Relay map-class and the map-class is assigned to a Frame Relay DLCI, FRF.12 Fragmentation is the default fragmentation scheme enabled.

NOTE

When a Frame Relay map class is assigned to the physical interface with the frame-relay class map-class-name command, the same map class is inherited by all subinterfaces on the main interface. The more specific class map-class-name DLCI configuration command can be used to assign a particular Frame Relay map class to a DLCI.

Referring to Example 16-7, End-to-End FRF.12 Fragmentation is enabled on DLCI 102 at router R1 and on DLCI 201 at router R2 with the frame-relay fragment map-class configuration command. On DLCI 103 at router R1 and on DLCI 301 at router R2, the vofr command is used to enable VoFR on a specific DLCI and to configure specific subchannels on that DLCI. The data keyword specifies the subchannel to use for data. The call-control keyword specifies the subchannel to be used for call-control signaling. When the Frame Relay Fragmentation configurations are already present on the DLCI, FRF.11 Annex C Fragmentation is immediately used after VoFR is configured on the DLCI.

Finally, on DLCI 104 at router R1 and on DLCI 401 at router R2, the vofr cisco DLCI configuration command is used to turn on the Cisco proprietary fragmentation on this specific DLCI.

The show frame-relay vofr global EXEC command can be used to display Frame Relay VoFR statistics on the router. Example 16-8 shows an output of the show frame-relay vofr command at R1.

Example 16-8. Output of show frame-relay vofr Command at R1
R1#show frame-relay vofr

interface         vofr-type   dlci   cid   cid-type
Serial2/1.104     VoFR cisco  104    4     data
Serial2/1.104     VoFR cisco  104    5     voice call-control
Serial2/1.103     VoFR        103    4     data
Serial2/1.103     VoFR        103    5     voice call-control

This command displays the information about the FRF.11 subchannels being used on VoFR DLCIs. The vofr-type field indicates the type of VoFR DLCI being observed. The cid-type represents the type of traffic carried on the corresponding subchannel.

The configured fragment size in the Frame Relay map class is 100 bytes. As such, any outgoing packets on the DLCIs with a size greater than 100 bytes are subjected to fragmentation. In the next example, extended pings to router R2 are performed at R1. This is shown in Example 16-9.

Example 16-9. Illustrating Fragmentation Occurring at R1
R1#ping
Protocol [ip]:
Target IP address: 172.16.1.2
Repeat count [5]: 10
Datagram size [100]: 500
Timeout in seconds [2]:
Extended commands [n]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 10, 500-byte ICMP Echos to 172.16.1.2, timeout is 2 seconds:
!!!!!!!!!!
Success rate is 100 percent (10/10), round-trip min/avg/max = 172/173/176 ms

R1#ping
Protocol [ip]:
Target IP address: 172.16.1.6
Repeat count [5]: 10
Datagram size [100]: 500
Timeout in seconds [2]:
Extended commands [n]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 10, 500-byte ICMP Echos to 172.16.1.6, timeout is 2 seconds:
!!!!!!!!!!
Success rate is 100 percent (10/10), round-trip min/avg/max = 172/172/172 ms

R1#ping
Protocol [ip]:
Target IP address: 172.16.1.10
Repeat count [5]: 10
Datagram size [100]: 500
Timeout in seconds [2]:
Extended commands [n]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 10, 500-byte ICMP Echos to 172.16.1.10, timeout is 2 seconds:
!!!!!!!!!!
Success rate is 100 percent (10/10), round-trip min/avg/max = 172/172/172 ms

R1#show frame-relay fragment
interface         dlci  frag-type    frag-size  in-frag    out-frag   dropped-frag
Serial2/1.102     102   end-to-end   100        68         68         0
Serial2/1.103     103   VoFR         100        68         68         0
Serial2/1.104     104   VoFR-cisco   100        68         68         0
________________________________________________________________
R2#show frame-relay fragment
interface         dlci  frag-type    frag-size  in-frag    out-frag   dropped-frag
Serial3/1.201     201   end-to-end   100        68         68         0
Serial3/1.301     301   VoFR         100        68         68         0
Serial3/1.401     401   VoFR-cisco   100        68         68         0

The show frame-relay fragment command indicates the type of fragmentation scheme enabled on each specific Frame Relay DLCI configured on the router.

A common cause of problems or poor performance related to the use of Frame Relay Fragmentation is due to users' misconfigurations. It is important to ensure that the same fragmentation scheme is used between two peers. For example, fragmentation fails if one peer is configured with FRF.12 Fragmentation while the other side is using FRF.11 Annex C Fragmentation. When configuring routers for Frame Relay Fragmentation, always use the same fragmentation scheme between them. In addition, recall that WFQ and LLQ are the only queuing strategies that can be used with fragmentation. Fragmentation will not work if other queuing schemes are employed.

It is also imperative to use a carefully chosen fragment size when configuring fragmentation. For example, poor performance can occur if the fragment size is too small and real-time voice packets are getting fragmented. FRF.12 fragments voice packets if the fragmentation size is set to a value smaller than the voice packet size. If your application supports VoFR, FRF.11 Annex C would be better because it does not fragment voice packets, regardless of the configured fragment size.


Summary

This chapter discussed the use of fragmentation on Frame Relay networks to manage latency and delay for real-time multiservice traffic, such as voice. Frame Relay Fragmentation has brought many benefits to integrated voice and data Frame Relay networks. This chapter explained serialization delay on low-speed networks and how fragmentation can be used to reduce this delay.

This chapter introduced Cisco's implementations of Frame Relay Fragmentations on Cisco routers. The three different types of Frame Relay Fragmentation schemes supported by Cisco routers include FRF.12 Fragmentation (both End-to-End and switched), Frame Relay Fragmentation with FRF.11 Annex C, and Cisco proprietary Frame Relay Fragmentation.

This chapter also covered the Cisco IOS configuration tasks for each Frame Relay Fragmentation scheme supported on Cisco routers. It explained the Cisco IOS show commands for monitoring and maintaining Frame Relay Fragmentation configurations. The most common issues and probable causes of problems arising from the use of fragmentation were mentioned. The chapter wraps up with a case study scenario. The case study illustrates a common problem encountered by a typical Frame Relay customer attempting to support voice and data traffic on the same network. Frame Relay Fragmentation can be used to effectively deal with such issues.

In Part IV, a general overview of Frame Relay queuing mechanisms is presented. The next chapter contains a detailed discussion on Frame Relay Congestion Management features.


Review Questions

1: | What is fragmentation?
2: | What is the primary purpose of fragmentation in Frame Relay?
3: | How do Frame Relay FRF.12 Fragmentation, Frame Relay Fragmentation using FRF.11 Annex C, and Cisco proprietary fragmentation compare?
4: | Describe the benefits of using Frame Relay Fragmentation with hardware compression support.
5: | What is the purpose of the sequence number field in the Frame Relay header for fragmentation?


References

  • Frame Relay Forum Implementation Agreement FRF.12: Frame Relay Fragmentation, edited by Andrew G. Malis, 1997: http://www.mplsforum.org/frame/Approved/FRF.12/frf12.pdf

  • Frame Relay Forum Implementation Agreement FRF.11: Voice over Frame Relay, edited by Ted Hatala, Ross Kocen, Kenneth Rehbehn, Tim Chui, 1999: http://www.mplsforum.org/frame/Approved/FRF.11/frf_11.1.pdf

  • Cisco IOS 12.1(2)T Release FRF.12 Support: http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121newft/121t/121t2/dtfr12ap.htm

  • Cisco IOS 12.1(2)T Release FRF.12 Support on Switched PVCs: http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121newft/121t/121t2/dtfragsw.htm

  • Cisco IOS 12.1(5)T Release Frame Relay Fragmentation with Hardware Compression: http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121newft/121t/121t5/dtfrfwhc.htm

  • Cisco IOS 12.2 Release WAN Configuration Guide: http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/fwan_c/wcffrely.htm#1070622


Case Study: Implementing Fragmentation on a Voice and Data Network

In this section, a scenario depicting a typical mixed voice and data environment demonstrates how Frame Relay Fragmentation can be used to improve the performance of the network. This case study is based on the diagram shown in Figure 16-12.

Figure 16-12. Network Diagram of Case Study Scenario

A customer of XYZ Frame Relay service provider has complained of bad voice quality after attempting to use the existing 128-kbps Frame Relay connection for VoIP services. The customer is interested in keeping the converged data and voice Frame Relay network and does not want a separate network for voice services, in order to curb phone toll charges. To save on cost, the customer does not wish to purchase additional bandwidth and wants to explore other solutions to improve performance.

After investigations by the network manager, the bad voice quality problem is determined to be primarily the result of long file transfer taking place between the ERP clients and the servers. Voice packets are getting blocked behind the large data packets, resulting in jitters in the VoIP conversation. The transmission of large data packets over the link is causing increased serialization delay for the smaller voice packets.

This example shows how Frame Relay Fragmentation using FRF.12 can be used to improve the overall performance. Example 16-10 shows the configurations of routers R1 and R2 after implementing Frame Relay Fragmentation.

Example 16-10. Configurations of Routers in Case Study Scenario
Router R1:

<output omitted>

ip routing
!
interface Ethernet2/0
 ip address 10.0.0.1 255.255.255.0
 !
interface Serial1/0
 no ip address
 encapsulation frame-relay
 frame-relay traffic-shaping
!
interface Serial1/0.102 point-to-point
 ip address 172.16.1.1 255.255.255.252
 frame-relay interface-dlci 102
   class voip
   !
map-class frame-relay voip
 frame-relay cir 128000
 no frame-relay adaptive-shaping
 frame-relay fair-queue
 frame-relay ip rtp priority 16383 16384 128
 frame-relay fragment 200
 !
dial-peer voice 1 pots
 destination-pattern 4081234
 port 0/0
!
dial-peer voice 2 voip
 destination-pattern 4085678
 session target ipv4:172.16.1.2
________________________________________________________________
Router R2:

<output omitted>

ip routing
!
interface Ethernet2/0
 ip address 192.168.1.2 255.255.255.0
 !
interface Serial1/1
 no ip address
 encapsulation frame-relay
 frame-relay traffic-shaping
!
interface Serial1/1.201 point-to-point
 ip address 172.16.1.2 255.255.255.252
 frame-relay interface-dlci 201
   class voip
   !
map-class frame-relay voip
 frame-relay cir 128000
 no frame-relay adaptive-shaping
 frame-relay fair-queue
 frame-relay ip rtp priority 16383 16384 128
 frame-relay fragment 200
!
dial-peer voice 1 pots
 destination-pattern 4085678
 port 0/0
!
dial-peer voice 2 voip
 destination-pattern 4081234
 session target ipv4:172.16.1.1

After implementing FRF.12 on the routers, XYZ's customer has noticed dramatic improvement in terms of the voice quality. Moreover, the customer is also assured that fragmentation did not result in any substantial delay or other negative effects on its ERP applications.

In addition to FRF.12, Frame Relay IP RTP priority is configured to ensure that voice traffic matching the specified UDP port ranges is reserved a bandwidth of 128 kbps. Other advanced Frame Relay QoS features, such as Compressed RTP (cRTP), IP Precedence marking, and WFQ, are also suitable for use on this network. For instance, cRTP can be used to reduce the size of voice packets traveling across the network, and IP Precedence marking can be used to prioritize the ERP traffic over users' other normal traffic.


Part IV. Cisco Frame Relay Solutions for Congestion Management

Previous Page
Next Page

Part IV: Cisco Frame Relay Solutions for Congestion Management

Chapter 17 Frame Relay Congestion Management

Chapter 18 Frame Relay Class-Based Weighted Fair Queuing (CBWFQ) and Low Latency Queuing (LLQ)

Chapter 19 Frame Relay Queuing and Fragmentation at the Interface

Chapter 20 Link Fragmentation and Interleaving (LFI) for Frame Relay Virtual Circuits


Chapter 17. Frame Relay Congestion Management

Part IV of this book focuses on the Congestion Management Quality of Service (QoS) features on Frame Relay networks. Congestion management is crucial in meeting service level agreements (SLAs) and ensuring that mission-critical traffic is prioritized and delivered with minimal delay. Congestion management involves the use of queues in the router to hold excess packets during congestion until the interface is free to transmit them. Presently, several different queuing algorithms are available. The proper use of queuing mechanisms can influence the order in which the packets waiting in the queues are serviced.

This chapter begins with an introduction to the major queuing mechanisms for Frame Relay currently supported on Cisco routers. The introduction provides an overview of the hierarchical queuing architecture on serial interfaces configured with Frame Relay encapsulation and how queuing at the interface level and permanent virtual circuit (PVC) level compares. During the course of this introduction to Frame Relay queuing, this chapter revisits some queuing mechanisms, such as priority queuing, which were introduced in earlier chapters of this book. The objective is to reinforce readers' understanding of the basic queuing mechanisms and the different types of queuing strategies supported on Frame Relay networks. Additionally, this chapter covers the use of the Frame Relay broadcast queue to manage broadcast traffic on Frame Relay networks.

After the introduction, this chapter concentrates on the Cisco Frame Relay PVC Interface Priority Queuing (PIPQ) feature. The Frame Relay PIPQ feature provides a priority queuing scheme at the interface level based on destination PVCs instead of packet contents, as in strict priority queuing. This chapter uses practical examples to demonstrate the benefits of the Frame Relay PIPQ queuing feature and to explain the configuration tasks for enabling the feature on Cisco routers. This chapter concludes by showing readers how to monitor and maintain the Frame Relay PIPQ configurations with Cisco IOS show commands on Cisco routers.

The topics and questions that this chapter addresses include the following:

  • Overview of the requirements for queuing on Frame Relay networks

  • Overview of the hierarchical queuing architecture for Cisco Frame Relay devices

  • Overview of the Frame Relay PIPQ feature

  • Configuring the Frame Relay PIPQ feature on a Cisco router

  • Monitoring and maintaining Frame Relay PIPQ configurations on a Cisco router

After completing this chapter, readers will recognize the benefits of queuing and how queuing can be used to manage traffic flows on a congested network. Readers will also become familiar with the different queuing strategies supported by the Cisco IOS software for Frame Relay. Readers will learn about the use of the Frame Relay PIPQ feature, including the configuration tasks for the feature and the relevant Cisco IOS show commands for monitoring and maintaining it on a Cisco router.


The Need for Queuing on Frame Relay Networks

Modern Frame Relay networks service a mixed variety of traffic types from users. Among the different types of traffic, mission-critical and delay-sensitive traffic are extremely susceptible to network latency. For example, delay-sensitive traffic, such as voice, is intolerant to network latency and delay largely because of the nature of the application. Network latency and delay could cause voice packets to be delayed, lost, or arrive out of order. This can severely impact the quality of the voice conversation conducted by the end users.

Most of the time, network latency and delay are the consequence of congestion on the network. When a network is not experiencing congestion, all packets are sent out an exit interface of a router as soon as they arrive at a router. However, when the network is congested, packets can arrive at a rate faster than the rate at which the outgoing interface can handle them. The router encountering congestion buffers the excess packets in queues until the congestion eases and there is available bandwidth to service the packets held up in the queues. However, if the traffic rate continues to increase, the state of congestion can become out of control. This condition inevitably causes the queues on the routers to overflow and arriving packets to be dropped from the queues.

On a Cisco Frame Relay device, two levels of queuing are involved. The congestion point can occur at the interface level or the Frame Relay PVC level. When congestion occurs, queuing is required to provide prioritization and to ensure that delay-sensitive traffic, such as voice and video packets, is not delayed or dropped. At the same time, certain queuing mechanisms ensure that traffic that is not mission critical or delay sensitive is allocated sufficient bandwidth for transmission. When queuing is set up on a congested interface, excess packets are enqueued when there is insufficient bandwidth for transmission. Subsequently, the packets are dequeued from the buffers when the network has enough bandwidth to transmit them.

A variety of different Frame Relay queuing algorithms exist to control how the packets are handled in these queues. The queuing mechanisms influence the order of transmission by determining the way the packets in the queues are serviced. For example, when priority queuing is adopted, delay-sensitive voice packets are typically given strict priority. These packets are enqueued in the highest priority queue. When the network is congested and there is limited bandwidth, the higher priority packets in the priority queue are always scheduled for transmission ahead of other traffic in lower-priority queues.

Cisco IOS software supports the following queuing mechanisms:

  • First-In-First-Out (FIFO) FIFO is the most basic form of queuing. It does not involve any classification and prioritization. As its name implies, all packets are sent out the interfaces in the order that packets arrive.

  • Priority Queuing (PQ) PQ provides strict priority by ensuring that one type of traffic (highest priority) is sent ahead of other traffic. This is usually accomplished at the expense of other lower-priority traffic. As long as high-priority traffic is present, lower-priority traffic might never get the chance to send its packets. The PQ system supports four queues: high, medium, normal, and low. PQ is discussed extensively in Chapter 5, "Frame Relay Traffic Shaping."

  • Custom Queuing (CQ) CQ provides a round-robin method of queuing by allocating the available bandwidth to all classes of traffic. Some classes of traffic might be assigned a larger proportion of the bandwidth. Nonetheless, all traffic gets a share of the total available bandwidth. In CQ, the packet-count is used to determine the size of each custom queue. Up to 16 custom queues can be created by users on Cisco routers. CQ is discussed extensively in Chapter 5.

  • Weighted Fair Queuing (WFQ) The general WFQ system uses a scheduler to ensure all traffic is treated fairly and dynamically, without users' intervention. The traffic is classified based on flows and each flow is serviced by a different queue in the system. The packets classified by WFQ as belonging to the same flow typically share the same source and destination IP address, the same source and destination port numbers, or the same transport protocol. Bandwidth is divided fairly across queues of traffic based on weights. Traffic with a lower weight is given a larger proportion of the bandwidth than higher-weight traffic. The weight factor is inversely proportional to bandwidth. Hence, WFQ effectively penalizes high-volume traffic but favors low-volume traffic. WFQ provides satisfactory performance to low-volume traffic, such as interactive telnet, that does not require large bandwidth but is sensitive to delay. However, WFQ does not work well with real-time traffic, such as voice, as it does not provide a priority queue to reduce delay and jitter. Figure 17-1 illustrates the WFQ mechanism.

    Figure 17-1. Weighted Fair Queuing

    [View full size image]

    There are four types of WFQ, as listed:

    - Flow-based WFQ Flow-based WFQ, simply known as WFQ, uses a dynamic scheduling algorithm to provide fair bandwidth allocation to all network traffic. To ensure fairness, WFQ separates the traffic into different flows, or conversations.

    The WFQ algorithm first identifies the traffic on the network based on source and destination network addresses, protocol types, and session identifiers, such as socket or port numbers. Then WFQ applies priority, or weights, to the identified traffic to classify it into conversations. The IP precedence level determines the weight carried by each classified traffic type, and the weights are inversely proportional to the IP precedence. WFQ decides from the weights how much bandwidth a conversation is allowed relative to other conversations. Hence, WFQ allows the "fair sharing" of the bandwidth among low-volume and high-volume traffic flows. For instance, WFQ allows low-volume or interactive traffic, such as Telnet sessions, to be given a high priority over high-volume, high-bandwidth traffic, such as FTP sessions. The low-volume traffic normally has fewer packets in the conversation queue compared with the high-volume traffic. Therefore, when using WFQ, the low-volume traffic is not held up for long periods.

    - Class-based WFQ (CBWFQ) CBWFQ extends the basic WFQ functionality by allowing users to define the traffic classes based on user-defined criteria and parameters, such as protocol numbers or network layer addresses. For example, extended access lists can be used to classify the traffic for CBWFQ. In CBWFQ, the weight of a class of traffic is determined by the bandwidth assigned to the class configured by the user. The bandwidth assigned to each class affects the order in which packets are sent. In the current Cisco IOS software, up to 256 classes of traffic can be defined with CBWFQ.

    - Distributed WFQ This type of WFQ is a special high-speed version of WFQ that runs on the Versatile Interface Processor (VIP). VIP is supported on c7000 series routers with RSP7000 or c7500 series routers with a VIP2-40 or greater interface processor.

    - Distributed class-based WFQ This extends CBWFQ functionality to the VIP on c7000/c7500 series routers.

  • Low Latency Queuing (LLQ or PQ/CBWFQ) LLQ combines PQ with CBWFQ. Hence, LLQ is also commonly known as PQ/CBWFQ. Because CBWFQ does not provide a strict PQ system, LLQ creates a PQ and allocates delay-sensitive traffic, such as voice, to the PQ. The other classes of traffic, such as data, are serviced by the CBWFQ, and the remaining bandwidth is divided according to the classes configured by the user. The use of LLQ ensures low latency for delay-sensitive traffic, yet provides user-configurable WFQ for the other classes of traffic. LLQ is explained in Chapter 18, "Frame Relay Class-Based Weighted Fair Queuing (CBWFQ) and Low Latency Queuing (LLQ)."

  • Frame Relay PIPQ PIPQ provides an interface-level PQ scheme in which prioritization is based on the destination PVC instead of packet contents. The mechanism for Frame Relay PIPQ is very similar to the general PQ system used at the interface level. The only obvious difference between Frame Relay PIPQ and PQ is that the former can be used only on Frame Relay interfaces. PIPQ is discussed in this chapter. In order to fully understand Frame Relay PIPQ, you need to know the differences between interface-level queuing and PVC level queuing on Frame Relay interfaces. The differences are explained and discussed in the next section.


Hierarchical Queuing Architecture for Frame Relay

When Frame Relay encapsulation is configured for serial interfaces on Cisco routers, two levels of queuing can exist for the serial interfaces. By default, when the Frame Relay interface is congested, the interface-level queue is used to store the excess packets at the interface level until the interface becomes free to send them. In addition, a second level of queuing at the Frame Relay PVC level is possible with Frame Relay Traffic Shaping.

NOTE

WFQ is the default queuing mechanism at the interface level for serial interfaces with speed of E1 (2.048 Mbps) or lower on all Cisco router platforms. FIFO is the default for interfaces with speeds greater than E1.

PVC-Level Queues Versus Interface-Level Queues

Configuring the Frame Relay Traffic Shaping feature at the Frame Relay main interface enables PVC-level queuing. FIFO queuing, with a queue limit of 40 packets, is the default PVC-level queuing mechanism. The default queue limit of 40 packets can be changed with the frame-relay holdq size map-class configuration command. Each Frame Relay virtual circuit (VC) under the main interface can be configured to support different PVC-level queuing mechanisms, such as PQ, CQ, WFQ, or LLQ. Together with the interface-level queue, this creates a two-level hierarchical queuing architecture.

Figure 17-2 clearly demonstrates the two-level queuing architecture. Enabling Frame Relay Traffic Shaping creates a two-level queuing structure. In this example, CQ is configured on DLCI 100 at the PVC level in place of the default FIFO queuing. At the interface level, Frame Relay Traffic Shaping dictates that FIFO queuing must be used. After CQ is configured, the interface supports PVC-level CQ in addition to the interface-level FIFO queue.

Figure 17-2. Two-Level Hierarchical Queuing

As illustrated in the figure, Frame Relay frames are first enqueued in the CQ at the PVC level based on user-defined criteria and classification. Example 17-1 shows a typical configuration example of CQ configured on the router in Figure 17-2.

Example 17-1. Configuration Example of CQ Configured on Router in Figure 17-2
interface Serial2/1
 encapsulation frame-relay
 no fair
 frame-relay traffic-shaping
!
interface Serial2/1.100 point-to-point
 ip address 172.16.1.1 255.255.255.0
 frame-relay interface-dlci 100
class CQ
!
map-class frame-relay CQ
 no frame-relay adaptive-shaping
 frame-relay custom-queue-list 1
queue-list 1 protocol ip 1
queue-list 1 protocol ip 2 tcp www
queue-list 1 protocol ip 3 tcp telnet
queue-list 1 protocol ip 4 tcp ftp
queue-list 1 protocol ip 5 tcp smtp
queue-list 1 default 6

CQ serves the queue in a round-robin fashion. When each CQ is serviced, the Frame Relay frames enqueued in the PVC-level custom queues are dequeued and sent to the interface-level FIFO queue. The queuing mechanism selected at the PVC level determines the order in which packets are dequeued from the PVC-level queues and sent into the interface-level queue.

Take note that when Frame Relay Traffic Shaping is enabled at the physical interface level and a PVC-level queuing system, such as PQ, is enabled, the packets are dequeued from the PVC-level queues at the configured Frame Relay shaping rate into the interface level queue for transmission.

To view the type of queuing mechanism currently used at the interface level, use the show interface global EXEC command. An example of the show interface output is shown in Example 17-2.

Example 17-2. Output of show interface Command, Specifying That FIFO Queuing Is Used at the Interface Level
Router#show interface serial2/0
Serial2/0 is up, line protocol is up
  Hardware is M4T
  MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec,
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation FRAME-RELAY, crc 16, loopback not set
  Keepalive set (10 sec)
  Restart-Delay is 0 secs
  LMI enq sent  3, LMI stat recvd 5, LMI upd recvd 0, DTE LMI up
  LMI enq recvd 0, LMI stat sent  0, LMI upd sent  0
  LMI DLCI 1023  LMI type is CISCO  frame relay DTE
  FR SVC disabled, LAPF state down
  Broadcast queue 0/64, broadcasts sent/dropped 0/0, interface broadcasts 0
  Last input 00:00:08, output 00:00:08, output hang never
  Last clearing of "show interface" counters 00:00:41
  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
  Queueing strategy: fifo
  Output queue: 0/40 (size/max)
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
     5 packets input, 65 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
     9 packets output, 119 bytes, 0 underruns
     0 output errors, 0 collisions, 3 interface resets
     0 output buffer failures, 0 output buffers swapped out
3 carrier transitions     DCD=up  DSR=up  DTR=up  RTS=up  CTS=up

To view the type of queuing mechanism currently used at the Frame Relay PVC level, use the show frame-relay pvc dlci global EXEC command. The output of the command also shows summary information related to the queuing mechanism deployed on the PVC. An example of the show frame-relay pvc dlci command is illustrated in Example 17-3.

Example 17-3. Output of show frame-relay pvc Command, Specifying That WFQ Is Used at the PVC Level
Router#show frame-relay pvc 100

PVC Statistics for interface Serial2/0 (Frame Relay DTE)

DLCI = 100, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial2/0.100

  input pkts 0             output pkts 0            in bytes 0
  out bytes 0              dropped pkts 0           in pkts dropped 0
  out pkts dropped 0                out bytes dropped 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
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
  pvc create time 00:00:05, last time pvc status changed 00:00:05
  cir 56000     bc 7000      be 0         byte limit 875    interval 125
  mincir 28000     byte increment 875   Adaptive Shaping none
  pkts 0         bytes 0         pkts delayed 0         bytes delayed 0
  shaping inactive
  traffic shaping drops 0
  Queueing strategy: weighted fair
  Current fair queue configuration:
   Discard     Dynamic      Reserved
   threshold   queue count  queue count
    64          16           0
Output queue size 0/max total 600/drops 0

Dual-FIFO Queue

On the nondistributed c2600, c3600, and c7200 series routers, a special Dual-FIFO queue is created at the interface level when Frame Relay Traffic Shaping and Frame Relay FRF.12 End-to-End Fragmentation is enabled. As a result, two levels of queuing are created on the Frame Relay interface. Frame Relay Traffic Shaping supports the first level of PVC queuing to prevent a VC from consuming all available bandwidth at the interface and starving the remaining VCs. PVC-level queuing, such as PQ, CQ, or WFQ, can be configured at this level. At the interface level, FIFO is the queuing method used when Frame Relay Traffic Shaping is enabled. Enabling Frame Relay FRF.12 Fragmentation changes the FIFO queue to a Dual-FIFO queue, whereby one queue is of high priority and the other queue is of low priority. The high-priority queue handles traffic, such as voice packets, and control packets, such as LMI exchanges. The low-priority queue is usually used to service fragmented packets, such as data.

Ideally, the delay-sensitive voice packets are unfragmented and enqueued to the high-priority FIFO queue at the interface level. The larger data packets are fragmented by FRF.12 and are assigned to the low-priority FIFO queue. To ensure that the voice packets get into the high-priority queue unfragmented, the fragmentation size configured must be larger than the average voice packet size. At the interface, the packets in both FIFO queues, consisting of small voice packets and fragmented data packets, are interleaved and transmitted. Figure 17-3 shows the Dual-FIFO queuing created at the interface when Frame Relay Traffic Shaping and Frame Relay FRF.12 Fragmentation are configured. Frame Relay Fragmentation with FRF.12 is explained in Chapter 16, "Frame Relay Fragmentation."

Figure 17-3. Dual-FIFO Queue Used with Frame Relay FRF.12

[View full size image]

NOTE

The Dual-FIFO queue structure applies only to nondistributed platforms such as the c2600, c3600, and c7200 series routers. Also take note that the Dual-FIFO queue system is created at the interface level when Real-Time Transport Protocol (RTP) prioritization and FRF.12 Fragmentation are enabled.

Example 17-4 shows the typical configurations for Frame Relay Traffic Shaping and Frame Relay FRF.12 Fragmentation configured on a Cisco router.

Example 17-4. Configuration Example of FRTS and FRF.12 on a Cisco Router
interface Serial2/1
 encapsulation frame-relay
 no fair
 frame-relay traffic-shaping
!
interface Serial2/1.100 point-to-point
 ip address 172.16.1.1 255.255.255.0
 frame-relay interface-dlci 100
  class Fragmentation
  !
map-class frame-relay Fragmentation
  frame-relay fair-queue
  frame-relay fragment 100

Example 17-5 shows the output of the show interface command after the configurations are applied.

Example 17-5. Output of show interface Command, Specifying That Dual-FIFO Queuing Is Used
Router#show interface serial2/0
Serial2/0 is up, line protocol is up
  Hardware is M4T
  MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec,
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation FRAME-RELAY, crc 16, loopback not set
  Keepalive set (10 sec)
  Restart-Delay is 0 secs
  LMI enq sent  14, LMI stat recvd 16, LMI upd recvd 0, DTE LMI up
  LMI enq recvd 0, LMI stat sent  0, LMI upd sent  0
  LMI DLCI 1023  LMI type is CISCO  frame relay DTE
  FR SVC disabled, LAPF state down
  Broadcast queue 0/64, broadcasts sent/dropped 1/0, interface broadcasts 0
  Last input 00:00:03, output 00:00:03, output hang never
  Last clearing of "show interface" counters 00:02:26
  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
  Queueing strategy: dual fifo
  Output queue: high size/max/dropped 0/256/0
  Output queue: 0/128 (size/max)
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
     16 packets input, 208 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
     21 packets output, 656 bytes, 0 underruns
     0 output errors, 0 collisions, 4 interface resets
     0 output buffer failures, 0 output buffers swapped out
     4 carrier transitions     DCD=up  DSR=up  DTR=up  RTS=up  CTS=up

Recall that the Frame Relay IP RTP Priority feature, which is introduced in Chapter 16, is used to ensure that voice traffic matching the specified UDP port ranges is reserved the required bandwidth. When Frame Relay IP RTP Priority is used together with Frame Relay FRF.12 (provided that the configured fragmentation size is greater than the voice packet size), voice packets matching on the RTP UDP port range are enqueued into the high-priority Dual-FIFO queue at the interface level. Other types of traffic are enqueued into the low-priority Dual-FIFO queue at the interface level.

Frame Relay Broadcast Queue

This section introduces and explains the use of the Frame Relay Broadcast queue enhancement on Cisco routers. The Frame Relay Broadcast queue is a Cisco enhancement to resolve performance issues likely to be encountered in large-scale Frame Relay networks. An overview of the Frame Relay Broadcast Queue is provided earlier in Chapter 5, "Frame Relay Traffic Shaping."

In large Frame Relay networks, a sizable number of Frame Relay PVCs are fairly commonly terminated at a single router. This is usually the case at the central or hub site. However, this introduces a possible performance issue when customers run dynamic routing protocols over such a Frame Relay network. If the central site runs a dynamic routing protocol with every remote site connected, the central router needs to broadcast locally generated route updates to all remote sites or to replicate route updates it received from the remote sites and to transmit the route updates on each DLCI under its main interface.

When using a distance vector routing protocol, such as RIP, it is certainly assumed that split horizon is disabled at the main interface. Inevitably, this broadcast behavior can consume a considerable amount of access link bandwidth, resulting in delay and jitter for real-time traffic.

Moreover, the routing broadcast updates occupy interface buffer spaces. During network congestion, overflowing buffers can lead to a higher packet loss rate for data and routing update traffic.

The Frame Relay Broadcast queue enhancement alleviates this issue by identifying broadcast traffic, such as routing or Service Advertising Packets (SAP) updates, and storing the excess traffic in a special broadcast queue at the interface. The broadcast queue is useful when a Frame Relay interface needs to send duplicates of a broadcast packet out on all active DLCIs. The broadcast packet sent on an interface or subinterface is duplicated for each broadcast-capable DLCI, and all copies of the broadcast packet are sent to the broadcast queue.

The broadcast queue is managed independently of the normal interface queue. It is assigned a maximum throughput based on packet counts and byte counts per second. Only the maximum throughput provided is allowed for the packets in the broadcast queue. This effectively ensures a guaranteed minimum bandwidth allocation for packets in the broadcast queue. Because the broadcast queue is user configurable, the broadcast queue can be customized to avoid overconsumption of the access bandwidth by broadcast packets but still prevent losing routing updates by allocating additional buffering.

The Frame Relay Broadcast queue can be configured via the following interface configuration command:

frame-relay broadcast-queue size byte-rate packet-rate

On a serial interface, the default size is 64 packets, and the default byte rate is 256000 bytes per second. The default for packet-rate is 36 packets per second (pps). Other higher-speed interfaces, such as High Speed Serial Interface (HSSI), have higher default values. Changes to the default queue size for the frame-relay broadcast-queue command and the number of broadcasts sent or dropped can be verified with the show interface command, as shown in Example 17-6.

Example 17-6. Output of show interface Command, Specifying the Broadcast Queue Size and Related Parameters
Router#show interface serial2/0
Serial2/0 is up, line protocol is up
  Hardware is M4T
  MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec,
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation FRAME-RELAY, crc 16, loopback not set
  Keepalive set (10 sec)
  Restart-Delay is 0 secs
  LMI enq sent  14, LMI stat recvd 16, LMI upd recvd 0, DTE LMI up
  LMI enq recvd 0, LMI stat sent  0, LMI upd sent  0
  LMI DLCI 1023  LMI type is CISCO  frame relay DTE
  FR SVC disabled, LAPF state down
  Broadcast queue 0/64, broadcasts sent/dropped 1/0, interface broadcasts 0
  Last input 00:00:03, output 00:00:03, output hang never
  Last clearing of "show interface" counters 00:02:26
  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
  Queueing strategy: dual fifo
  Output queue: high size/max/dropped 0/256/0
  Output queue: 0/128 (size/max)
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
     16 packets input, 208 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
     21 packets output, 656 bytes, 0 underruns
     0 output errors, 0 collisions, 4 interface resets
     0 output buffer failures, 0 output buffers swapped out
     4 carrier transitions     DCD=up  DSR=up  DTR=up  RTS=up  CTS=up


Frame Relay PIPQ

The remaining sections of this chapter focus on the Frame Relay PIPQ feature. The Frame Relay PIPQ feature works by providing a PQ scheme at the interface level. Similar to the generic PQ feature enabled at the interface level for nonserial interfaces or other encapsulation types, the Frame Relay PIPQ feature provides four queues of ascending levels of priority: low, normal, medium, and high.

NOTE

The Frame Relay PIPQ feature is supported in Cisco IOS Release 12.1(1)T and later.

PQ Versus Frame Relay PIPQ

The major difference between generic PQ and Frame Relay PIPQ is in the way the packets are classified and sent into the respective priority queues. In the generic PQ case, packet classification and prioritization are based on packet contents, such as protocol types, packet size, TCP or UDP port numbers, and the use of access lists. In the Frame Relay PIPQ case, prioritization is based solely on the destination PVC, rather than the packet contents.

With Frame Relay PIPQ, the user can designate that the Frame Relay PVC carrying high-priority traffic has absolute priority over the other Frame Relay PVCs transporting noncritical data. When a Frame Relay packet arrives at the interface level, the packet is examined for its DLCI value. After knowing which DLCI the packet belongs to, the packet is then sent to the corresponding priority queue at the interface level, based on the priority level that is mapped to that DLCI by Frame Relay PIPQ.

Because Frame Relay PIPQ determines a Frame Relay packet's priority level based on its DLCI value rather than examining the packet contents, it is extremely important for the network administrator to configure the network so that separate types of traffic are transported on separate Frame Relay PVCs. Frame Relay PIPQ does not work if there is a Frame Relay PVC carrying varying types of traffic with different QoS requirements. Frame Relay PIPQ is most advantageous if there are different PVCs for carrying different types of traffic, and the network administrator needs to ensure that delay-sensitive traffic on a Frame Relay PVC has absolute priority over the remaining classes of traffic on other PVCs. Figure 17-4 depicts the way Frame Relay PIPQ works.

Figure 17-4. Frame Relay PIPQ

As illustrated in Figure 17-4, Frame Relay PIPQ sorts traffic arriving from the Frame Relay PVCs into four interface-level priority queues, based on the packets' derived DLCI values. The figure also serves as an example of how the Frame Relay PIPQ feature is commonly used.

Before enabling the Frame Relay PIPQ feature on your network, you should ensure that your Frame Relay PVCs are configured to carry only a single type of traffic. As shown in the figure, it is imperative for users to protect delay-sensitive and network-control traffic, such as voice packets and routing updates, by transporting them on a separate Frame Relay PVC (DLCI 100) mapped to the high-priority queue.

Traffic such as voice call signaling can be transported on a dedicated Frame Relay PVC separate from the high-priority traffic. In the example shown in Figure 17-4, the voice call signaling and setup traffic carried on DLCI 200 are mapped to the medium-priority queue. It is a common practice to assign data traffic that is not mission-critical, such as users' FTP file transfers, to the low priority queue. The network manager must ensure that separate PVCs are used to service the users. All other traffic that is not classified can be transported on single designated PVC mapped to the normal priority queue.

NOTE

In principle, the Frame Relay PIPQ feature works almost exactly the same way as the PQ mechanism. As in PQ, the high-priority queue is always serviced first. As long as the high-priority queue is not empty, it is possible that the lower-priority queues can be starved of their required bandwidth to transmit. Therefore, network administrators should ensure that the network is configured with adequate call admission control.

Restrictions of Frame Relay PIPQ

This section looks at the restrictions imposed on the use of the Frame Relay PIPQ feature on supported Cisco platforms. The Frame Relay PIPQ feature is supported on all major Cisco router platforms, including the c7500 series routers in nondistributed mode.

The following list summarizes the restrictions applied to the Frame Relay PIPQ feature:

  • Frame Relay PIPQ cannot be used on interfaces that do not support PQ. Examples are loopbacks or tunnel logical interfaces.

  • Frame Relay PIPQ cannot be used on interfaces that are already configured with queuing other than FIFO queuing or WFQ (if it is not the default interface queuing method).


Configuring Frame Relay PIPQ

This section looks at the configuration tasks for enabling the Frame Relay PIPQ feature on Cisco routers. Take note that Frame Relay Traffic Shaping or FRF.12 is not required for Frame Relay PIPQ to work. Frame Relay PIPQ can work with or without these features. However, recall that when Frame Relay Traffic Shaping is enabled on a Frame Relay interface, the two-level queuing hierarchy is created on the interface. With Frame Relay Traffic Shaping and the two-level queuing structure, the interface-level queue is a FIFO queue, whereas the PVC-level queue can support other queuing methods, such as WFQ. Enabling Frame Relay Traffic Shaping with FRF.12 converts the interface-level FIFO queue to a Dual-FIFO queue, whereby unfragmented voice packets go into the high-priority FIFO queue, and fragmented data packets are queued in the low-priority FIFO queue.

With Frame Relay PIPQ, the four-queue interface-level PQ system replaces the FIFO queue or the Dual-FIFO queue created at the interface when Frame Relay Traffic Shaping and Frame Relay FRF.12 Fragmentation are enabled concurrently. In the Dual-FIFO queue system, depending on whether packets carried on the PVC are fragmented, FRF.12 prioritizes and separates the unfragmented voice packets and fragmented data packets into the high-priority and the low-priority interface queues, respectively. When assigning priority, in contrast with FRF.12, Frame Relay PIPQ does not take into consideration whether packets are fragmented or not. When FRF.12 is configured together with Frame Relay PIPQ, both voice packets and fragmented data packets carried by the same Frame Relay PVC go into an interface-level priority queue preassigned to that PVC by Frame Relay PIPQ. Although the Frame Relay PIPQ feature is independent of Frame Relay FRF.12 Fragmentation, it is always useful to enable FRF.12 on the Frame Relay PVC carrying voice traffic to prevent an unexpected large packet from causing latency or jitters for the mainstream voice packets.

Table 17-1 summarizes the various interface-level queuing mechanisms that result from enabling certain Frame Relay features.

Table 17-1. Interface Queuing Strategy for Frame Relay

Frame Relay Features

Interface Queuing Strategy

Frame Relay encapsulation without any features

If the interface speed is lower than E1, default is WFQ queuing. If the interface speed is greater than E1, default is FIFO queuing.

Frame Relay Traffic Shaping

FIFO queuing.

Frame Relay FRF.12 with FRTS

Dual-FIFO queuing.

Frame Relay PIPQ (with or without FRTS or FRF.12)

Interface PQ.

To configure the Frame Relay PIPQ feature on a Cisco router, perform the following configuration steps, beginning from the global configuration mode:

Step 1. | In the global configuration mode, first set up the PVC priority within a Frame Relay map class. Specify the map-class name with the map-class frame-relay map-class-name command. This enters you into the map-class configuration mode.
Step 2. | In the map-class configuration mode, assign a PVC priority level to a Frame Relay map class with the frame-relay interface-queue priority {high | medium | normal | low} map-class configuration command. When the map class is subsequently assigned to a Frame Relay DLCI, the configured priority level in the map class determines the PVC priority level for the traffic transported on that DLCI.
Step 3. | Enable Frame Relay PIPQ at the interface level with the frame-relay interface-queue priority [high-limit medium-limit normal-limit low-limit] interface configuration command. The queue limit of the four priority queues can be adjusted with this command. Otherwise, the default queue limits for the high, medium, normal, and low queues are 20, 40, 60, and 80, respectively. If frame-relay interface-queue priority is not enabled at the interface level, configuring PVC priority within a map class is not effective.
Step 4. | The final step is to assign the configured Frame Relay map class to the individual Frame Relay PVC. The class map-class-name configuration command can be used to assign a Frame Relay map class directly to an individual Frame Relay PVC. Additionally, the frame-relay class map-class-name interface configuration command can be used to assign a Frame Relay map class to all Frame Relay PVCs created on a main interface or subinterface.

Figure 17-5 depicts the network diagram used to verify Frame Relay PIPQ. Example 17-7 shows the configuration commands of the routers in the diagram.

Example 17-7. Configuration Commands of the Routers Used for Demonstrating Frame Relay PIPQ in Figure 17-5
! Router R1:

<output omitted>

interface FastEthernet0/0
 ip address 10.0.0.3 255.255.255.0
 ip policy route-map WEB_TRAFFIC
 !
interface Serial4/0
 no ip address
 encapsulation frame-relay
 frame-relay interface-queue priority
!
interface Serial4/0.102 point-to-point
 ip address 172.16.1.1 255.255.255.252
 frame-relay interface-dlci 102
  class HIGH
!
interface Serial4/0.103 point-to-point
 ip address 172.16.2.1 255.255.255.252
 frame-relay interface-dlci 103
  class MEDIUM
!
interface Serial4/0.104 point-to-point
 ip address 172.16.1.5 255.255.255.252
 frame-relay interface-dlci 104
  class LOW
!
interface Serial4/0.105 point-to-point
 ip address 172.16.2.5 255.255.255.252
 frame-relay interface-dlci 105
class NORMAL
!
router ospf 1
 area 1 stub
 passive-interface FastEthernet0/0
 network 10.0.0.0 0.0.0.255 area 1
 network 172.16.1.4 0.0.0.3 area 0
 network 172.16.2.0 0.0.0.3 area 0
 network 172.16.2.4 0.0.0.3 area 0
 !
map-class frame-relay MEDIUM
 no frame-relay adaptive-shaping
 frame-relay interface-queue priority medium
!
map-class frame-relay NORMAL
 no frame-relay adaptive-shaping
!
map-class frame-relay LOW
 no frame-relay adaptive-shaping
 frame-relay interface-queue priority low
!
map-class frame-relay HIGH
 no frame-relay adaptive-shaping
 frame-relay interface-queue priority high
!
access-list 101 permit tcp any any eq www
!
route-map WEB_TRAFFIC permit 10
 match ip address 101
 set ip next-hop 172.16.2.2
!
route-map WEB_TRAFFIC permit 20
!
!
!
dial-peer voice 1 pots
 destination-pattern 4001
 port1/0
!
dial-peer voice 2 voip
 destination-pattern 4002
 session target ipv4:172.16.1.2
________________________________________________________________
! Router R2:

<output omitted>

interface FastEthernet0/1
 ip address 192.168.1.1 255.255.255.0
 !
interface Serial2/1
 no ip address
 encapsulation frame-relay
 !
interface Serial2/1.201 point-to-point
 ip address 172.16.1.2 255.255.255.252
 frame-relay interface-dlci 201
!
interface Serial2/1.401 point-to-point
 ip address 172.16.1.6 255.255.255.252
 frame-relay interface-dlci 401
 !
router ospf 1
 network 172.16.1.4 0.0.0.3 area 0
 network 192.168.1.0 0.0.0.255 area 0
 !
dial-peer voice 1 pots
 destination-pattern 4002
 port 1/0
 !
dial-peer voice 2 voip
 destination-pattern 4001
 session target ipv4:172.16.1.1
________________________________________________________________
! Router R3:

<output omitted>

interface FastEthernet0/0/0
 ip address 172.16.3.1 255.255.255.0
 !
interface Serial3/0/1
 no ip address
 encapsulation frame-relay
!
interface Serial3/0/1.301 point-to-point
 ip address 172.16.2.2 255.255.255.252
 frame-relay interface-dlci 301
!
interface Serial3/0/1.501 point-to-point
 ip address 172.16.2.6 255.255.255.252
 frame-relay interface-dlci 501
 !
router ospf 1
 network 172.16.2.0 0.0.0.3 area 0
 network 172.16.2.4 0.0.0.3 area 0
 network 172.16.3.0 0.0.0.255 area 2

Figure 17-5. Verifying the Frame Relay PIPQ Feature

[View full size image]

The configuration examples for Figure 17-5 portray a simple remote-central office setup connected over a hub-and-spoke Frame Relay network. The company needs to transport several different classes of user traffic with varying QoS requirements over the Frame Relay network with limited available bandwidth. The company has decided to use Frame Relay PIPQ at the central site router to prioritize the different classes of traffic sent into the Frame Relay network.

To fully utilize the benefits of Frame Relay PIPQ, you must separate the different types of traffic onto separate Frame Relay PVCs. In this example, four Frame Relay PVCs are provisioned between the central site, and its remote office sites to carry the different classes of traffic. The central site plans to make Voice over IP (VoIP) calls with one of its connected remote sites. A dedicated Frame Relay PVC is provisioned to transport the delay-sensitive VoIP traffic on DLCI 102. To minimize network latency for the VoIP traffic, traffic carried on DLCI 102 is given preferential treatment over other classes of traffic. Therefore, Frame Relay PIPQ is configured at the interface level. All traffic carried on DLCI 102 is sent into the high-priority interface queue at central router R1.

A small team of account managers at a branch site uploads sales proposals to a group of servers on a network connected to router R2. The manager at the central site needs to download this data for analysis. For this purpose, a low-bandwidth Frame Relay PVC is provisioned between routers R1 and R2 to facilitate this file transfer process between the central and remote sites. On the central router R1 and the remote router R2, OSPF is configured on the 172.16.1.4/30 subnet to provide connectivity between the central and remote sites. This helps to isolate routing updates from Frame Relay DLCI 102 and DLCI 201 serving the VoIP users. Furthermore, because the file transfer between routers R1 and R2 over 172.16.1.4/30 subnet are not considered mission-critical and the file transfer can be scheduled or performed manually during off-peak hours, traffic carried on DLCI 104 at the central router is sent into the low-priority interface queue.

Intranet Web traffic between clients connected to router R1 and the Web server attached to router R3 is given the next highest priority. All traffic carried on DLCI 103 is assigned to the medium-priority interface queue at router R1. Additionally, a route map is configured on router R1 to enable policy routing so that all incoming Web traffic from its clients is directed to router R3 over DLCI 103. All other traffic between routers R1 and R3 are routed with OSPF. Finally, at central router R1, the remaining traffic classes between routers R1 and R3 transported on DLCI 105 are assigned to the normal-priority interface queue.

It is important to understand that the scenario presented in this section serves only as an example to reflect the different classes of traffic likely to be seen on an actual production Frame Relay network. Each class of traffic can be transported on individual Frame Relay PVCs, and Frame Relay PIPQ can then be used to effectively provide traffic prioritization between the DLCIs.

NOTE

Notice in Example 17-7 that the configurations do not show the frame-relay interface-queue priority normal command for the normal priority queue under the Frame Relay map class. The default behavior for Frame Relay PIPQ in a map class is to assign packets to the normal queue. Hence, if you enable Frame Relay PIPQ at the interface but do not differentiate the classes of traffic in Frame Relay map classes, all traffic goes into the normal priority queue. This has the same exact behavior as FIFO queuing at the interface level. The configurations in Example 17-7 are verified in the next section. The commands for monitoring and troubleshooting Frame Relay PIPQ on a Cisco router are also introduced in the next section.


Monitoring and Troubleshooting Frame Relay PIPQ

This section continues with the configuration examples in Figure 17-5. You can observe how Frame Relay PIPQ works when actual traffic is sent. The show frame-relay pvc dlci global EXEC command can be used to display statistics about Frame Relay PIPQ configured on the PVC. An example of the output of the command is shown in Example 17-8.

Example 17-8. Output of show frame-relay pvc dlci at R1
R1#show frame-relay pvc 102

PVC Statistics for interface Serial4/0 (Frame Relay DTE)

DLCI = 102, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial4/0.102

  input pkts 188           output pkts 187          in bytes 60826
  out bytes 60836          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 182       out bcast bytes 60316
  pvc create time 03:03:40, last time pvc status changed 02:59:20
priority high

R1#show frame-relay pvc 103

PVC Statistics for interface Serial4/0 (Frame Relay DTE)

DLCI = 103, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial4/0.103
  input pkts 1225          output pkts 1453         in bytes 167719
  out bytes 187696         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 1072      out bcast bytes 171368
  pvc create time 03:04:18, last time pvc status changed 03:00:28
priority medium

R1#show frame-relay pvc 104

PVC Statistics for interface Serial4/0 (Frame Relay DTE)

DLCI = 104, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial4/0.104

  input pkts 1768          output pkts 6517         in bytes 519930
  out bytes 5359763        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 1239      out bcast bytes 137939
  pvc create time 03:04:53, last time pvc status changed 03:00:23
priority low

R1#show frame-relay pvc 105

PVC Statistics for interface Serial4/0 (Frame Relay DTE)

DLCI = 105, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial4/0.105

  input pkts 898           output pkts 1090         in bytes 117581
  out bytes 173982         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 1077      out bcast bytes 172650
pvc create time 03:05:23, last time pvc status changed 03:01:33

The show interface command can also be used to verify the queuing method currently used at the interface level. An example of the output is shown in Example 17-9.

Example 17-9. Output of show interface Command at R1, Specifying That DLCI PQ Is Used
R1#show interface serial4/0
Serial4/0 is up, line protocol is up
  Hardware is M4T
  MTU 1500 bytes, BW 2048 Kbit, DLY 20000 usec,
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation FRAME-RELAY, crc 16, loopback not set
  Keepalive set (10 sec)
  LMI enq sent  1125, LMI stat recvd 1125, LMI upd recvd 0, DTE LMI up
  LMI enq recvd 0, LMI stat sent  0, LMI upd sent  0
  LMI DLCI 1023  LMI type is CISCO  frame relay DTE
  FR SVC disabled, LAPF state down
  Broadcast queue 0/64, broadcasts sent/dropped 3635/0, interface broadcasts 2527
  Last input 00:00:00, output 00:00:02, output hang never
  Last clearing of "show interface" counters 03:07:38
  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 3573
  Queueing strategy: DLCI priority
  Output queue (queue priority: size/max/drops):
     high: 0/20/0, medium: 0/40/0, normal: 0/60/0, low: 0/80/0
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
     5263 packets input, 894258 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
     6865 packets output, 2262972 bytes, 0 underruns
     0 output errors, 0 collisions, 3 interface resets
     0 output buffer failures, 0 output buffers swapped out
     3 carrier transitions     DCD=up  DSR=up  DTR=up  RTS=up  CTS=up

The show interface command output also reveals statistics regarding the current configured queue limit of the priority queues and the number of packets dropped from each queue.

Finally, the show queuing [custom | fair | priority | random-detect [interface]] global EXEC command can be used to list all the configured queuing strategies on the router.

An example of the output is shown in Example 17-10.

Example 17-10. Output of show queuing Command at R1
R1#show queueing
Current fair queue configuration:

  Interface           Discard     Dynamic      Reserved
                      threshold   queue count  queue count
  Serial2/0           64          256          0
  Serial2/1           64          256          0
  Serial2/2           64          256          0
  Serial2/3           64          256          0
  Serial4/1           64          256          0
  Serial4/2           64          256          0
  Serial4/3           64          256          0

Current DLCI priority queue configuration:

  Interface           High    Medium  Normal  Low
                      limit   limit   limit   limit
  Serial4/0           20      40      60      80

Current priority queue configuration:
Current custom queue configuration:
Current random-detect configuration:

As shown in Example 17-10, interface Serial4/0 on R1 is configured to use Frame Relay PIPQ. The output of the command shows the queue limits configured for Frame Relay PIPQ on Serial4/0. In addition, the command displays information related to WFQ, PQ, CQ, or random-detect (Random Early Detection). Congestion avoidance techniques for Frame Relay involving Random Early Detection (RED) and Weighted Random Early Detection will be covered in Chapter 21. The rest of the unused serial interfaces on R1 are configured with the default WFQ because they are of slower speeds than E1.

The debug priority command is a useful tool for debugging the Frame Relay PIPQ feature on a Cisco router. Information on PIPQ is displayed for process-switched traffic or when there is congestion.

In general, all debug commands should be used with extreme caution because debugging processes are CPU intensive and can seriously impact the performance of the router and your network. Take note that the same debug priority command can be used to display debugging information for generic PQ.

In Example 17-11, the debug priority command is enabled on router R1 and a large volume of data is sent across the Frame Relay network from router R1 on DLCI 103 (medium priority interface queue). The objective is to verify that when there is no contesting traffic from other DLCIs with higher interface queue priorities, traffic from the lower-priority interface queues is serviced. Subsequently, this example includes sending traffic onto the higher-priority DLCIs and placing a VoIP call from router R1 to router R2. The aim is to verify that when traffic from the Frame Relay DLCIs enters its respective assigned interface priority queues, packets in the interface priority queues are serviced according to their priority levels.

Example 17-11. Verifying Frame Relay PIPQ with the debug priority Command. A large volume of traffic is generated on DLCI 103 at router R1 destined for router R2.
! R1#debug priority
02:07:47: PQ: Serial3/0 dlci 104 -> low
02:07:47: PQ: Serial3/0 output (Pk size/Q 1002/3)
02:07:47: PQ: Serial3/0 dlci 104 -> low
02:07:47: PQ: Serial3/0 dlci 103 -> medium
02:07:47: PQ: Serial3/0 output (Pk size/Q 1002/1)
02:07:47: PQ: Serial3/0 dlci 104 -> low
02:07:47: PQ: Serial3/0 dlci 104 -> low
02:07:47: PQ: Serial3/0 output (Pk size/Q 1002/3)
02:07:47: PQ: Serial3/0 dlci 103 -> medium
02:07:47: PQ: Serial3/0 dlci 104 -> low
02:07:47: PQ: Serial3/0 output (Pk size/Q 1002/1)
02:07:47: PQ: Serial3/0 dlci 104 -> low
02:07:47: PQ: Serial3/0 dlci 103 -> medium
02:07:47: PQ: Serial3/0 output (Pk size/Q 1002/1)
02:07:47: PQ: Serial3/0 dlci 104 -> low
02:07:47: PQ: Serial3/0 dlci 104 -> low
02:07:47: PQ: Serial3/0 output (Pk size/Q 1002/3)
02:07:47: PQ: Serial3/0 dlci 103 -> medium
02:07:47: PQ: Serial3/0 dlci 104 -> low
02:07:47: PQ: Serial3/0 output (Pk size/Q 1002/1)
02:07:47: PQ: Serial3/0 dlci 104 -> low
02:07:47: PQ: Serial3/0 dlci 103 -> medium
02:07:47: PQ: Serial3/0 output (Pk size/Q 1002/1)
02:07:47: PQ: Serial3/0 dlci 104 -> low
02:07:48: PQ: Serial3/0 dlci 104 -> low
02:07:48: PQ: Serial3/0 output (Pk size/Q 1002/3)
02:07:48: PQ: Serial3/0 dlci 103 -> medium
02:07:48: PQ: Serial3/0 dlci 104 -> low
02:07:48: PQ: Serial3/0 output (Pk size/Q 1002/1)
02:07:48: PQ: Serial3/0 dlci 104 -> low
02:07:48: PQ: Serial3/0 dlci 103 -> medium
02:07:48: PQ: Serial3/0 output (Pk size/Q 1002/1)
02:07:48: PQ: Serial3/0 dlci 104 -> low
02:07:48: PQ: Serial3/0 output (Pk size/Q 1002/3)
02:07:48: PQ: Serial3/0 dlci 104 -> low
02:07:48: PQ: Serial3/0 dlci 103 -> medium
02:07:48: PQ: Serial3/0 dlci 104 -> low
02:07:48: PQ: Serial3/0 output (Pk size/Q 1002/1)
02:07:48: PQ: Serial3/0 dlci 104 -> low
02:07:48: PQ: Serial3/0 dlci 103 -> medium

!After placing VOIP calls from R1 to R2:
02:21:00: PQ: Serial3/0 dlci 102 -> high
02:21:00: PQ: Serial3/0 output (Pk size/Q 1002/0)
02:21:00: PQ: Serial3/0 dlci 104 -> low
02:21:00: PQ: Serial3/0 dlci 102 -> high
02:21:00: PQ: Serial3/0 dlci 102 -> high
02:21:00: PQ: Serial3/0 output (Pk size/Q 72/0)
02:21:01: PQ: Serial3/0 dlci 102 -> high
02:21:01: PQ: Serial3/0 output (Pk size/Q 1002/0)
02:21:01: PQ: Serial3/0 output (Pk size/Q 1002/0)
02:21:01: PQ: Serial3/0 dlci 102 -> high
02:21:01: PQ: Serial3/0 output (Pk size/Q 1002/0)
02:21:01: PQ: Serial3/0 dlci 104 -> low
02:21:01: PQ: Serial3/0 dlci 102 -> high
02:21:01: PQ: Serial3/0 output (Pk size/Q 1002/0)
02:21:01: PQ: Serial3/0 dlci 102 -> high
02:21:01: PQ: Serial3/0 output (Pk size/Q 1002/0)
02:21:01: PQ: Serial3/0 dlci 102 -> high
02:21:01: PQ: Serial3/0 output (Pk size/Q 1002/0)
02:21:01: PQ: Serial3/0 dlci 104 -> low
02:21:01: PQ: Serial3/0 dlci 102 -> high
02:21:01: PQ: Serial3/0 output (Pk size/Q 1002/0)
02:21:01: PQ: Serial3/0 dlci 102 -> high
02:21:01: PQ: Serial3/0 output (Pk size/Q 1002/0)
02:21:01: PQ: Serial3/0 dlci 102 -> high
02:21:01: PQ: Serial3/0 output (Pk size/Q 1002/0)
02:21:01: PQ: Serial3/0 dlci 104 -> low
02:21:01: PQ: Serial3/0 dlci 102 -> high
02:21:01: PQ: Serial3/0 output (Pk size/Q 1002/0)
02:21:01: PQ: Serial3/0 dlci 102 -> high
02:21:01: PQ: Serial3/0 output (Pk size/Q 1002/0)
02:21:01: PQ: Serial3/0 dlci 102 -> high
02:21:01: PQ: Serial3/0 output (Pk size/Q 1002/0)
02:21:01: PQ: Serial3/0 dlci 104 -> low
02:21:01: PQ: Serial3/0 dlci 102 -> high
02:21:01: PQ: Serial3/0 output (Pk size/Q 1002/0)
02:21:01: PQ: Serial3/0 dlci 102 -> high
02:21:01: PQ: Serial3/0 output (Pk size/Q 1002/0)
02:21:01: PQ: Serial3/0 dlci 102 -> high
02:21:01: PQ: Serial3/0 output (Pk size/Q 1002/0)
02:21:01: PQ: Serial3/0 dlci 104 -> low
02:21:01: PQ: Serial3/0 dlci 102 -> high
02:21:01: PQ: Serial3/0 output (Pk size/Q 1002/0)
02:21:02: PQ: Serial3/0 dlci 102 -> high
02:21:02: PQ: Serial3/0 output (Pk size/Q 1002/0)

!20 seconds later after aggregated traffic from the DLCIs has saturated the Frame Relay link

02:21:19: PQ: Serial3/0 output (Pk size/Q 1002/0)
02:21:19: PQ: Serial3/0 dlci 102 -> high
02:21:19: PQ: Serial3/0 output (Pk size/Q 1002/0)
02:21:19: PQ: Serial3/0 dlci 104 -> low -- congestion drop
02:21:19: PQ: Serial3/0 dlci 102 -> high
02:21:19: PQ: Serial3/0 output (Pk size/Q 1002/0)
02:21:19: PQ: Serial3/0 dlci 102 -> high
02:21:19: PQ: Serial3/0 output (Pk size/Q 1002/0)
02:21:19: PQ: Serial3/0 dlci 102 -> high
02:21:19: PQ: Serial3/0 output (Pk size/Q 1002/0)
02:21:19: PQ: Serial3/0 dlci 104 -> low -- congestion drop
02:21:19: PQ: Serial3/0 dlci 102 -> high
02:21:19: PQ: Serial3/0 output (Pk size/Q 1002/0)
02:21:19: PQ: Serial3/0 dlci 102 -> high
02:21:19: PQ: Serial3/0 output (Pk size/Q 1002/0)
02:21:19: PQ: Serial3/0 dlci 102 -> high
02:21:19: PQ: Serial3/0 output (Pk size/Q 1002/0)
02:21:19: PQ: Serial3/0 dlci 104 -> low -- congestion drop
02:21:19: PQ: Serial3/0 dlci 102 -> high

In the next example, a large volume of traffic is sent over DLCI 104 into the low-priority queue. As a result of this, congestion build-up can be observed at the interface at R1, and the low-priority queue overflows. The results are shown in Example 17-12.

Example 17-12. Output of show interface at R1 After the Low-Priority Queue Overflows
!After sending a large volume of traffic from Client at R1 to R2 over DLCI 104:
R1#show interface serial4/0
Serial4/0 is up, line protocol is up
  Hardware is M4T
  MTU 1500 bytes, BW 2048 Kbit, DLY 20000 usec,
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation FRAME-RELAY, crc 16, loopback not set
  Keepalive set (10 sec)
  LMI enq sent  38, LMI stat recvd 38, LMI upd recvd 0, DTE LMI up
  LMI enq recvd 0, LMI stat sent  0, LMI upd sent  0
  LMI DLCI 1023  LMI type is CISCO  frame relay DTE
  FR SVC disabled, LAPF state down
  Broadcast queue 0/64, broadcasts sent/dropped 165/0, interface broadcasts 126
  Last input 00:00:03, output 00:00:00, output hang never
  Last clearing of "show interface" counters 00:06:32
  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 26069
  Queueing strategy: DLCI priority
  Output queue (queue priority: size/max/drops):
     high: 0/20/0, medium: 0/40/0, normal: 0/60/0, low: 0/80/26069
  5 minute input rate 1000 bits/sec, 1 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
     589 packets input, 43953 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
     1156 packets output, 960428 bytes, 0 underruns
     0 output errors, 0 collisions, 0 interface resets
     0 output buffer failures, 0 output buffers swapped out
     0 carrier transitions     DCD=up  DSR=up  DTR=up  RTS=up  CTS=up

Example 17-13 shows the output the debug priority command enabled on router R1. The results indicate that packets are discarded from the low-priority queue after the queue overflowed.

Example 17-13. Output of the debug priority Command Indicates That All Packets Are Entering the Low-Priority Queue and Discarded
R1#debug priority
03:43:27: PQ: Serial4/0 dlci 104 -> low -- congestion drop
03:43:27: PQ: Serial4/0 dlci 104 -> low -- congestion drop
03:43:27: PQ: Serial4/0 output (Pk size/Q 998/3)
03:43:27: PQ: Serial4/0 dlci 104 -> low
03:43:27: PQ: Serial4/0 dlci 104 -> low -- congestion drop
03:43:27: PQ: Serial4/0 dlci 104 -> low -- congestion drop
03:43:27: PQ: Serial4/0 dlci 104 -> low -- congestion drop
PQ: Serial4/0 dlci 104 -> low> low
03:4
03:43:27: PQ: Serial4/0 output (Pk size/Q 998/3)
03:43:27: PQ: Serial4/0 dlci 104 -> low
03:43:27: PQ: Serial4/0 dlci 104 -> low -- congestion drop
03:43:27: PQ: Serial4/0 dlci 104 -> low -- congestion drop
03:43:27: PQ: Serial4/0 dlci 104 -> low -- congestion drop
03:43:27: PQ: Serial4/0 output (Pk size/Q 998/3)
03:43:27: PQ: Serial4/0 dlci 104 -> low
03:43:27: PQ: Serial4/0 dlci 104 -> low -- congestion drop
03:43:27: PQ: Serial4/0 dlci 104 -> low -- congestion drop
03:43:27: PQ: Serial4/0 dlci 104 -> low -- congestion drop
03:43:27: PQ: Serial4/0 output (Pk size/Q 998/3)
03:43:27: PQ: Serial4/0 dlci 104 -> low
03:43:28: PQ: Serial4/0 dlci 104 -> low -- congestion drop
PQ: Serial4/0 dlci 104 -> low3:27: PQ: Seria: PQ: Serial4/0 dlci 104 -> low -- congestion drop
03:43:28: PQ: Serial4/0 output (Pk size/Q 998/3)
03:43:28: PQ: Serial4/0 dlci 104 -> low
03:43:28: PQ: Serial4/0 dlci 104 -> low -- congestion drop
03:43:28: PQ: Serial4/0 dlci 104 -> low -- congestion drop
03:43:28: PQ: Serial4/0 dlci 104 -> low -- congestion drop
03:43:28: PQ: Serial4/0 dlci 104 -> low -- congestion drop
03:43:28: PQ: Serial4/0 output (Pk size/Q 998/3)
03:43:28: PQ: Serial4/0 dlci 104 -> low
03:43:28: PQ: Serial4/0 dlci 104 -> low -- congestion drop
03:43:28: PQ: Serial4/0 dlci 104 -> low -- congestion drop
PQ: Serial4/0 dlci 104 -> lowl4/0 dlci 1
03:43:28: PQ: Serial4/0 dlci 104 -> low -- congestion drop
03:43:28: PQ: Serial4/0 output (Pk size/Q 998/3)
03:43:28: PQ: Serial4/0 dlci 104 -> low

Example 17-14 serves to verify that even though the interface is now congested with traffic from the low-priority queue, it is possible to send traffic that has a higher priority across the Frame Relay network.

Example 17-14. Ping from Client at R1 Across the Frame Relay Network Is Working
C:\>ping 172.16.3.1

Pinging 10.112.2.202 with 32 bytes of data:

Reply from 172.16.3.1: bytes=32 time<10ms TTL=254
Reply from 172.16.3.1: bytes=32 time<10ms TTL=254
Reply from 172.16.3.1: bytes=32 time<10ms TTL=254
Reply from 172.16.3.1: bytes=32 time<10ms TTL=254

Ping statistics for 172.16.3.1:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum =  0ms, Average =  0ms


Summary

This chapter presented a general overview of the use of queuing mechanisms to effectively manage and control traffic flows on congested Frame Relay networks. This chapter introduced the different types of queuing supported on Frame Relay networks, such as PQ, CQ, WFQ, LLQ, and Frame Relay PIPQ. This chapter showed readers the two levels of queuing on Frame Relay interfaces when Frame Relay Traffic Shaping is enabled: PVC level and interface level. This chapter explained how interface-level and PVC-level queues compare.

Subsequently, this chapter focused on the Frame Relay PIPQ feature. The Frame Relay PIPQ feature allows users to define a PQ system at the interface level. Frame Relay packets are prioritized based on the Frame Relay PVC they traverse, instead of the packet contents classification method used in the legacy PQ mechanism. This chapter demonstrated with practical examples how the Frame Relay PIPQ feature can be used on networks where separate classes of traffic are transported on different PVCs. Mission-critical or delay-sensitive traffic is typically carried on a Frame Relay PVC destined for the high-priority interface queue. The chapter ended with an explanation of the relevant Cisco IOS show and debug commands for monitoring and maintaining Frame Relay PIPQ on a Cisco router.

In the next chapter, the Class Based Weighted Fair Queuing (CBWFQ) and Low Latency Queuing (LLQ) systems are covered.


Review Questions

1: | Define the role of queuing in Frame Relay.
2: | Name the current queuing mechanisms for Frame Relay supported on Cisco routers.
3: | What is Frame Relay PIPQ?
4: | How do PVC-level queues and interface-level queues compare?
5: | Describe the use of a Dual-FIFO queue in Frame Relay.
6: | Describe the use of the Frame Relay broadcast queue.


References

  • Cisco IOS Quality of Service Solutions Configuration Guide Release 12.2, Congestion Management: http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/fqos_c/fqcprt2/index.htm

  • Cisco IOS Release 12.1(1)T Connection Documentation, Frame Relay PVC Interface Priority Queuing: http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121newft/121t/121t1/dtfrpipq.htm


Chapter 18. Frame Relay Class-Based Weighted Fair Queuing (CBWFQ) and Low Latency Queuing (LLQ)

By now, readers should be familiar with congestion management on Frame Relay networks and how queuing can be used to effectively manage network congestion. Generally, when a network becomes congested and there is insufficient bandwidth to service all user traffic, queuing algorithms can influence the transmission order of packets belonging to different priority levels which are held in the queues. Intelligent queuing provides differentiated services (DiffServ) to the different classes of traffic on the Frame Relay network to manage network congestion. When congestion management mechanisms are effectively deployed with other QoS components such as Traffic Conditioners (Shaping and Policing) and Congestion Avoidance (RED, WRED), the End-to-End QoS solution helps to minimize network delay, latency, and jitter for both mission-critical and real-time traffic.

This chapter focuses on two important Frame Relay queuing algorithms that are closely interrelated, namely, Frame Relay Class-Based Weighted Fair Queuing (CBWFQ) and Low Latency Queuing (LLQ) for Frame Relay. However, before moving into the detailed discussion of both Frame Relay queuing features, it is important for this chapter to introduce readers to Cisco's Modular Quality of Service Command Line Interface (MQC), because MQC supports a majority of Cisco QoS features. MQC first appeared in Cisco IOS Release 12.0(5)T as a framework for CBWFQ. MQC presents a new command-line interface (CLI) structure for users to configure QoS policies and QoS features. Both CBWFQ and LLQ are configured via the MQC interface with the Cisco IOS software.

Throughout this chapter, configuration examples are provided, with scenarios of how the new features are commonly used and applied. Troubleshooting and monitoring commands for the use of the features are also explained.

The topics and questions that this chapter addresses include the following:

  • Overview of MQC

  • Understanding the operations of CBWFQ for Frame Relay and the difference between CBWFQ and WFQ

  • Understanding the operations of LLQ for Frame Relay

  • Configuring CBWFQ for Frame Relay on Cisco routers

  • Configuring LLQ for Frame Relay on Cisco routers

  • Monitoring and maintaining MQC, CBWFQ, and LLQ for Frame Relay on Cisco routers

After completing this chapter, readers will recognize the advantages and benefits of the Cisco MQC for deploying QoS features with the Cisco IOS software. Readers will be familiar with the operations and configurations of the CBWFQ for Frame Relay and LLQ for Frame Relay features. Finally, readers will be able to use Cisco IOS show commands to monitor and maintain CBWFQ for Frame Relay and LLQ for Frame Relay configurations on a Cisco router.


Overview of the MQC

MQC is essentially a comprehensive framework for customers and users to deploy QoS policies on a network. MQC offers a modular and hierarchical approach that allows users to create policies to meet their QoS requirements. The basic MQC configuration encompasses the following three steps:

Step 1. | Create a traffic class with the class-map global configuration command.
Step 2. | Create a traffic policy with the policy-map global configuration command. With the traffic policy, the traffic class is associated with one or more QoS features.
Step 3. | Apply the policy-map to the interface, subinterface, ATM, or Frame Relay permanent virtual circuit (PVC) with the service-policy configuration command. With this, the QoS policies defined by the user in the policy-map act upon all packets entering or leaving the interface, subinterface, ATM, or Frame Relay PVC.

The first step of MQC configuration is to identify the interesting traffic to perform traffic classification. To meet this purpose, a class-map is configured to classify a group of network traffic. MQC offers a host of ways to allow the user to perform traffic classification.

After configuring the class-map to identify the interesting traffic, the second step involves the configuration of a policy-map. The policy-map decides the actions to be performed on the traffic identified by the preconfigured class-map. This step also involves associating the selected QoS features or QoS actions to be performed with the traffic identified.

The combination of the class-map and the QoS actions configured in the policy-map determines how the classified traffic is treated in the traffic policy. For example, the QoS actions can dictate a queuing or shaping function to be performed on the identified traffic.

The third and final step involves applying the policy-map to an interface, subinterface, ATM, or Frame Relay PVC on the Cisco router. Applying a policy-map to an interface, subinterface, ATM PVC, or Frame Relay PVC is accomplished with the service-policy command.

Figure 18-1 illustrates an example of a QoS policy configuration created using MQC. The purposes and the use of the new commands shown in the MQC configuration example are explained after the figure. The main objective in this section is use this configuration example to illustrate the hierarchical structure of the MQC for setting up QoS traffic policies.

Figure 18-1. Example of MQC Configurations

With reference to the configuration example shown in Figure 18-1, the first configuration step involved in the creation of a QoS traffic policy using MQC is traffic classification. A traffic class is used to classify traffic entering or leaving the interface where the traffic policy is applied. If the contents of the packets match the conditions specified in a traffic class, then the identified traffic is a member of that traffic class. A QoS traffic policy can have a single traffic class or multiple user-defined traffic classes. A traffic class is configured with the class-map class-map-name global configuration command. Referring to the configuration example in Figure 18-1, three traffic classes are configured with the following user-defined class-map names: "Data_BRONZE," "SNA_SILVER," and "voice_GOLD."

Configuring a Traffic Class with the class-map Command

When configuring a traffic class with the class-map command, many options and criteria are available to users to classify traffic. Under the class-map command, the match commands are used to specify the criteria for identifying the packets. As packets enter or leave the interface, they are checked to determine whether they match the criteria defined in the match statement. If they do, the packets are classified as members of the traffic class. On the contrary, if the packets fail to match any user-defined traffic class, they are classified as members of the default class. One or more match statements can be configured under a class-map command, as shown previously in the "SNA_SILVER" class-map in Figure 18-1.

Setting Up a Traffic Class with the class-map Command

When setting up a traffic class with the class-map command, you can specify either the match-any or match-all option. If not specified, the default is match-any. When match-any is chosen and the class-map has multiple match statements, incoming or outgoing traffic on the interface only needs to match one of the match statements to be classified as a member of the traffic class. Conversely, when match-all is used, all match statements in the class-map must be matched in order for the traffic to be associated with the traffic class.

After configuring a class-map to perform traffic classification, you have to identify the methods to classify the traffic that belong to the class-map. Traffic classification can be performed with many different methods, such as an access control list (ACL).

As shown in Figure 18-1, it is possible to define the matching criteria based on many methods, such as ACLs, protocol types, IP precedence values, CoS, and input interfaces. In the configuration example shown in Figure 18-1, an extended access list 101 is configured to identify traffic that belongs to the "Data_BRONZE" traffic class. Example 18-1 shows the possible methods for the match command.

Example 18-1. match Command Options When Configuring class-map
Router(config)#class-map ?
  WORD       class-map name
  match-all  Logical-AND all matching statements under this classmap
  match-any  Logical-OR all matching statements under this classmap

Router(config)#class-map GOLD
Router(config-cmap)#match ?
  access-group         Access group
  any                  Any packets
  class-map            Class map
  cos                  IEEE 802.1Q/ISL class of service/user priority values
  destination-address  Destination address
  input-interface      Select an input interface to match
  ip                   IP specific values
  mpls                 Multi Protocol Label Switching specific values
  not                  Negate this match result
  protocol             Protocol
  qos-group            Qos-group
  source-address       Source address

After defining the traffic classes with the class-map command to classify the different classes of traffic that an interface might receive or transmit, the next step requires the setup of a traffic policy with the policy-map global configuration command. Similar to the class-map configuration command, the policy-map needs a user-defined name to differentiate a traffic policy from other traffic policies on the router.

As shown in Figure 18-1, "CBWFQ_policy" identifies the name of a traffic policy configured on the router. Within the traffic policy, the user needs to associate the class-maps with the traffic policy and decide the action to be performed on each identified class of traffic. Inside a policy-map, the class command is used to reference the name of a particular configured class-map. This step enters the user into the policy-map-class configuration mode. In this mode, the user sets up the QoS actions to be performed on the traffic matched by the corresponding class-map. Example 18-2 shows the list of possible QoS actions that can be performed on the traffic matched by the GOLD class-map.

Example 18-2. Possible QoS Actions for a Classified Traffic Class in a policy-map
Router(config)#policy-map EXAMPLE
Router(config-pmap)#class GOLD
Router(config-pmap-c)#?
QoS policy-map class configuration commands:
  bandwidth       Bandwidth
  default         Set a command to its defaults
  exit            Exit from QoS class action configuration mode
  no              Negate a command or set its defaults
  police          Police
  priority        Strict Scheduling Priority for this Class
  queue-limit     Queue Max Threshold for Tail Drop
  random-detect   Enable Random Early Detection as drop policy
  service-policy  Configure QoS Service Policy
  shape           Traffic Shaping
  <cr>
  set             Set QoS values

In the example shown in Figure 18-1, the "CBWFQ_policy" policy-map defines the QoS actions to be performed on each category of traffic matched by the conditions set up in the class-maps. The bandwidth percent command is used to allocate a percentage of the total bandwidth that can be consumed by traffic matched by the conditions specified in the associated class-map. In this example, 50 percent of the total bandwidth can be allocated to traffic matched by the class-map voice_GOLD. All traffic carrying an IP precedence of 5 belongs to the class-map voice_GOLD. In other words, the QoS policy allocates up to 50 percent of the total bandwidth to traffic with IP precedence 5.

Incoming or outgoing traffic on the interface that does not match the voice_GOLD class-map is matched against the conditions specified in the remaining class-maps in a top-down approach. If the traffic does not match any of the user-defined class-maps, the traffic matches the class-default class-map, and the QoS actions configured in the class-default class-map are performed. In this example, traffic not matching any of the user-defined class-maps is fair queued.

The final step in Figure 18-1 entails attaching the traffic policy to an active interface on the router via the service-policy command. The service-policy command can be used to apply the traffic policy to either incoming or outgoing traffic. In Figure 18-1, the service-policy output CBWFQ_policy command directly applies the "CBWFQ_policy" traffic policy to all traffic leaving interface serial4/0 on the router.

The configuration example shown in this section serves to familiarize the reader with the steps involved in setting up QoS policies using MQC. Both CBWFQ and LLQ are configured with MQC. You will come across more configuration examples involving MQC later on in this chapter.


CBWFQ

This section looks at an advanced queuing feature for Frame Relay known as CBWFQ. CBWFQ is essentially an extension of the original flow-based WFQ algorithm discussed in detail in Chapter 17, "Frame Relay Congestion Management." In contrast to WFQ, CBWFQ allows and supports up to 64 user-defined traffic classes. Figure 18-2 illustrates the basic concepts of CBWFQ. The next section discusses how WFQ and CBWFQ compare.

Figure 18-2. How CBWFQ Works

In the previous chapter, the WFQ algorithm was briefly introduced. Before diving into the discussion on CBWFQ in this chapter, the next section revises what you learned about WFQ. The direct comparison between CBWFQ and WFQ allows you to understand the differences and applications of the two queuing mechanisms.

WFQ Revisited

The standard WFQ mechanism provides traffic priority management that automatically sorts among individual traffic streams without requiring the user to define access lists or any other forms of controls. Using a dynamic scheduling method, WFQ provides fair bandwidth allocation to all network traffic. Weights are applied to the identified traffic to classify it into conversations, or flows. The standard WFQ determines how much bandwidth will be given to each conversation. However, all traffic is treated fairly by WFQ based on the weights in a dynamic manner. For example, WFQ addresses the requirements of interactive traffic without penalizing traffic such as FTP file transfers.

WFQ is the default queuing strategy on all interfaces with a speed of E1 (2.048 Mbps) and below. For other interfaces supporting a speed greater than E1, the default queuing used is FIFO. WFQ can be disabled with the no fair-queue interface configuration command. It is replaced by FIFO if there are no other queuing mechanisms configured on the interface. To enable WFQ again on an interface if it has been previously disabled, use the fair-queue interface configuration command as follows:

fair-queue [congestive-discard-threshold [dynamic-queues [reservable-queues]]]

The configuration for WFQ on an interface does not require any parameters to be specified. However, WFQ supports a few optional configuration parameters to allow the user to customize WFQ. The configurable options are as follows:

  • The congestive-discard-threshold option specifies the number of messages allowed in each queue. The value must be a power of 2 in the range from 16 to 4096. The default value is 64 messages. New messages are discarded when a conversation reaches this threshold.

  • The dynamic-queues option indicates the number of dynamic queues to be used for best-effort conversations not requiring any special services.

  • The reservable-queues option sets the number of reservable queues for use by features such as Resource Reservation Protocol (RSVP). The configurable range is 0 to 1000, and the default value is 0.

Unlike with WFQ, a user can manipulate the weight for a class in CBWFQ. Configuring CBWFQ involves three major steps:

Step 1. | Defining traffic classification policy with class-map.
Step 2. | Associating each traffic class with a traffic policy.
Step 3. | Attaching the final traffic policy to the interface.

Understanding CBWFQ

CBWFQ entails setting up traffic classes based on match criteria such as access lists, input interfaces, or protocol types. When incoming packets arrive, the packets are matched with the criteria specified in the traffic classes. Packets matching the criteria for a class constitute the traffic for that traffic class. In CBWFQ, a queue is reserved for each traffic class, and traffic belonging to a traffic class is directed to the queue for that class.

After defining the match criteria for each traffic class, the user must determine the characteristics for the class by defining appropriate actions for traffic matching that class. For example, the user can specify the bandwidth, maximum queue limit, or the drop policy to a class.

When bandwidth is used to characterize a class, the assigned bandwidth indicates the guaranteed bandwidth delivered to the class during network congestion. When queue limit is used, the maximum number of packets allowed to accumulate in the queue for the class is specified. If a drop policy is not specified for a traffic class, then Tail Drop is used by default. When Tail Drop is in use, enqueuing of an additional packet to a queue that has already reached its configured queue limit causes that packet to be dropped. On the other hand, CBWFQ supports Weighted Random Early Detection (WRED), which allows packets to be randomly dropped based on their precedence value. For instance, when WRED is used, packets with a lower precedence are dropped than packets with a higher precedence. Among the low-precedence packets, WRED can be configured so that 10 percent of the low-precedence packets are randomly dropped.

CBWFQ supports the use of a default class. The default class is specified in a policy-map as class-default. The default class in CBWFQ can be configured to treat all unclassified traffic based on bandwidth or other policies. For example, if bandwidth is used, all unclassified traffic in the default class is treated according to the configured bandwidth. In addition, WFQ can be configured in CBWFQ so that the traffic is flow classified and fairly treated. If no default class is configured, by default, all unclassified traffic that does not match any of the configured classes is flow classified and treated by WFQ.

Comparing WFQ to CBWFQ

Unlike in WFQ, the weight for a packet is derived from the bandwidth assigned to the class in CBWFQ. Hence, the weight is user-configurable in CBWFQ, because it allows the user to specify the exact amount of bandwidth to be allocated for a specific class of traffic. Depending on the amount of bandwidth available at the interface, up to 64 classes can be configured. The user has full control of the distribution of bandwidth among them. This is not possible with WFQ. As for traffic classification, CBWFQ allows the user to define the criteria that constitute a class. For WFQ, this is based only on a flow basis.


Configuring CBWFQ for Frame Relay

This section discusses the configuration tasks for enabling CBWFQ on Frame Relay PVCs. CBWFQ is configured via the MQC configuration interface; MQC was explained at the beginning of this chapter. Table 18-1 lists the configuration options available for setting up the traffic classes. Table 18-2 displays the class policy configurations available.

Table 18-1. Available Options for Setting Up the Traffic Class (class-map)

Command (config-cmap)

Purpose

match access-group {access-group | name access-group-name}

The content of the packets is checked against the access list or named access list to determine if they belong to the class.

match input-interface interface-name

This checks the input interface of the packets to determine if they belong to the class.

match protocol protocol

This checks the packets to determine if they belong to a given protocol and hence, to the class.

match mpls experimental number

This checks the EXP field in the packets to determine if they belong to the class.

Table 18-2. Available Options for Setting Up the Class Policy (policy-map)

Command (config-pmap-c)

Purpose

bandwidth [percent percent] or bandwidth kbps

This specifies the amount of bandwidth in kbps to be assigned to the class. The user should consider the Layer 2 overhead in the configured bandwidth. Note that beginning with Cisco IOS Release 12.1(1), the percent keyword is supported, and bandwidth can be assigned as a percentage.

queue-limit

This specifies the maximum number of packets that can be enqueued for the class. This uses the Tail Drop method.

random-detect

This enables WRED. The class policy drops packets using WRED instead of Tail Drop. WRED is explained in more detail in Chapter 21, "Weighted Random Early Detection (WRED) for Frame Relay."

fair-queue (applicable to class-default only)

This specifies the number of dynamic queues to be reserved for use by flow-based WFQ running on the default class.

priority kbps

This creates a strict priority class and specifies the amount of bandwidth in kbps to be assigned to the class.

NOTE

CBWFQ is introduced in Cisco IOS Release 12.0(5)T. CBWFQ for Frame Relay is supported on c2600, c3600, and c7200 series routers in Cisco IOS Release 12.1(2)T or later. On the c7500 series with VIP, distributed CBWFQ mode is supported in Cisco IOS Release 12.1(5)T or later.

To set up CBWFQ for Frame Relay on a Cisco router, the user first needs to configure the CBWFQ policy using the MQC. In addition, if your router platform supports Frame Relay Traffic Shaping, FRTS should be enabled for the Frame Relay interface that uses CBWFQ. After these steps are accomplished, the CBWFQ policy needs to be attached to the Frame Relay interface. There are several options available with regard to where the service policy can be applied.

First of all, the policy-map created for CBWFQ can be applied to a Frame Relay map class if CBWFQ needs to be applied to a Frame Relay subinterface or directly to a Frame Relay PVC. Frame Relay Traffic Shaping has to be enabled at the main interface on platforms that support Frame Relay Traffic Shaping. On c7500 series routers, Distributed Traffic Shaping (DTS) is supported, and the shape command has to be used in the policy-map to implement shaping. DTS combines Generic Traffic Shaping (GTS) and Frame Relay Traffic Shaping.

NOTE

As of Cisco IOS Release 12.1(5)T, QoS policies must run in distributed mode on the VIP because RSP-based QoS is no longer supported.

If the configured policy-map is applied directly at the main interface level, the CBWFQ mechanism applies to a single interface queue rather than at the per-PVC level queues.

Figure 18-3 shows the topology of the network used to demonstrate CBWFQ. The scenario presented in this example shows how CBWFQ can be used to allocate bandwidth to different classes of traffic on a heterogeneous network. It should be noted here that this scenario only serves as an example. The accompanying configuration examples are not cast in stone because of the varying characteristics and requirements of every network.

Figure 18-3. Network Diagram for Verifying CBWFQ for Frame Relay

As shown in Figure 18-3, routers R1 and R2 are connected to a Frame Relay network. Router R1 represents a spoke office location connected to the central office via a Frame Relay network, at a relatively slow access rate of 64 kbps. The Frame Relay network allows the sites to burst above their respective CIR rates when the traffic is light. R1 serves several remote users at its location, who need to frequently access the main Web server at the central office. The finance administrator at the spoke location with the static address 10.0.0.2/24 needs to upload daily revenue information via a TCP application. At the same time, the company is considering a voice over IP (VoIP) implementation on its network and has installed trial phones on its routers.

The configuration examples for the routers in Figure 18-3 are shown in Example 18-3.

Example 18-3. Configuration Examples of Routers in Figure 18-3
! Router R1:

class-map match-any deluxe
  match ip precedence 5
  match access-group name UDP
class-map match-all premium
  match access-group 101
!
policy-map CBWFQ
  class premium
   bandwidth 32
  class deluxe
   bandwidth 16
   queue-limit 80
  class class-default
   fair-queue
!
interface FastEthernet0/0
 ip address 10.0.0.1 255.255.255.0
!
interface Serial4/0
 no ip address
 encapsulation frame-relay
 no fair-queue
 frame-relay traffic-shaping
!
interface Serial4/0.102 point-to-point
 ip address 172.16.1.1 255.255.255.252
 frame-relay interface-dlci 102
  class CBWFQ_class
!
router eigrp 1
 network 172.16.1.0 0.0.0.3
 network 10.0.0.0 0.0.0.255
!
ip access-list extended UDP
 permit udp any any gt 10000
!
!
map-class frame-relay CBWFQ_class
 frame-relay cir 96000
 frame-relay mincir 64000
 frame-relay adaptive-shaping becn
 service-policy output CBWFQ
!
access-list 101 permit ip host 10.0.0.2 any
!
dial-peer voice 1 pots
 destination-pattern 4001
!
dial-peer voice 2 voip
 destination-pattern 4002
 ip precedence 5
 session target ipv4:172.16.1.2
________________________________________________________________
! Router R2:

interface FastEthernet0/1
 ip address 192.168.1.1 255.255.255.0
 no ip mroute-cache
 duplex auto
 speed auto
 no cdp enable
!
interface Serial2/1
 no ip address
 encapsulation frame-relay
 no ip mroute-cache
 no fair-queue
 clockrate 128000
 frame-relay class FRTS
 frame-relay traffic-shaping
!
interface Serial2/1.201 point-to-point
 ip address 172.16.1.2 255.255.255.252
 frame-relay interface-dlci 201
!
router eigrp 1
 network 172.16.1.0 0.0.0.3
 network 192.168.1.0 0.0.0.255
!
map-class frame-relay FRTS
 frame-relay cir 512000
 frame-relay mincir 256000
 frame-relay adaptive-shaping becn
 !
dial-peer voice 1 pots
 destination-pattern 4002
!
dial-peer voice 2 voip
 destination-pattern 4001
 ip precedence 5
 session target ipv4:172.16.1.1

As shown in Example 18-3, CBWFQ is configured on Frame Relay DLCI 102 at router R1. R1 has a guaranteed access rate of 64 kbps. Because of the different classes of traffic that run on the network, CBWFQ is selected as the queuing mechanism to allocate bandwidth among the different types of traffic. Half of the available bandwidth is allocated to the premium traffic class with the bandwidth command in the class-map premium configurations. The premium class matches traffic based on access list 101, which is in turn matched to all IP traffic from host 10.0.0.2.

Next, 16 kbps is assigned to traffic that matches either named access-list UDP or any traffic with IP precedence set to critical (5). The VoIP traffic between the sites is assigned the precedence of 5.

Traffic not matching any of the criteria set up in the user-defined class-maps goes into the default class. The WFQ scheme is applied to traffic in this default class. The completed policy-map is attached to the CBWFQ_class map-class configuration for Frame Relay. This is assigned to DLCI 102.

Finally, Frame Relay Traffic Shaping is configured at the main serial interface 4/0. The CIR rate is set to 96 kbps, and the minimum CIR rate is fixed at the guaranteed 64 kbps in the Frame Relay map class. This Frame Relay Traffic Shaping configuration allows traffic on DLCI 102 to burst up to 96 kbps during no congestion. Some carriers allow their customers to burst up to the port speed when there is no congestion. When congestion occurs in the Frame Relay network, the output rate can step back to the guaranteed rate of 64 kbps. The CBWFQ mechanism ensures traffic belonging to the defined classes of traffic receive the allocated share of bandwidth.

It is important to mention that the user should ensure that the amount of bandwidth configured is large enough to accommodate all overhead, such as the Layer 2 overhead.

The next section looks at the commands for monitoring CBWFQ for the examples in Figure 18-3.


Monitoring and Troubleshooting CBWFQ for Frame Relay

The show policy-map privileged EXEC command can be used to display the configurations of all classes comprising the specified service policy map or all classes for all existing policy maps. A sample output of the show policy-map command is shown in Example 18-4.

Example 18-4. Output of show policy-map Command at R1
R1#show policy-map
  Policy Map CBWFQ
    Class premium
      Weighted Fair Queueing
            Bandwidth 32 (kbps) Max Threshold 64 (packets)
    Class deluxe
      Weighted Fair Queueing
            Bandwidth 16 (kbps) Max Threshold 80 (packets)
    Class class-default
      Weighted Fair Queueing
            Flow based Fair Queueing Max Threshold 64 (packets).

The show policy-map interface command can be used to view the policy-map currently attached to the specified interface. A sample output is shown in Example 18-5.

Example 18-5. Output of show policy-map interface Command at R1
R1#show policy-map inter s4/0.102
 Serial4/0.102: DLCI 102 -

  Service-policy output: CBWFQ (1641)

    Class-map: premium (match-all) (1643/2)
      285808 packets, 28580800 bytes
      5 minute offered rate 32000 bps, drop rate 0 bps
      Match: access-group 101 (1647)
      Weighted Fair Queueing
        Output Queue: Conversation 25
        Bandwidth 32 (kbps) Max Threshold 64 (packets)
        (pkts matched/bytes matched) 285808/28580800
        (depth/total drops/no-buffer drops) 0/0/0

    Class-map: deluxe (match-any) (1651/3)
      369 packets, 91512 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: ip precedence 5  (1655)
        369 packets, 91512 bytes
        5 minute rate 0 bps
      Match: access-group name UDP (1659)
        0 packets, 0 bytes
        5 minute rate 0 bps
      Weighted Fair Queueing
        Output Queue: Conversation 26
        Bandwidth 16 (kbps) Max Threshold 80 (packets)
        (pkts matched/bytes matched) 369/91512
        (depth/total drops/no-buffer drops) 0/0/0

    Class-map: class-default (match-any) (1663/0)
      571854 packets, 57244662 bytes
      5 minute offered rate 64000 bps, drop rate 27000 bps
      Match: any  (1667)
      Weighted Fair Queueing
        Flow Based Fair Queueing
        Maximum Number of Hashed Queues 16
        (total queued/total drops/no-buffer drops)
                       64/248543/0

The show frame-relay pvc DLCI privileged EXEC command can be used to verify and troubleshoot CBWFQ on a Cisco router. When CBWFQ is configured at the Frame Relay PVC level, the output of the show frame-relay pvc DLCI command shows additional detailed information, such as the name of the service policy attached, the number of packets matched to each class-map in the policy, and the number of packets transmitted, enqueued and dropped. The sample output in Example 18-6 shows the information displayed by the show frame-relay pvc DLCI command at R1 after traffic has been active on the Frame Relay network.

Example 18-6. Output of show frame-relay pvc 102 at R1
R1#show frame-relay pvc 102

PVC Statistics for interface Serial4/0 (Frame Relay DTE)

DLCI = 102, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial4/0.102

  input pkts 1530          output pkts 140100       in bytes 160329
  out bytes 13509272       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 20        out bcast bytes 6980
Shaping adapts to BECN
  pvc create time 1w0d, last time pvc status changed 1w0d
  cir 96000     bc 96000     be 0         byte limit 1500   interval 125
  mincir 64000     byte increment 1500  Adaptive Shaping BECN
  pkts 98938     bytes 9953392   pkts delayed 98938     bytes delayed 9953392
  shaping active
  traffic shaping drops 41219
  service policy CBWFQ

  Service-policy output: CBWFQ (1641)

    Class-map: premium (match-all) (1643/2)
      46317 packets, 4631700 bytes
5 minute offered rate 32000 bps, drop rate 0 bps
      Match: access-group 101 (1647)
           Weighted Fair Queueing
             Output Queue: Conversation 25
             Bandwidth 32 (kbps) Max Threshold 64 (packets)
             (pkts matched/bytes matched) 47118/4711800
        (depth/total drops/no-buffer drops) 0/0/0

    Class-map: deluxe (match-any) (1651/3)
      369 packets, 91512 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: ip precedence 5  (1655)
        369 packets, 91512 bytes
        5 minute rate 0 bps
      Match: access-group name UDP (1659)
        0 packets, 0 bytes
        5 minute rate 0 bps
           Weighted Fair Queueing
             Output Queue: Conversation 26
             Bandwidth 16 (kbps) Max Threshold 80 (packets)
             (pkts matched/bytes matched) 369/91512
        (depth/total drops/no-buffer drops) 0/0/0

Class-map: class-default (match-any) (1663/0)
      94274 packets, 9437360 bytes
      5 minute offered rate 64000 bps, drop rate 27000 bps
      Match: any  (1667)
           Weighted Fair Queueing
             Flow Based Fair Queueing
             Maximum Number of Hashed Queues 16
        (total queued/total drops/no-buffer drops)
                       63/42070/0
Output queue size 64/max total 600/drops 42070

Analyzing the output of show frame-relay pvc command in Example 18-6, you can see that 32 kbps of bandwidth is used by traffic belonging to the premium class, while about 64 kbps of bandwidth is used by traffic from the default class. The router is now transmitting at the CIR rate when there is no congestion, and the CIR rate is controlled by FRTS. When congestion occurs, the rate can be throttled down to the guaranteed rate of 64 kbps.

As shown in the show frame-relay pvc output, during no congestion, the aggregate throughput is about 96 kbps. 64 kbps of bandwidth (96 kbps minus 32 kbps used by the premium class) is now available to deluxe class and the default class.

Also observe in the output that there is no traffic that belongs to the deluxe class showing up. Because there is no active traffic from the deluxe class, all available bandwidth can be reused by other traffic comprising the premium class or the default class (which is all traffic not matched by any user-defined class-map).

Note that although 32 kbps and 16 kbps are reserved for traffic from the premium and deluxe classes, they can use up more than their allocated share of the bandwidth if more premium or deluxe traffic arrives. In other words, they are not policed. If the premium or deluxe traffic is transmitting at a rate much higher than its assigned bandwidth, limited bandwidth is available for traffic from the default class. WFQ can be removed and the bandwidth command can be used under the default class to allocate a minimum share of bandwidth to default traffic in order to prevent this condition.

This can be verified by removing fair-queue from the class-default class and adding bandwidth 16 to allocate the remaining 16 kbps to the class-default class. This change ensures that when traffic from all classes is bursting, traffic from the default class gets a share of the service. Example 18-7 shows the output of the resultant changes.

Example 18-7. Output of show frame-relay pvc at R1 After Allocating Bandwidth to the Default Class
R1#show frame-relay pvc 102

PVC Statistics for interface Serial4/0 (Frame Relay DTE)

DLCI = 102, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial4/0.102
  input pkts 1294          output pkts 163173       in bytes 95394
  out bytes 15681306       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 66        out bcast bytes 23034
  Shaping adapts to BECN
  pvc create time 1w1d, last time pvc status changed 1w1d
  cir 64000     bc 64000     be 0         byte limit 1000   interval 125
  mincir 64000     byte increment 1000  Adaptive Shaping BECN
  pkts 71892     bytes 7205634   pkts delayed 71821     bytes delayed 7185835
  shaping active
  traffic shaping drops 91211
  service policy CBWFQ

  Service-policy output: CBWFQ (2037)

    Class-map: premium (match-all) (2039/2)
      51382 packets, 5138200 bytes
      5 minute offered rate 48000 bps, drop rate 16000 bps
      Match: access-group 101 (2043)
      Weighted Fair Queueing
        Output Queue: Conversation 25
        Bandwidth 32 (kbps) Max Threshold 64 (packets)
        (pkts matched/bytes matched) 103392/10339200
        (depth/total drops/no-buffer drops) 63/25340/0

    Class-map: deluxe (match-any) (2047/3)
      144664 packets, 14466400 bytes
      5 minute offered rate 48000 bps, drop rate 32000 bps
      Match: ip precedence 5  (2051)
        0 packets, 0 bytes
        5 minute rate 0 bps
      Match: access-group name UDP (2055)
        144664 packets, 14466400 bytes
        5 minute rate 48000 bps
      Weighted Fair Queueing
        Output Queue: Conversation 26
        Bandwidth 16 (kbps) Max Threshold 80 (packets)
        (pkts matched/bytes matched) 145059/14505900
        (depth/total drops/no-buffer drops) 80/105933/0

    Class-map: class-default (match-any) (2059/0)
      69280 packets, 6968338 bytes
      5 minute offered rate 48000 bps, drop rate 32000 bps
      Match: any  (2063)
      Weighted Fair Queueing
        Output Queue: Conversation 27
        Bandwidth 16 (kbps) Max Threshold 64 (packets)
        (pkts matched/bytes matched) 69684/6968400
        (depth/total drops/no-buffer drops) 64/46493/0
  Output queue size 208/max total 600/drops 177930

As shown in Example 18-7, traffic from the premium, deluxe, and default classes is allocated 32 kbps, 16 kbps, and 16 kbps of bandwidth, respectively. To illustrate this example, the CIR is lowered to 64 kbps to remove oversubscription.

Note that the Cisco IOS CLI rejects any attempt by the user to allocate additional bandwidth to the policy-map if the resultant changes cause the aggregate bandwidth in the policy-map to exceed the total bandwidth available at the interface. Example 18-8 shows the Cisco IOS CLI rejecting an attempt to increase the bandwidth of the premium class because the aggregate bandwidth in the CBWFQ policy-map has now exceeded 64 kbps.

Example 18-8. Attempt to Increase Bandwidth Is Rejected by CLI
[View full width]
R1(config)#policy-map CBWFQ
R1(config-pmap)#class premium
R1(config-pmap-c)#bandwidth 33
 I/f Serial4/0.102 DLCI 102 Class premium requested bandwidth 33 (kbps) Only 0 (kbps)
   available

The bandwidth percent command can also be used to allocate traffic as a percentage of the available bandwidth. Remember that when the percent keyword is used, all the class bandwidths must be specified as percentages. A mix of both kbps and percent is not allowed.

This example concludes the discussion of CBWFQ on Frame Relay. In the next section, a new exciting queuing strategy known as LLQ, or PQ/CBWFQ, is discussed. Since LLQ was developed, it has been widely adopted and used on voice/data networks.


LLQ, or PQ/CBWFQ

With the emergence of voice traffic into data networks, the need to differentiate between the various classes of service has become greater. PQ/CBWFQ, most commonly known as LLQ, is a new feature that provides a strict priority queue for voice traffic and a weighted fair queue for each of the other classes of traffic. LLQ brings strict priority queuing to the CBWFQ scheme. Figure 18-4 illustrates the basic concepts of how LLQ works.

Figure 18-4. How LLQ Works

Without LLQ, the CBWFQ scheme provides WFQ to classes of traffic defined by the user, but there is no strict priority queue for delay-sensitive traffic, such as voice. CBWFQ allows the user to reserve a minimum bandwidth for a class during congestion. However, this scheme does not work well for voice traffic, which is intolerant of delay. Delay in voice traffic results in irregular transmission causing jitter in the heard conversation. For good voice quality, the one-way end-to-end delay should ideally be less than 150 milliseconds (ms). The new feature provided by LLQ is especially important for ensuring voice quality on slow-speed links.

With LLQ, a strict priority queuing scheme improves the QoS by allowing delay-sensitive traffic, such as voice, to be dequeued from the queuing system and sent before other classes of traffic. The priority queue is also policed to ensure that the fair queues are not starved of bandwidth. Packets that exceed the configured maximum in the PQ are dropped. Although LLQ is most commonly deployed on mixed voice/data networks for voice traffic, other mission-critical traffic can be classified and transmitted from the priority queue.

LLQ offers much more flexibility than previous Frame Relay QoS features, such as Real-Time Protocol (RTP) prioritization and PQ/WFQ for Frame Relay. With RTP prioritization and PQ/WFQ, traffic that matches a specified UDP/RTP port range is considered high priority and allocated to the PQ. LLQ allows the user to define classes of traffic based on protocols, source interfaces, or access lists. Each class of traffic can be assigned characteristics, such as priority, bandwidth, queue-limit, and random-detect (WRED), in a way similar to CBWFQ.

Frame Relay QoS Features Related to LLQ

LLQ for Frame Relay is related to several QoS features for Frame Relay and can be used in conjunction with them. The Frame Relay QoS features related to LLQ are the following:

  • Frame Relay Traffic Shaping To use LLQ for Frame Relay, Frame Relay Traffic Shaping must be enabled on the main interface. FRTS is a prerequisite for LLQ. This is verified in the examples in the later sections of this chapter.

  • RTP Prioritization for Frame Relay The RTP Prioritization for Frame Relay feature provides a strict priority queuing scheme for voice traffic. The voice traffic is identified by its RTP port numbers and classified into a priority queue using the frame-relay ip rtp priority map-class configuration command. When RTP Prioritization is used in conjunction with LLQ, voice traffic that matches the specified range is queued in the LLQ PQ and the interface priority queue.

  • Voice over Frame Relay (VoFR) When VoFR is configured in conjunction with LLQ, it uses the LLQ PQ rather than its own priority queuing mechanism. VoFR is enabled with the frame-relay voice bandwidth map-class configuration command, which sets the total bandwidth made available to VoFR traffic. The vofr data command is supported with LLQ for Frame Relay. When VoFR has no data, all the voice and call control packets are queued in the VC priority queue. For VoFR with data, a FRF.11 PVC can carry both voice and data packets in different subchannels. The FRF.11 data packets are fragmented and interleaved with the voice packets.

  • Frame Relay Fragmentation (FRF.12) Frame Relay Fragmentation (FRF.12) is used to support voice and data packets on lower-speed links without causing excessive delay to the voice packets. When FRF.12 is configured, the smaller voice packets queued in the priority queue are sent unfragmented. Large data packets classified to the priority queue are fragmented when dequeued. This causes the fragmented data packets to be interleaved with the unfragmented voice packets. This interleaving ensures minimum delay for the delay-sensitive voice packets.

  • IP Cisco Express Forwarding (CEF) Switching The IP CEF switching functionality is transparent to LLQ for Frame Relay and is expected to work with LLQ for Frame Relay.

Features Not Supported with LLQ for Frame Relay

In Cisco IOS Release 12.1(2)T, the LLQ for Frame Relay feature is not compatible with certain legacy Frame Relay features. When using LLQ for Frame Relay with an earlier supported Cisco IOS release, please ensure the Frame Relay features listed in this section are not configured together with LLQ. The following Frame Relay features are not supported with LLQ for Frame Relay:

  • Frame Relay switching

  • GTS

  • Traffic shaping commands in MQC CLI

  • Fancy queuing: Frame Relay priority queuing and Frame Relay custom queuing

In addition, any queue other than a FIFO queue that is configured in the Frame Relay map class must be removed. LLQ for Frame Relay cannot be used if there is already a non-FIFO queue configured, except for the default queue created when fragmentation is enabled.

In the next section, a simple scenario illustrates how LLQ can be configured on a Cisco router to support voice and data traffic on a heterogeneous network.

Configuring LLQ for Frame Relay

The LLQ for Frame Relay feature is available in Cisco IOS Release 12.1(2)T or later and is supported on c805, c1600, c1700, c2500, c2600, c3600, c3810, and c7200 series routers. The latest Cisco IOS release might support the LLQ for Frame Relay feature on the newer Cisco router platforms, such as c2600-XM, c3700, and c7600.

The Cisco MQC interface CLI is used to configure LLQ for Frame Relay. To configure LLQ for Frame Relay, the queues are set up on a per-PVC basis. Each VC has a PQ and an assigned number of fair queues. In a manner identical to CBWFQ, LLQ for Frame Relay is configured with a combination of class-map, policy-map, and Frame Relay map-class commands. Traffic classes are set up with the class-map command to classify the traffic. The user determines how the traffic is classified based on protocols, source interfaces, or access lists. Then the policy-map command is used to create a traffic policy whereby the user can configure how each class of traffic is treated in the queuing system. The policies can be based on priority (PQ), bandwidth, queue limit, or WRED. Finally, the policy-map is attached to a Frame Relay VC using the service-policy output command in the Frame Relay map class. The map class is, in turn, assigned to the Frame Relay DLCI.

If you skipped the earlier sections on MQC interface CLI or CBWFQ, reading those sections to become familiarized with the configuration tasks for MQC or CBWFQ is recommended. Otherwise, Figure 18-5 shows the topology of the network that is used to illustrate LLQ for Frame Relay.

Figure 18-5. Network Diagram to Illustrate LLQ for Frame Relay

Figure 18-5 illustrates the scenario of a small firm that has a central office connected to several branch offices across a nationwide Frame Relay network. The firm wishes to leverage on VoIP and multicast to support desktop video conferencing applications on its network. To optimize the application performance for the real-time traffic on the network, the firm needs to manage the network performance with respect to bandwidth, delay, jitters, and packet loss. In addition, the firm needs to service the needs of other applications running over the WAN. Hence, the firm decides to implement LLQ on its Frame Relay network. A strict priority queue is created to minimize delay for the real-time delay-sensitive traffic. LLQ polices the real-time traffic in the strict priority queue and ensures that other nonpriority traffic on the network, such as SNA and sales data transfers, is not starved of bandwidth.

NOTE

The network implementer advised the firm against using oversubscription, because it usually leads to packet discards and might result in poor voice/video quality.

The network in Figure 18-5 is set up, and the configurations of the routers are shown in Example 18-9. Notice that only the configurations of routers R1 and R2 are shown in Example 18-9, because the configurations for R3 or R4 are very similar to those of R2.

Example 18-9. Configurations of the Routers in Figure 18-5
! Router R1:

<output omitted>

class-map match-all SALES_DATA
  match access-group 103
class-map match-any SNA_DATA
  match protocol dlsw
  match access-group 102
class-map match-all VIDEO
  match access-group 101
!
!
policy-map LLQ
  class VIDEO
    priority 64
  class SNA_DATA
   bandwidth 32
   queue-limit 100
  class SALES_DATA
   bandwidth 16
  class class-default
   fair-queue
!
interface FastEthernet0/0
 ip address 10.0.0.1 255.255.255.0
!
interface Serial4/0
 no ip address
 encapsulation frame-relay
 no fair-queue
 frame-relay traffic-shaping
!
interface Serial4/0.102 point-to-point
 ip address 172.16.1.1 255.255.255.252
 frame-relay interface-dlci 102
  class LLQ_class
!
interface Serial4/0.103 point-to-point
 ip address 172.16.1.5 255.255.255.252
 frame-relay interface-dlci 103
  class LLQ_class
!
interface Serial4/0.104 point-to-point
 ip address 172.16.1.9 255.255.255.252
 frame-relay interface-dlci 104
  class LLQ_class
!
!
map-class frame-relay LLQ_class
 frame-relay cir 128000
 frame-relay mincir 128000
 no frame-relay adaptive-shaping
 service-policy output LLQ
!
ip route 20.0.0.0 255.255.255.0 172.16.1.2
ip route 30.0.0.0 255.255.255.0 172.16.1.6
ip route 40.0.0.0 255.255.255.0 172.16.1.10
!
access-list 101 permit udp any any eq 12000
access-list 102 permit tcp any eq 2065 any
access-list 102 permit tcp any any eq 2065
access-list 103 permit tcp host 10.0.0.2 any eq 10000
________________________________________________________________
! Router R2:

<output omitted>

class-map match-all SALES_DATA
  match access-group 103
class-map match-any SNA_DATA
  match protocol dlsw
  match access-group 102
class-map match-all VIDEO
  match access-group 101
!
!
policy-map LLQ
  class VIDEO
    priority 64
  class SNA_DATA
   bandwidth 32
   queue-limit 100
  class SALES_DATA
   bandwidth 16
  class class-default
   fair-queue
!
interface FastEthernet0/0
 ip address 20.0.0.1 255.255.255.0
!
interface Serial2/1
 no ip address
 encapsulation frame-relay
 no fair-queue
 frame-relay traffic-shaping
!
interface Serial2/1.201 point-to-point
 ip address 172.16.1.2 255.255.255.252
 frame-relay interface-dlci 201
  class LLQ_class
!
map-class frame-relay LLQ_class
 frame-relay cir 128000
 frame-relay mincir 128000
 no frame-relay adaptive-shaping
 service-policy output LLQ
!
ip route 10.0.0.0 255.255.255.0 172.16.1.1
ip route 30.0.0.0 255.255.255.0 172.16.1.1
ip route 40.0.0.0 255.255.255.0 172.16.1.1
!
access-list 101 permit udp any any eq 12000
access-list 102 permit tcp any eq 2065 any
access-list 102 permit tcp any any eq 2065
access-list 103 permit tcp host 20.0.0.2 any eq 10000

In the network diagram in Figure 18-5, each remote site has a Frame Relay VC with a minimum access speed of 128 kbps terminating into the central location. To prevent oversubscription, Frame Relay Traffic Shaping is enabled, and the routers are allowed to burst only up to the CIR rate. Hence, both the minimum CIR and the CIR are set to 128 kbps in Example 18-9.

Although bursting over Frame Relay can be attractive for data networks, it might not be desirable on integrated voice and data networks because voice packets might be dropped. A discarded voice packet can result in retransmission and cause jitter and result in poor voice quality. This can also cause slow response to the user desktop application.

The various traffic classes are defined with the class-map commands. The traffic is classified to the class-map by means of protocol types, input interfaces, or access lists. For instance, in Example 18-9, the traffic destined for the priority queue is classified with an extended access list 101 that matches UDP traffic with port number 12000. Then the CBWFQ scheme is used to serve both the SNA and sales data traffic on the network. All the remaining traffic not matched by the priority class map or the CBWFQ class maps are sent to the default class.

A policy-map named LLQ is configured to define how each identified class of traffic is handled in the traffic policy. A priority queue with a bandwidth of 64 kbps is used to service desktop video conferencing traffic running on UDP port 12000. The SNA and sales data are assigned a bandwidth of 32 kbps and 16 kbps, respectively. Traffic in the default class is serviced based on best-effort delivery using a flow-based fair queuing scheme.

The next section verifies the workings of the LLQ system by observing the outputs of the various show commands.


Monitoring and Troubleshooting LLQ for Frame Relay

After the routers are configured, four different streams of traffic from the applications are transmitted over the network. The traffic information is recorded in Table 18-3.

Table 18-3. Traffic Information for Figure 18-5 Received by R1

Traffic Streams

Allocated Bandwidth

Actual Amount of Traffic Sent

Stream 1 (UDP port 12000)

64 kbps

85 kbps

Stream 2 (TCP port 2065)

32 kbps

34 kbps

Stream 3 (IP source address 10.0.0.2)

16 kbps

18 kbps

Stream 4 (IP traffic with source 10.0.0.3)

16 kbps if Stream 1 and Stream 2 are sticking to their assigned bandwidth

16 kbps

Total Bandwidth

128 kbps

Approximately 153 kbps

In Table 18-3, the actual amount of traffic sent over the network is set to be slightly higher than the allowed CIR value. The main objective is to verify that when congestion arises, delay-sensitive traffic in the priority queue is allocated its reserved bandwidth and receives the service required. Moreover, observe that the LLQ system, unlike priority queue, does not starve the other traffic of the bandwidth required. CBWFQ ensures that the other classes of traffic are serviced.

The show frame-relay pvc DLCI command can be used to display information related to the per-VC queuing strategy configured on the DLCI, including LLQ. Example 18-10 shows the output of show frame-relay pvc command at router R1 after the traffic has been sent onto the network for approximately 5 minutes.

Example 18-10. Output of show frame-relay pvc at Router R1
R1#show frame-relay pvc 102

PVC Statistics for interface Serial4/0 (Frame Relay DTE)

DLCI = 102, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial4/0.102

  input pkts 6809          output pkts 612865       in bytes 423873
  out bytes 64024285       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 57        out bcast bytes 19893
  pvc create time 04:07:13, last time pvc status changed 04:06:53
  cir 128000    bc 128000    be 0         byte limit 2000   interval 125
  mincir 128000    byte increment 2000  Adaptive Shaping none
  pkts 498627    bytes 54344821  pkts delayed 498627    bytes delayed 54344821
  shaping active
  traffic shaping drops 114134
  service policy LLQ

  Service-policy output: LLQ (2367)

    Class-map: VIDEO (match-all) (2369/2)
      339456 packets, 36661248 bytes
5 minute offered rate 86000 bps, drop rate 22000 bps
      Match: access-group 101 (2373)
     Weighted Fair Queueing
       Strict Priority
       Output Queue: Conversation 24
       Bandwidth 64 (kbps) Burst 1600 (Bytes)
       (pkts matched/bytes matched) 342270/36965160
       (total drops/bytes drops) 88739/9583812

    Class-map: SNA_DATA (match-any) (2377/3)
      136583 packets, 14750964 bytes
      5 minute offered rate 34000 bps, drop rate 0 bps
      Match: protocol dlsw (2381)
        0 packets, 0 bytes
        5 minute rate 0 bps
      Match: access-group 102 (2385)
        136583 packets, 14750964 bytes
        5 minute rate 34000 bps
     Weighted Fair Queueing
       Output Queue: Conversation 25
       Bandwidth 32 (kbps) Max Threshold 100 (packets)
       (pkts matched/bytes matched) 136908/14786064
        (depth/total drops/no-buffer drops) 0/0/0

    Class-map: SALES_DATA (match-all) (2389/4)
      68492 packets, 8219040 bytes
      5 minute offered rate 19000 bps, drop rate 0 bps
      Match: access-group 103 (2393)
     Weighted Fair Queueing
       Output Queue: Conversation 26
       Bandwidth 16 (kbps) Max Threshold 64 (packets)
       (pkts matched/bytes matched) 68631/8235720
        (depth/total drops/no-buffer drops) 0/0/0

    Class-map: class-default (match-any) (2397/0)
      68606 packets, 6888986 bytes
      5 minute offered rate 16000 bps, drop rate 5000 bps
      Match: any  (2401)
     Weighted Fair Queueing
       Flow Based Fair Queueing
       Maximum Number of Hashed Queues 16
        (total queued/total drops/no-buffer drops)
                       64/26091/0
Output queue size 65/max total 600/drops 115060

Example 18-10 showed the output rate and other detailed information of each queue, as expected of LLQ.

In the output, the VIDEO class shows the average output rate to be approximately 86000 bps with a constant drop rate of 22000 bps. Hence, the aggregate output of the priority queue is 64000 bps, as reserved in the priority command in the VIDEO class-map. When congestion occurs and the other CBWFQ queues are fully using their allocated bandwidth, the priority queue is policed, and any excess packets exceeding the reserved bandwidth are dropped. For the SNA_DATA and SALES_DATA data queues, although 32 kbps and 16 kbps are allocated in the class-map, traffic from these classes can use up more than the allocated bandwidth, if it is available.

As seen from the output, bandwidth implicitly available to the default class is now used by traffic from the SNA_DATA and SALES_DATA classes. Around 5 kbps of bandwidth is "squeezed" from the default class, which is the cause of the constant 5 kbps of packet drop in the class-default class. To ensure traffic from the default class is guaranteed service, replace the fair-queue command with the bandwidth kbps command in the class-map for class-default.

Example 18-11 displays the output of the show interface command at router R1, which shows that the aggregate output rate is rate-limited by Frame Relay Traffic Shaping at approximately 128000 bps.

Example 18-11. Output of show interface Command at R1
R1#show interface serial4/0
Serial4/0 is up, line protocol is up
  Hardware is M4T
  MTU 1500 bytes, BW 128000 Kbit, DLY 20000 usec,
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation FRAME-RELAY, crc 16, loopback not set
  Keepalive set (10 sec)
  LMI enq sent  502, LMI stat recvd 502, LMI upd recvd 0, DTE LMI up
  LMI enq recvd 0, LMI stat sent  0, LMI upd sent  0
  LMI DLCI 1023  LMI type is CISCO  frame relay DTE
  FR SVC disabled, LAPF state down
  Broadcast queue 0/64, broadcasts sent/dropped 251/0, interface broadcasts 0
  Last input 00:00:00, output 00:00:00, output hang never
  Last clearing of "show interface" counters 01:23:31
  Queueing strategy: fifo
  Output queue 40/40, 187539 drops; input queue 0/75, 0 drops
  5 minute input rate 0 bits/sec, 2 packets/sec
  5 minute output rate 124000 bits/sec, 142 packets/sec
     10611 packets input, 657839 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
     715526 packets output, 78013049 bytes, 0 underruns
     0 output errors, 0 collisions, 0 interface resets
     0 output buffer failures, 0 output buffers swapped out
     0 carrier transitions     DCD=up  DSR=up  DTR=up  RTS=up  CTS=up

The output queue at the interface is seeing packet drops because the LLQ at the Frame Relay PVC level is experiencing congestion.

The subsequent examples exemplify that when the priority queue is not transmitting, the bandwidth allocated in the priority queue can be freed up for traffic from the other CBWFQ queues.

Example 18-12 shows the output of the show frame-relay pvc command at R1 after traffic comprising the priority queue from stream 1 is reduced. Traffic from the remaining queues is still being sent at the same rate as before.

Example 18-12. Output of show frame-relay pvc at Router R1 After High-Priority Traffic Is Reduced
R1#show frame-relay pvc 102

PVC Statistics for interface Serial4/0 (Frame Relay DTE)

DLCI = 102, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial4/0.102

  input pkts 10506         output pkts 941786       in bytes 654032
  out bytes 98387187       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 87        out bcast bytes 30363
  pvc create time 04:38:01, last time pvc status changed 04:37:41
  cir 128000    bc 128000    be 0         byte limit 2000   interval 125
  mincir 128000    byte increment 2000  Adaptive Shaping none
  pkts 766874    bytes 83579919  pkts delayed 764061    bytes delayed 83273311
  shaping inactive
  traffic shaping drops 174828
  service policy LLQ

  Service-policy output: LLQ (2367)

    Class-map: VIDEO (match-all) (2369/2)
      521479 packets, 56319732 bytes
      5 minute offered rate 74000 bps, drop rate 16000 bps
      Match: access-group 101 (2373)
     Weighted Fair Queueing
       Strict Priority
       Output Queue: Conversation 24
       Bandwidth 64 (kbps) Burst 1600 (Bytes)
       (pkts matched/bytes matched) 521479/56319732
       (total drops/bytes drops) 135203/14601924

    Class-map: SNA_DATA (match-any) (2377/3)
      210146 packets, 22695768 bytes
      5 minute offered rate 34000 bps, drop rate 0 bps
      Match: protocol dlsw (2381)
        0 packets, 0 bytes
        5 minute rate 0 bps
      Match: access-group 102 (2385)
        210146 packets, 22695768 bytes
        5 minute rate 34000 bps
     Weighted Fair Queueing
       Output Queue: Conversation 25
       Bandwidth 32 (kbps) Max Threshold 100 (packets)
       (pkts matched/bytes matched) 208629/22531932
        (depth/total drops/no-buffer drops) 0/0/0

    Class-map: SALES_DATA (match-all) (2389/4)
      105474 packets, 12656880 bytes
      5 minute offered rate 19000 bps, drop rate 0 bps
      Match: access-group 103 (2393)
     Weighted Fair Queueing
       Output Queue: Conversation 26
       Bandwidth 16 (kbps) Max Threshold 64 (packets)
       (pkts matched/bytes matched) 104315/12517800
        (depth/total drops/no-buffer drops) 0/0/0

    Class-map: class-default (match-any) (2397/0)
      105650 packets, 10608824 bytes
      5 minute offered rate 16000 bps, drop rate 0 bps
      Match: any  (2401)
     Weighted Fair Queueing
       Flow Based Fair Queueing
       Maximum Number of Hashed Queues 16
        (total queued/total drops/no-buffer drops)
                       0/39625/0
  Output queue size 0/max total 600/drops 174828

As shown in Example 18-12, as the traffic rate in the priority queue is gradually reduced, there are no longer any packets dropped in the class-default queue. As such, when the priority queue is not transmitting, traffic from the other CBWFQ queues can use up the free bandwidth.

Example 18-13 shows the output of the same show frame-relay pvc command at router R1 after all the high-priority traffic is stopped.

Example 18-13. Output of the show frame-relay pvc at Router R1 After High-Priority Traffic Is Stopped
R1#show frame-relay pvc 102

PVC Statistics for interface Serial4/0 (Frame Relay DTE)

DLCI = 102, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial4/0.102

  input pkts 11370         output pkts 976038       in bytes 707755
  out bytes 101985354      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 94        out bcast bytes 32806
  pvc create time 04:45:10, last time pvc status changed 04:44:50
  cir 128000    bc 128000    be 0         byte limit 2000   interval 125
  mincir 128000    byte increment 2000  Adaptive Shaping none
  pkts 801172    bytes 87320090  pkts delayed 764061    bytes delayed 83273311
  shaping inactive
  traffic shaping drops 174828
  service policy LLQ

  Service-policy output: LLQ (2367)

    Class-map: VIDEO (match-all) (2369/2)
      521479 packets, 56319732 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: access-group 101 (2373)
     Weighted Fair Queueing
       Strict Priority
       Output Queue: Conversation 24
       Bandwidth 64 (kbps) Burst 1600 (Bytes)
       (pkts matched/bytes matched) 521479/56319732
       (total drops/bytes drops) 135203/14601924

    Class-map: SNA_DATA (match-any) (2377/3)
      227749 packets, 24596892 bytes
      5 minute offered rate 34000 bps, drop rate 0 bps
      Match: protocol dlsw (2381)
        0 packets, 0 bytes
        5 minute rate 0 bps
      Match: access-group 102 (2385)
        227749 packets, 24596892 bytes
        5 minute rate 34000 bps
     Weighted Fair Queueing
       Output Queue: Conversation 25
       Bandwidth 32 (kbps) Max Threshold 100 (packets)
       (pkts matched/bytes matched) 208629/22531932
        (depth/total drops/no-buffer drops) 0/0/0
    Class-map: SALES_DATA (match-all) (2389/4)
      114275 packets, 13713000 bytes
      5 minute offered rate 19000 bps, drop rate 0 bps
      Match: access-group 103 (2393)
     Weighted Fair Queueing
       Output Queue: Conversation 26
       Bandwidth 16 (kbps) Max Threshold 64 (packets)
       (pkts matched/bytes matched) 104315/12517800
        (depth/total drops/no-buffer drops) 0/0/0

    Class-map: class-default (match-any) (2397/0)
      114465 packets, 11493810 bytes
      5 minute offered rate 16000 bps, drop rate 0 bps
      Match: any  (2401)
     Weighted Fair Queueing
       Flow Based Fair Queueing
       Maximum Number of Hashed Queues 16
        (total queued/total drops/no-buffer drops)
                       0/39625/0
  Output queue size 0/max total 600/drops 174828

In Example 18-14, the opposite condition is verified. When the CBWFQ queues are not using up their allocated bandwidth, traffic from a congested priority queue can use up the free bandwidth. The high-priority traffic is resent onto the network and the traffic rate from streams 2, 3, and 4 are reduced. Example 18-14 displays the output of the show frame-relay pvc command at router R1, which shows that the priority queue is now using up the freed bandwidth from the CBWFQ queues.

Example 18-14. High-Priority Queue Traffic Using Up Bandwidth Freed from the CBWFQ Queues
R1#show frame-relay pvc 102

PVC Statistics for interface Serial4/0 (Frame Relay DTE)

DLCI = 102, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial4/0.102

  input pkts 13083         output pkts 1099572      in bytes 814301
  out bytes 114906617      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 109       out bcast bytes 38041
  pvc create time 04:59:25, last time pvc status changed 04:59:05
  cir 128000    bc 128000    be 0         byte limit 2000   interval 125
  mincir 128000    byte increment 2000  Adaptive Shaping none
  pkts 915475    bytes 99738465  pkts delayed 843271    bytes delayed 91875437
  shaping inactive
  traffic shaping drops 184066
  service policy LLQ

  Service-policy output: LLQ (2367)

    Class-map: VIDEO (match-all) (2369/2)
      594934 packets, 64252872 bytes
      5 minute offered rate 86000 bps, drop rate 0 bps
      Match: access-group 101 (2373)
     Weighted Fair Queueing
       Strict Priority
       Output Queue: Conversation 24
       Bandwidth 64 (kbps) Burst 1600 (Bytes)
       (pkts matched/bytes matched) 576248/62234784
       (total drops/bytes drops) 144441/15599628

    Class-map: SNA_DATA (match-any) (2377/3)
      251232 packets, 27133056 bytes
      5 minute offered rate 8000 bps, drop rate 0 bps
      Match: protocol dlsw (2381)
        0 packets, 0 bytes
        5 minute rate 0 bps
      Match: access-group 102 (2385)
        251232 packets, 27133056 bytes
        5 minute rate 8000 bps
     Weighted Fair Queueing
       Output Queue: Conversation 25
       Bandwidth 32 (kbps) Max Threshold 100 (packets)
       (pkts matched/bytes matched) 225005/24300540
        (depth/total drops/no-buffer drops) 0/0/0

    Class-map: SALES_DATA (match-all) (2389/4)
      127770 packets, 15332400 bytes
      5 minute offered rate 9000 bps, drop rate 0 bps
      Match: access-group 103 (2393)
     Weighted Fair Queueing
       Output Queue: Conversation 26
       Bandwidth 16 (kbps) Max Threshold 64 (packets)
       (pkts matched/bytes matched) 113484/13618080
        (depth/total drops/no-buffer drops) 0/0/0

    Class-map: class-default (match-any) (2397/0)
      126029 packets, 12657182 bytes
      5 minute offered rate 4000 bps, drop rate 0 bps
      Match: any  (2401)
     Weighted Fair Queueing
       Flow Based Fair Queueing
       Maximum Number of Hashed Queues 16
        (total queued/total drops/no-buffer drops)
                       0/39625/0
  Output queue size 0/max total 600/drops 184066

As observed in Example 18-14, the traffic from the priority queue is now using up bandwidth freed from the CBWFQ queues. Note that although only 64 kbps of bandwidth is reserved for the priority queue, it is now sending at a rate higher than 64 kbps because the other CBWFQ queues are not transmitting at their maximum potential.

FRTS is a prerequisite for employing the LLQ system on a Frame Relay VC. If FRTS is unconfigured at the main interface after LLQ has been enabled on a Frame Relay DLCI, the service policy is removed. Example 18-15 shows this condition.

Example 18-15. Removing FRTS After LLQ Is Configured
R1#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
R1(config)#interface Serial4/0
R1(config-if)#no frame-relay traffic-shaping
R1(config-if)#exit
R1#show frame-relay pvc 102

PVC Statistics for interface Serial4/0 (Frame Relay DTE)

DLCI = 102, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial4/0.102

  input pkts 13284         output pkts 1112074      in bytes 826899
  out bytes 116215070      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 110       out bcast bytes 38390
  pvc create time 05:01:04, last time pvc status changed 05:00:44

<-- The service policy is now removed!

The show policy-map interface command can be used to display or verify information regarding the LLQ traffic policy attached to an interface. This is shown in Example 18-16.

Example 18-16. Output of show policy-map interface at Router R1
R1#show policy-map interface Serials4/0.102
 Serial4/0.102: DLCI 102 -

  Service-policy output: LLQ (2411)

    Class-map: VIDEO (match-all) (2413/2)
      36349 packets, 3925692 bytes
      5 minute offered rate 86000 bps, drop rate 0 bps
      Match: access-group 101 (2417)
      Weighted Fair Queueing
        Strict Priority
        Output Queue: Conversation 24
        Bandwidth 64 (kbps) Burst 1600 (Bytes)
        (pkts matched/bytes matched) 1/108
        (total drops/bytes drops) 0/0

    Class-map: SNA_DATA (match-any) (2421/3)
      3635 packets, 392580 bytes
      5 minute offered rate 8000 bps, drop rate 0 bps
      Match: protocol dlsw (2425)
        0 packets, 0 bytes
        5 minute rate 0 bps
      Match: access-group 102 (2429)
        3635 packets, 392580 bytes
        5 minute rate 8000 bps
      Weighted Fair Queueing
        Output Queue: Conversation 25
        Bandwidth 32 (kbps) Max Threshold 100 (packets)
        (pkts matched/bytes matched) 0/0
        (depth/total drops/no-buffer drops) 0/0/0

    Class-map: SALES_DATA (match-all) (2433/4)
      3635 packets, 436200 bytes
      5 minute offered rate 9000 bps, drop rate 0 bps
      Match: access-group 103 (2437)
      Weighted Fair Queueing
        Output Queue: Conversation 26
        Bandwidth 16 (kbps) Max Threshold 64 (packets)
        (pkts matched/bytes matched) 0/0
        (depth/total drops/no-buffer drops) 0/0/0
    Class-map: class-default (match-any) (2441/0)
      1830 packets, 185988 bytes
      5 minute offered rate 4000 bps, drop rate 0 bps
      Match: any  (2445)
      Weighted Fair Queueing
        Flow Based Fair Queueing
        Maximum Number of Hashed Queues 16
        (total queued/total drops/no-buffer drops)
                       0/0/0


Summary

This chapter introduced readers to the MQC in the Cisco IOS software, which provides users with a comprehensive, standardized, and modular framework to deploy QoS policies on the network. This chapter also demonstrated the configuration steps involved with MQC with practical configuration examples.

Two advanced QoS features for queuing on Frame Relay networks were also introduced: CBWFQ for Frame Relay and LLQ for Frame Relay (also commonly known as PQ/CBWFQ). The advanced Frame Relay queuing features allow users to effectively manage network performance with respects to bandwidth, delay, jitters, and packet loss. Example scenarios demonstrated the functions of the CBWFQ and LLQ features on a Frame Relay network. Then the chapter showed readers the configuration steps required to configure the CBWFQ and LLQ features for Frame Relay on a Cisco router. Finally, this chapter explained the Cisco IOS show commands useful for monitoring and maintaining CBWFQ and LLQ configurations for Frame Relay on a Cisco router.

The next chapter covers the Frame Relay Interface Queuing and Fragmentation feature, an advanced QoS feature for queuing on Frame Relay networks.


Review Questions

1: | Describe the use of Cisco's MQC configuration.
2: | How do CBWFQ and WFQ compare?
3: | How do LLQ and CBWFQ compare?
4: | Describe the role of the priority queue in LLQ.
5: | Describe the mechanism of LLQ for Frame Relay.


References

  • Cisco 12.0(5)T Documentation, Class-Based Weighted Fair Queuing: http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/120newft/120t/120t5/cbwfq.htm

  • Cisco IOS Release 12.1(2)T Documentation, Low Latency Queuing for Frame Relay: http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121newft/121t/121t2/dtfrpqfq.htm

  • Cisco IOS Release 12.2 Quality of Service Solution Guide: http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/fqos_c/fqcprt8/index.htm


Chapter 19. Frame Relay Queuing and Fragmentation at the Interface

The previous chapters described the quality of service (QoS) features related to queuing for Frame Relay services. This chapter describes in detail the Frame Relay Queuing and Fragmentation at the Interface feature. This new feature allows Low Latency Queuing (LLQ) for Frame Relay (see Chapter 18, "Frame Relay Class-Based Weighted Fair Queuing (CBWFQ) and Low Latency Queuing (LLQ)") and Frame Relay FRF.12 End-to-End Fragmentation (see Chapter 16, "Frame Relay Fragmentation") to be supported at the Frame Relay main interface level.

This chapter begins with an overview of the components supported by the Frame Relay Queuing and Fragmentation at the Interface feature. It then discusses the benefits the Frame Relay Queuing and Fragmentation at the Interface feature provides over LLQ for Frame Relay and Frame Relay FRF.12 End-to-End Fragmentation. These are QoS features for Frame Relay supported only at the PVC level. This chapter then provides configuration examples using practical scenarios to illustrate how to deploy Frame Relay Queuing and Fragmentation at the Interface and to demonstrate the configuration tasks involved in configuring the feature on a Cisco router. Finally, this chapter explains the relevant Cisco IOS show and debug commands for monitoring and maintaining Frame Relay Queuing and Fragmentation at the Interface configurations on Cisco routers.

The topics and questions that this chapter addresses include the following:

  • Overview of Frame Relay Queuing and Fragmentation at the Interface feature

  • Differences between Frame Relay Queuing and Fragmentation at the Interface and LLQ for Frame Relay and Frame Relay FRF.12 End-to-End Fragmentation at the PVC level

  • Configuring the Frame Relay Queuing and Fragmentation at the Interface feature on a Cisco router

  • Applying the Frame Relay Queuing and Fragmentation at the Interface feature in a scenario example

  • Monitoring and maintaining Frame Relay Queuing and Fragmentation at the Interface configurations with Cisco IOS show and debug commands on Cisco routers

After completing this chapter, readers will recognize the benefits of the Frame Relay Queuing and Fragmentation at the Interface feature. The main benefit of the feature is providing customers and users with a simplified configuration to deploy LLQ and Frame Relay FRF.12 to a group of Frame Relay PVCs created on the main interface and subinterfaces. Readers will also become familiar with the configuration tasks and commands involved in setting up the Frame Relay Queuing and Fragmentation at the Interface feature on the main interface. Readers will become familiar with the relevant Cisco IOS show and debug commands for monitoring and maintaining the Frame Relay Queuing and Fragmentation at the Interface feature on Cisco routers.


Overview of Frame Relay Queuing and Fragmentation at the Interface

This section discusses the benefits of the Frame Relay Queuing and Fragmentation at the Interface feature. The Frame Relay Queuing and Fragmentation at the Interface feature provides customers and users with a simplified configuration for supporting LLQ, Frame Relay FRF.12 End-to-End Fragmentation, and subrate shaping on a group of Frame Relay PVCs created on the main interface or logical subinterfaces. In addition, the Frame Relay Queuing and Fragmentation at the Interface feature offers flexible bandwidth allocation to the traffic. It provides a subrate shaping function to shape user traffic up to the configured interface shaping rate.

Simplified Configuration for LLQ

Before the release of the Frame Relay Queuing and Fragmentation at the Interface feature, every Frame Relay PVC that required LLQ or FRF.12 Fragmentation had to have an LLQ service policy or FRF.12 configurations configured in a Frame Relay map class and applied to each individual Frame Relay PVC. The new feature presents a simplified way of supporting queuing and fragmentation. It allows a single queuing and fragmentation policy configured on the Frame Relay main interface to be applied to all Frame Relay PVCs created on that main interface and its subinterfaces.

As a result, the new Frame Relay Queuing and Fragmentation at the Interface feature allows LLQ and FRF.12 to be collectively configured at the Frame Relay interface level. This eliminates the requirement to configure a low-latency service policy on each Frame Relay PVC individually. Effectively, the Frame Relay Queuing and Fragmentation at the Interface feature enhances the scalability of the LLQ and FRF.12 features by significantly reducing the configuration complexities involved, especially when either LLQ or FRF.12 needs to be provisioned on a large number of Frame Relay DLCIs created under the main interface. In addition to supporting LLQ and FRF.12 on the main Frame Relay interface, a subrate shaper is used to manage output traffic rate on the main interface.

Frame Relay Queuing at the Interface

When an LLQ policy map is applied to the interface, traffic through the interface is identified via class maps and is directed to either the priority queue or the class-default queue. Delay-sensitive traffic, such as voice, should be classified as high priority by the class maps and queued on the priority queue. The remaining traffic that does not meet the classifications of the high-priority queue is queued on the class-default queue. Together, the frames from both high-priority and class-default queues are subjected to fragmentation and interleaving at the interface. Frames that exceed the configured fragment size for FRF.12 End-to-End fragmentation at the interface are fragmented.

FRF.12 End-to-End Fragmentation at the Interface

As part of this new feature, FRF.12 End-to-End Fragmentation can now be configured at the Frame Relay main interface level. When FRF.12 End-to-End Fragmentation is enabled on an interface with a user-defined fragment size, all PVCs on the main interface and its subinterfaces have FRF.12 End-to-End Fragmentation enabled with the same configured fragment size. To maintain low latency and low jitters for high-priority traffic, you are recommended to configure the fragment size to be greater than the largest high-priority frame that is expected. In this way, the high-priority frames are not fragmented. They are interleaved with the fragmented frames from the class-default queue to achieve the highest level of QoS transmission for high-priority traffic.

NOTE

Local Management Interface (LMI) frames are required for network management on the Frame Relay network. LMI frames are not fragmented and are therefore guaranteed delivery.

Interleaving of Frames for Transmission

The Frame Relay Queuing and Fragmentation at the Interface feature enables nonfragmented high-priority frames to be interleaved together with fragmented low-priority frames for transmission. For interleaving of frames to work properly, some conditions have to be met. First of all, both interface level LLQ policy and FRF.12 Fragmentation must be configured. Next, the subrate shaping at the interface level must be turned off. Finally, for interleaving to work efficiently, the chosen fragment size should be greater than the largest high-priority frame. This is to ensure that the high-priority frames are not fragmented and delayed behind the fragmented data frames. Figure 19-1 illustrates the Frame Relay Queuing and Fragmentation at the Interface and interleaving process.

Figure 19-1. How Frame Relay Queuing and Fragmentation at the Interface Works

Subrate Shaping at the Interface

The Frame Relay Queuing and Fragmentation at the Interface feature supports a subrate shaper to limit the burst of traffic up to the physical interface line rate or the aggregate throughput governed by the interface shaping rate. If shaping is not configured, each Frame Relay PVC can send bursts up to the physical interface line rate. In addition, notice in Example 19-1 and Example 19-2 that Frame Relay fragmentation at the interface level cannot be supported together with the legacy Frame Relay Traffic Shaping feature.

Example 19-1. Interface-Level Fragmentation Cannot Be Enabled if FRTS Has Been Configured on the Interface
Router#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router(config)#interface serial2/1
Router(config-if)#encapsulation frame-relay
Router(config-if)#frame-relay traffic-shaping
Router(config-if)#frame-relay fragment 100 end-to-end
Interface fragmentation can not be enabled while FRTS is configured.

Example 19-2. FRTS Cannot Be Enabled if Interface-Level Fragmentation Has Been Configured on the Interface
Router(config)#interface serial2/1
Router(config-if)#encapsulation frame-relay
Router(config-if)#frame-relay fragment 100 end-to-end
Router(config-if)#frame-relay traffic-shaping
Disable interface level end-to-end fragmentation first.

To support the new feature, a subrate shaper is used at the interface. When shaping is configured at the interface and the traffic rate exceeds the configured shaping rate, the traffic is queued at the shaping layer using fair queuing. At the interface level, the frames are queued using the configured queuing strategy or the default queuing method for the interface.

When subrate shaping is configured, interleaving of high-priority frames does not work. To use interleaving, subrate shaping must be disabled. When subrate shaping is not used, each Frame Relay PVC under the main interface or its subinterfaces is permitted to burst up to the physical line rate of the interface.

In all, the Frame Relay Queuing and Fragmentation at the Interface feature provides queuing, fragmentation, and shaping functionalities at the Frame Relay interface. This provides the benefit of a simple configuration for LLQ and fragmentation by applying a joint QoS policy to all Frame Relay PVCs under the main interface and its subinterfaces. With Frame Relay Queuing and Fragmentation at the Interface, users no longer need to configure QoS on each Frame Relay PVC individually. What is more, the Frame Relay Queuing and Fragmentation at the Interface feature avoids bandwidth partitioning between Frame Relay PVCs while preserving the logical separation of traffic classes on the Frame Relay PVCs.

Related Functionality

The Frame Relay Queuing and Fragmentation at the Interface feature supports the following features:

  • Frame Relay fragmentation with hardware compression

  • Frame Relay payload compression

  • IP header compression

  • Voice over Frame Relay (VoFR)

  • Weighted Random Early Detection (WRED)

In general, the Frame Relay compression features greatly reduce network overhead and help customers to maximize their network throughputs and efficiency over low-bandwidth links. Frame Relay Queuing and Fragmentation at the Interface level supports hardware-assisted compression. Hardware-based compression offloads computationally intensive compression calculations from the routers' CPUs. This helps to free up critical resources on the router to allow it to support other features and functionalities. Frame Relay compression is covered in Chapter 15, "Compression over Frame Relay."

VoFR allows a router to carry voice traffic, such as telephone calls and faxes, over a Frame Relay network. VoFR is covered extensively in Cisco Press's book Cisco Voice over Frame Relay, ATM, and IP by Stephen McQuerry, Kelly McGrew, and Stephen Foy (2001, ISBN: 1578702275). WRED provides a congestion avoidance mechanism for TCP by randomly dropping packets before periods of high congestion. WRED is covered in Chapter 21, "Weighted Random Early Detection (WRED) for Frame Relay."

Nonsupported Functionality

The following are not supported by the Frame Relay Queuing and Fragmentation at the Interface feature:

  • Frame Relay Traffic Shaping with interface fragmentation

  • Frame Relay class-based fragmentation with interface fragmentation

  • Frame Relay switched virtual circuits (SVCs)

  • Hierarchical shaping and multiple shapers

Configuring Frame Relay Queuing and Fragmentation at the Interface

This section describes the tasks required to configure the Frame Relay Queuing and Fragmentation at the Interface feature on a Cisco router.

NOTE

The Frame Relay Queuing and Fragmentation at the Interface feature was released in Cisco IOS Release 12.2(13)T.

]To configure the Frame Relay Queuing and Fragmentation at the Interface feature on a Cisco router, perform the following configuration steps:

Step 1. | Define traffic classifications by creating a class-map with the class-map class-name global configuration command. The class-map is needed to classify traffic to their respective queues. The characteristics of the class are determined by the match criteria configured in the class-map. Refer to the Modular Quality of Service Command Line Interface (MQC) configurations in Chapter 18 on how to set up a class-map for traffic classifications.
Step 2. | Set up a policy map with the policy-map policy-map global configuration command. In the policy-map created, specify the name of class to be associated with the strict priority queue and the amount of bandwidth, in kbps, to be assigned to the class. This is configured with the priority bandwidth-kbps policy-map-class configuration command.
Step 3. | (optional) In the policy-map created, specify the name of the class to be associated with the bandwidth queues and specify the amount of bandwidth, in kbps, to be assigned to the class. This is configured with the bandwidth bandwidth-kps policy-map-class configuration command. Take note that by default, the sum of all bandwidth allocation on an interface cannot exceed 75 percent of the total available interface bandwidth. However, this can be overridden by the max-reserved-bandwidth command.
Step 4. | (optional) To configure shaping in addition to queuing on the Frame Relay interface, use the predefined class-default class to configure the shaping policy. The shaping policy configured in the class-default class acts as the parent policy, and all traffic for the entire interface is shaped. The shape [average | peak] mean-rate [[burst-size] [excess-burst-size]] policy-map-class configuration command is used to define the shaping policy.
Step 5. | After the overall LLQ service policy is defined in the earlier steps, enter the interface configuration mode of the Frame Relay interface and configure Frame Relay encapsulation with the encapsulation frame-relay interface configuration command. Next, apply the LLQ service-policy to the interface with service-policy output policy-map-name interface configuration command. Finally, enable FRF.12 End-to-End Fragmentation on the interface with the frame-relay fragment fragment-size end-to-end interface configuration command.

NOTE

Before this feature, FRF.12 could only be configured in a Frame Relay map class.

NOTE

The class-default class is meant for classifying traffic that does not fall into one of the user-defined classes. Although the class-default class is predefined when the policy map is created, it should be configured. Otherwise, traffic that does not match any of the user-defined classes is only given best-effort treatment. As mentioned, when configuring the shaping policy for the LLQ service-policy, use the class-default class.

Example of Frame Relay Queuing and Fragmentation at the Interface

This section uses the Frame Relay network exemplified in Figure 19-2 to explain Frame Relay Queuing and Fragmentation at the Interface and to describe the feature in action with configuration examples.

Figure 19-2. Implementing Frame Relay Queuing and Fragmentation at the Interface

[View full size image]

The Open Shortest Path First (OSPF) dynamic routing protocol is chosen to disseminate network layer routing information between the sites on the Frame Relay network, as shown in the next figure. Figure 19-3 shows the OSPF information of the network.

Figure 19-3. Routing Information of the Frame Relay Network

The configuration examples of the routers in Figure 19-2 (and Figure 19-3) are shown in Example 19-3.

Example 19-3. Configuration Examples of Routers R1, R2, and R3 in Figure 19-2
! Router R1:

<output-omitted>

class-map match-all video
  match access-group 101
!
!
policy-map llq
  class video
    priority 64
  class class-default
   fair-queue
!
interface Ethernet1/2
 ip address 192.168.1.1 255.255.255.0
!
!
interface Serial2/0
 bandwidth 128
 no ip address
 encapsulation frame-relay
 service-policy output llq
 frame-relay fragment 120 end-to-end
!
interface Serial2/0.102 point-to-point
 ip address 172.16.1.1 255.255.255.252
 frame-relay interface-dlci 102
!
interface Serial2/0.103 point-to-point
 ip address 172.16.1.5 255.255.255.252
 frame-relay interface-dlci 103
!
router ospf 1
 network 172.16.1.0 0.0.0.3 area 0
 network 172.16.1.4 0.0.0.3 area 0
 network 192.168.1.0 0.0.0.255 area 1
!
!
access-list 101 permit udp any any eq 16480
________________________________________________________________
! Router R2:

<output-omitted>

interface Ethernet0/2
 ip address 10.0.0.1 255.255.255.0
!
interface Serial1/1
 no ip address
 encapsulation frame-relay
 frame-relay fragment 120 end-to-end
!
interface Serial1/1.201 point-to-point
 ip address 172.16.1.2 255.255.255.252
 frame-relay interface-dlci 201
!
router ospf 1
 network 10.0.0.0 0.0.0.255 area 2
 network 172.16.1.0 0.0.0.3 area 0
________________________________________________________________
! Router R3:

interface Ethernet1
 ip address 20.0.0.1 255.255.255.0
!
interface Serial0
 no ip address
 encapsulation frame-relay
 frame-relay fragment 120 end-to-end
!
interface Serial0.301 point-to-point
 ip address 172.16.1.6 255.255.255.252
 frame-relay interface-dlci 301
!
router ospf 1
 network 20.0.0.0 0.0.0.255 area 3
 network 172.16.1.4 0.0.0.3 area 0

In the scenario described in this example, a small entertainment company operating a Frame Relay network wants to use LLQ to ensure the highest level of QoS for its voice and video traffic running between the central site and its remote offices. However, it does not wish to reconfigure every Frame Relay PVC provisioned at its central router whenever new sites are added to its network. Using the Frame Relay Queuing and Fragmentation at the Interface feature, a single LLQ policy can be created to apply QoS policies to all PVCs created under that main interface. FRF.12 End-to-End Fragmentation can be added to fragment the larger data packets that are transmitted out of that same interface. In this way, the fragmented data packets can be interleaved with the high-priority packets to reduce latency for the data packets as well during network congestion.

As seen in Figure 19-2, a single voice and video server is connected to the central site's LAN Ethernet segment. On this network, users at the remote offices running video-on-demand applications connect to the central server to receive multicast streams and to download recorded voice messages. At the same time, the Frame Relay network is serving normal users running e-mail or file transfer applications. The size of the delay-sensitive video and voice packets is expected to be relatively small compared with the size of the regular traffic. The network configurations in this example have a physical access rate of 128 kbps at the central site and 64 kbps at the remote sites.

As you've seen in the configuration examples of the routers shown in Example 19-3, a single service policy is created to configure a LLQ policy for all Frame Relay PVCs provisioned on the Frame Relay interface. For traffic classification, an access list is defined to match delay-sensitive traffic operating on UDP port number 16480 in this example. Traffic satisfying the criteria specified in access-list 101 is classified as belonging to the "video" traffic class, as shown in the "video" class-map configurations. In the llq policy-map, traffic belonging to "video" class-map is given high-priority treatment and is assigned to the high-priority queue with the priority command. In the same command, a bandwidth of 64 kbps is guaranteed for traffic in this class.

The class-default class is used to match all traffic not matching any of the user-defined criteria. In the example, fair-queue is configured to apply weighted fair queuing (WFQ) to all traffic in the default queue. On all routers, R1, R2, and R3, FRF.12 End-to-End Fragmentation is configured on the Frame Relay interfaces at the interface level with a fragment size of 120 bytes. Because all packets transmitted on the Frame Relay interface are subjected to the interface-level fragmentation, it is important to reiterate that the fragment size should be greater than the largest high-priority packet. A sufficiently larger fragment size prevents fragmentation of the smaller high-priority packets. Effectively, the fragmented data packets can be interleaved with the high-priority packets for transmission. This achieves the highest QoS for priority queue traffic on the Frame Relay network.

In the next example, actual traffic is sent onto the Frame Relay network to simulate the Frame Relay Queuing and Fragmentation at the Interface feature in action. To simulate the high-priority traffic, a multicast stream transmitting on the network at a rate of 64 kbps is created. In addition, the Frame Relay network is populated with different data traffic streams, amounting to an aggregate rate of approximately 128 kbps to create congestion.

The results of this test are shown in the next section, where the Cisco IOS commands for monitoring and troubleshooting the Frame Relay Queuing and Fragmentation at the Interface feature are introduced and explained.


Monitoring and Troubleshooting Frame Relay Queuing and Fragmentation at the Interface

This section continues from the previous section, looking at the effects of the Frame Relay Queuing and Fragmentation at the Interface feature after the traffic has been sent.

The show policy-map interface type/slot/number privileged EXEC command can be used to verify the LLQ QoS policy configurations enabled on the Frame Relay interface. Example 19-4 shows the LLQ policy applied to interface serial2/0 on Router R1 in Figure 19-2. Comparing the statistics displayed by the show policy-map interface command with the llq policy-map configurations in Example 19-3, you can observe that a strict priority queue is defined and a bandwidth of 64 kbps is guaranteed to traffic matching access-list 101. After the multicast stream is initiated, you can observe a steady stream of high-priority traffic at a rate of 64 kbps.

Recall that in this example, the interface serial2/0 on router R1 has an access rate of 128 kbps. Also, remember that when the subrate shaper is not configured, all PVCs on the Frame Relay interface are allowed to burst up to the physical line rate. As such, when the high-priority traffic is bursting at its full potential, the remaining 64 kbps of bandwidth is available to the class-default traffic. Hence, in the class-default class, only approximately 64 kbps of traffic are transmitted, with the remaining 64 kbps of traffic dropped. The next example shown in Example 19-4 depicts the resultant output of the show policy-map interface command performed on router R1.

Example 19-4. Output of the show policy-map interface Command on Router R1 in Figure 19-2
R1#show policy-map inter serial2/0

 Serial2/0

  Service-policy output: llq

    Class-map: video (match-all)
      298462 packets, 31636972 bytes
      5 minute offered rate 64000 bps, drop rate 0 bps
      Match: access-group 101
      Queueing
        Strict Priority
        Output Queue: Conversation 40
        Bandwidth 64 (kbps) Burst 1600 (Bytes)
        (pkts matched/bytes matched) 298462/31636972
        (total drops/bytes drops) 0/0

    Class-map: class-default (match-any)
      286897 packets, 57152306 bytes
      5 minute offered rate 127000 bps, drop rate 65000 bps
      Match: any
      Queueing
        Flow Based Fair Queueing
        Maximum Number of Hashed Queues 32
        (total queued/total drops/no-buffer drops) 64/149150/0

During the absence of high-priority traffic, the bandwidth reserved by the strict priority class can be freed up to other traffic, including the class-default traffic. The output of show policy-map interface at router R1 indicates that class-default traffic is using up freed bandwidth when there is no high-priority traffic. This is shown in Example 19-5.

Example 19-5. Output of show policy-map interface at Router R1
R1#show policy-map interface serial2/0

 Serial2/0

  Service-policy output: llq

    Class-map: video (match-all)
      0 packets, 0 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: access-group 101
      Queueing
        Strict Priority
        Output Queue: Conversation 40
        Bandwidth 64 (kbps) Burst 1600 (Bytes)
        (pkts matched/bytes matched) 0/0
        (total drops/bytes drops) 0/0

    Class-map: class-default (match-any)
      23669 packets, 4722026 bytes
      5 minute offered rate 102000 bps, drop rate 9000 bps
      Match: any
      Queueing
        Flow Based Fair Queueing
        Maximum Number of Hashed Queues 32
        (total queued/total drops/no-buffer drops) 64/1804/0

In the next example, the show interface type/slot/number privileged EXEC command is used to display the interleaving statistics. As shown in Example 19-6, after the LLQ QoS policy and FRF.12 interface fragmentation are configured, the show interface command displays the PQ interleaving information. The PQ interleaving counter shows the number of packets from the high-priority queue that have been interleaved with fragmented data packets from the class-default queue. The show interface command also reveals that FRF.12 End-to-End Fragmentation with a fragment size of 120 bytes has been enabled on the main interface level.

Example 19-6. Output of the show interface Command on Router R1 in Figure 19-2
R1#show interface serial2/0
Serial2/0 is up, line protocol is up
  Hardware is M4T
  MTU 1500 bytes, BW 128 Kbit, DLY 20000 usec,
     reliability 255/255, txload 247/255, rxload 1/255
  Encapsulation FRAME-RELAY, crc 16, loopback not set
  Keepalive set (10 sec)
  Restart-Delay is 0 secs
  LMI enq sent  419, LMI stat recvd 419, LMI upd recvd 0, DTE LMI up
  LMI enq recvd 0, LMI stat sent  0, LMI upd sent  0
  LMI DLCI 1023  LMI type is CISCO  frame relay DTE
  FR SVC disabled, LAPF state down
  Fragmentation type: end-to-end, size 120, PQ interleaves 135569
  Broadcast queue 0/64, broadcasts sent/dropped 1569/0, interface broadcasts 1430
  Last input 00:00:00, output 00:00:00, output hang never
  Last clearing of "show interface" counters 01:09:45
  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 149189
  Queueing strategy: weighted fair
  Output queue: 65/1000/64/149189 (size/max total/threshold/drops)
     Conversations  2/5/32 (active/max active/max total)
     Reserved Conversations 0/0 (allocated/max allocated)
     Available Bandwidth 32 kilobits/sec
  5 minute input rate 1000 bits/sec, 4 packets/sec
  5 minute output rate 124000 bits/sec, 147 packets/sec
     16501 packets input, 1018195 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
     563117 packets output, 59338543 bytes, 0 underruns
     0 output errors, 0 collisions, 0 interface resets
     0 output buffer failures, 0 output buffers swapped out
     0 carrier transitions     DCD=up  DSR=up  DTR=up  RTS=up  CTS=up

The show frame-relay pvc dlci privileged EXEC command can be used to verify the statistics pertaining to individual Frame Relay PVCs created under the main interface. As shown in Example 19-7, the output shows the output rate on each Frame Relay PVC.

Example 19-7. Output of show frame-relay pvc dlci Command on Router R1 in Figure 19-2
R1#show frame-relay pvc 102

PVC Statistics for interface Serial2/0 (Frame Relay DTE)

DLCI = 102, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial2/0.102

  input pkts 4699          output pkts 62838        in bytes 377004
  out bytes 12359044       dropped pkts 0           in pkts dropped 0
  out pkts dropped 0                out bytes dropped 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 2010      out bcast bytes 216548
  5 minute input rate 0 bits/sec, 2 packets/sec
  5 minute output rate 67000 bits/sec, 40 packets/sec
  pvc create time 06:46:35, last time pvc status changed 06:42:25
fragment type end-to-end         fragment size 120

R1#show frame-relay pvc 103

PVC Statistics for interface Serial2/0 (Frame Relay DTE)

DLCI = 103, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial2/0.103

  input pkts 4556          output pkts 54237        in bytes 367612
  out bytes 11148016       dropped pkts 0           in pkts dropped 0
  out pkts dropped 0                out bytes dropped 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 2014      out bcast bytes 217150
  5 minute input rate 0 bits/sec, 1 packets/sec
  5 minute output rate 67000 bits/sec, 40 packets/sec
  pvc create time 06:46:37, last time pvc status changed 06:19:27
fragment type end-to-end         fragment size 120

As shown in Example 19-8, the show frame-relay fragment privileged EXEC command displays the fragmentation information and statistics pertaining to Frame Relay Fragmentation enabled on the router.

Example 19-8. Output of the show frame-relay fragment Command on Routers R1, R2, and R3 in Figure 19-2
R1#show frame-relay fragment
interface         dlci  frag-type    frag-size  in-frag    out-frag   dropped-frag
Serial2/0.102     102   end-to-end   120        0          1050       0
Serial2/0.103     103   end-to-end   120        0          1053       0
________________________________________________________________
R2 #show frame-relay fragment
interface         dlci  frag-type    frag-size  in-frag    out-frag   dropped-frag
Serial1/1.201     201   end-to-end   120        1050       0          0
________________________________________________________________
R3#show frame-relay fragment
interface         dlci  frag-type    frag-size  in-frag    out-frag   dropped-frag
Serial0.301       301   end-to-end   120        1053       0          0

As shown in Example 19-8, in normal operating conditions, the number of fragmented output packets at the transmitting router should match the number of fragmented input packets at the receiving router. The show frame-relay fragment command also indicates the type of fragmentation being configured on the router. In this case, "end-to-end" means that FRF.12 interface Fragmentation is configured.

Using the Subrate Shaper

In the next example, the configurations of router R1 are changed by adding the configurations for the subrate shaper. Example 19-9 shows the configurations of router R1, which has been altered to add a subrate shaper to the llq policy-map. The new subrate shaper restricts the aggregate output rate of the policy to 96000 bps.

Example 19-9. Adding a Subrate Shaper to the LLQ QoS Policy
<output omitted>

policy-map llq
  class video
    priority 64
  class class-default
   fair-queue
   shape average 96000
!
interface Serial2/0
 bandwidth 128
 no ip address
 encapsulation frame-relay
 service-policy output llq
 frame-relay fragment 120 end-to-end

Example 19-10 shows the corresponding output of the show policy-map command on router R1 after the subrate shaper configurations are added.

Example 19-10. Output of the show policy-map interface type/slot/number Command on Router R1 After Subrate Shaper Is Configured
R1#show policy-map interface serial2/0

 Serial2/0

  Service-policy output: llq

    Class-map: video (match-all)
      1552 packets, 164512 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: access-group 101
      Queueing
        Strict Priority
        Output Queue: Conversation 40
        Bandwidth 64 (kbps) Burst 1600 (Bytes)
        (pkts matched/bytes matched) 1552/164512
        (total drops/bytes drops) 11/1166

    Class-map: class-default (match-any)
      35681 packets, 7118179 bytes
      5 minute offered rate 128000 bps, drop rate 37000 bps
      Match: any
      Queueing
        Flow Based Fair Queueing
        Maximum Number of Hashed Queues 32
        (total queued/total drops/no-buffer drops) 1/124/0
      Traffic Shaping
           Target/Average   Byte   Sustain   Excess    Interval  Increment
             Rate           Limit  bits/int  bits/int  (ms)      (bytes)
            96000/96000     1992   7968      7968      83        996

        Adapt  Queue     Packets   Bytes     Packets   Bytes     Shaping
        Active Depth                         Delayed   Delayed   Active
        -      64        27739     5812916   27720     5533240   yes

Example 19-11 shows the output of the show interface command at router R1 after the subrate shaper has been applied. Observe that the output rate has been rate-limited to 96 kbps.

Example 19-11. Output of show interface Command at Router R1 After Subrate Shaper Is Added
R1#show interface serial2/0
Serial2/0 is up, line protocol is up
  Hardware is M4T
  MTU 1500 bytes, BW 128 Kbit, DLY 20000 usec,
     reliability 255/255, txload 191/255, rxload 3/255
  Encapsulation FRAME-RELAY, crc 16, loopback not set
  Keepalive set (10 sec)
  Restart-Delay is 0 secs
  LMI enq sent  61, LMI stat recvd 61, LMI upd recvd 0, DTE LMI up
  LMI enq recvd 0, LMI stat sent  0, LMI upd sent  0
  LMI DLCI 1023  LMI type is CISCO  frame relay DTE
  FR SVC disabled, LAPF state down
  Fragmentation type: end-to-end, size 120, PQ interleaves 0
  Broadcast queue 0/64, broadcasts sent/dropped 144/0, interface broadcasts 124
  Last input 00:00:00, output 00:00:00, output hang never
  Last clearing of "show interface" counters 00:10:12
  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 14414
  Queueing strategy: weighted fair
  Output queue: 1/1000/64/135 (size/max total/threshold/drops)
     Conversations  1/5/32 (active/max active/max total)
     Reserved Conversations 0/0 (allocated/max allocated)
     Available Bandwidth 32 kilobits/sec
  5 minute input rate 2000 bits/sec, 4 packets/sec
  5 minute output rate 96000 bits/sec, 114 packets/sec
     2623 packets input, 160840 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
     71129 packets output, 7460834 bytes, 0 underruns
     0 output errors, 0 collisions, 0 interface resets
     0 output buffer failures, 0 output buffers swapped out
     0 carrier transitions     DCD=up  DSR=up  DTR=up  RTS=up  CTS=up

Subrate shaping can be configured to control the rate at which the shaper can send traffic. However, recall that when subrate shaping is applied, interleaving of high-priority traffic is disabled.

Finally, to troubleshoot issues regarding FRF.12 interface fragmentation on a Cisco router, use the debug frame-relay fragment [event | interface] command. Example 19-12 shows the output of the debug frame-relay fragment interface command captured on router R1.

Example 19-12. Captures of the debug frame-relay fragment interface Command at Router R1
R1#debug frame-relay fragment interface
07:50:01: Serial2/0.102(o): dlci 102, tx-seq-num 2274, E bit set, frag_hdr 03 B1 50 E2
07:50:01: Serial2/0.102(o): dlci 102, tx-seq-num 2275, B bit set, frag_hdr 03 B1 90 E3
07:50:01: Serial2/0.102(o): dlci 102, tx-seq-num 2276, E bit set, frag_hdr 03 B1 50 E4
07:50:01: Serial2/0.102(o): dlci 102, tx-seq-num 2277, B bit set, frag_hdr 03 B1 90 E5
07:50:01: Serial2/0.102(o): dlci 102, tx-seq-num 2278, E bit set, frag_hdr 03 B1 50 E6
07:50:01: Serial2/0.102(o): dlci 102, tx-seq-num 2279, B bit set, frag_hdr 03 B1 90 E7
07:50:01: Serial2/0.102(o): dlci 102, tx-seq-num 2280, E bit set, frag_hdr 03 B1 50 E8
07:50:01: Serial2/0.102(o): dlci 102, tx-seq-num 2281, B bit set, frag_hdr 03 B1 90 E9
07:50:01: Serial2/0.102(o): dlci 102, tx-seq-num 2282, E bit set, frag_hdr 03 B1 50 EA

The captures of the debug frame-relay fragment interface command at router R1 show users information pertaining to the fragmented packet transmitted out of the router interface. As shown in Example 19-12, the "tx-seq-num" field indicates the transmit sequence number of the fragmented packet. This field is used to reassemble the fragmented packet at the receiving router. The B and E bits represent Beginning and End of the fragments. With this debug output information, you know that the received packet is broken up into two fragments. The debug output also shows the fragmentation header of the fragmented packets.

Use debug commands with care, because like all debug commands, the debug frame-relay fragment command generates a large number of CPU cycles and may impact the performance of the router if it is enabled.


Summary

This chapter showed how the Frame Relay Queuing and Fragmentation at the Interface feature helps customers and users to simplify the configurations for LLQ and Frame Relay FRF.12 End-to-End Fragmentation on a Frame Relay interface. With the Frame Relay Queuing and Fragmentation at the Interface feature, users are able to apply a collective LLQ policy to all Frame Relay PVCs created under the main Frame Relay interface or its subinterfaces. As part of the feature, Frame Relay FRF.12 End-to-End Fragmentation is now supported at the interface level. Before the Frame Relay Queuing and Fragmentation at the Interface feature, FRF.12 was only supported at the PVC level.

Frame Relay Queuing and Fragmentation at the Interface allows interleaving of high-priority frames with fragmented data frames to achieve the highest QoS for high-priority traffic. Additionally, a subrate shaper can be configured to limit the burst rate of each Frame Relay PVC to the configured interface shaping rate.

This chapter showed readers the configuration tasks and commands required to configure the Frame Relay Queuing and Fragmentation at the Interface feature on a Cisco router. Then this chapter demonstrated to readers the relevant Cisco IOS show and debug commands for monitoring and maintaining the feature on a Cisco router. The next chapter discusses the Link Fragmentation and Interleaving feature for Frame Relay virtual circuits.


Review Questions

1: | Describe the benefits of the Frame Relay Queuing and Fragmentation at the Interface feature.
2: | What is interleaving? Describe its main advantage.
3: | What are the legacy Frame Relay functionalities that are mutually exclusive with the Frame Relay Queuing and Fragmentation at the Interface feature?
4: | What is the purpose of the subrate shaper?
5: | When subrate shaping is enabled, what component of Frame Relay Queuing and Fragmentation at the Interface is automatically disabled?


Reference

Cisco IOS Release 12.2(13)T Frame Relay Queuing and Fragmentation at the Interface: http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122newft/122t/122t13/frfrintq.htm


Chapter 20. Link Fragmentation and Interleaving (LFI) for Frame Relay Virtual Circuits

Link Fragmentation and Interleaving (LFI) is a Cisco IOS link-layer efficiency mechanism designed to reduce serialization delay and jitters when transporting both real-time and non-real-time traffic on slow bandwidth links. The Cisco IOS LFI feature discussed in this chapter is based on Cisco's implementation of Multilink Point-to-Point Protocol (MLP) over Frame Relay and ATM, which supports the fragmentation and packet sequencing specifications outlined in RFC 1717. The Frame Relay Fragmentation features discussed in Chapter 16 similarly offer Link-Efficiency mechanisms for minimizing serialization delay for small delay-sensitive packets over slow-speed Frame Relay links. However, the Cisco IOS LFI using MLP supports both Frame Relay and ATM virtual circuits as well as FRF.8 Frame Relay-to-ATM interworking. For that reason, MLP LFI is useful in environments that need to support differing Frame Relay and ATM networks using FRF.8. FRF.8 Frame Relay-to-ATM interworking is covered in Chapter 8 of this book.

This chapter covers the Cisco IOS MLP LFI feature for supporting Frame Relay virtual circuits. MLP LFI over ATM virtual circuits will not be addressed in this chapter. After presenting an overview of the MLP LFI mechanism, this chapter will show you each major step involved in configuring MLP LFI over Frame Relay on a Cisco router. In addition, this chapter will discuss the Cisco IOS commands for monitoring and maintaining the Cisco IOS MLP LFI feature on a Cisco router.

The topics and questions that this chapter addresses include the following:

  • Overview of LFI using MLP

  • Configuring Cisco IOS MLP LFI support for Frame Relay virtual circuits

  • Monitoring and maintaining Cisco IOS MLP LFI support for Frame Relay

After completing this chapter, readers will be familiar with the use of the MLP LFI feature to support the delivery of real-time application traffic over slow bandwidth links. Readers will recognize the benefits of Cisco's MLP LFI feature for Frame Relay virtual circuits. Readers will also be able to configure the Cisco IOS MLP LFI feature to support Frame Relay virtual circuits. Finally, readers will become familiar with the relevant Cisco IOS show and debug commands required to monitor and maintain Cisco IOS MLP LFI configurations on Cisco routers.


LFI Using MLP Overview

LFI is part of Cisco's QoS features and solutions for addressing the diverse requirements of voice, video, and data applications on the network. Interactive and real-time delay-sensitive traffic, such as voice, is susceptible to increased latency when it is transported together with normal data traffic. In many situations, the latency issue can become critical, especially when the real-time traffic is delivered over slow bandwidth links. On these slower bandwidth links, the network latency suffered by the delay-sensitive traffic can affect the quality and performance of the real-time applications.

The MLP with LFI feature allows large data packets to be multilink-encapsulated and fragmented so that they are small enough to satisfy the delay requirements of real-time delay-sensitive traffic. In addition, MLP LFI provides a special transmission queue for delay-sensitive traffic so that it can be transmitted ahead of other normal flows. Hence, using the MLP LFI feature can lead to more efficient and predictable services for business-critical applications.

The Cisco IOS MLP LFI feature reduces delay on slower bandwidth links by fragmenting the larger data packets and interleaving the delay-sensitive voice packets with the smaller fragmented data packets. Cisco also recommends the use of LFI on slow links with access speeds less than 768 kbps.

Supporting Real-Time Applications

Real-time applications, such as Voice over IP (VoIP), have different characteristics and requirements than traditional data applications. Unlike the traditional data applications, the nature of real-time applications means that they are intolerant of packet loss and jitters. Packet loss due to network congestion and delayed packets caused by jitters can result in the degradation of the quality of the voice transmission. To support voice traffic over a data network, the voice traffic must be protected. QoS mechanisms are required to ensure reliable delivery of the delay-sensitive packets with acceptable consistent delay and minimal latency and packet loss.

To maintain good voice quality, the one-way delay target for real-time voice packets is under to 150 milliseconds (ms). In view of the requirements for voice packets, an IP-based network using the best-effort delivery model does not work too well for transporting real-time voice traffic. First of all, the per-packet overheads are typically high for the transmission of real-time traffic. Then again, in order to achieve bulk transmission efficiency, the maximum transmission unit (MTU) has to be sufficiently large. However, on a slow 56 kbps line, a packet with an MTU size of 1500 bytes can take 215 ms to traverse the link, therefore exceeding the delay target. This problem drives the requirement for a technique to fragment larger packets and queue smaller packets between the fragments of the large packet. Moreover, the QoS mechanism used must ensure the voice packets are prioritized for transmission ahead of the fragmented data packets, by using a strict priority queue reserved for the delay-sensitive traffic.

MLP-Based LFI Mechanism

The Cisco IOS MLP LFI feature uses MLP to provide a way to split, reassemble, and sequence datagrams across multiple logical data links. Under the LFI process, the traditionally larger data packets are multilink-encapsulated and fragmented into packets of a size that is comparatively small to the size of the delay-sensitive packets. Then the small delay-sensitive packets, which are not multilink-encapsulated, are interleaved with fragments of the larger data packets.

The MLP process enables the fragmented data packets to be transmitted at the same time over the multiple point-to-point links to the same remote destination. Typically, the multilink connections are configured so that additional links are brought up when the current load exceeds the configured load threshold. The threshold can be calculated in the inbound direction, outbound direction, or both. In this way, flexibility is added because additional bandwidth can be provided on demand. The additional bandwidth helps to reduce latency across the link. Figure 20-1 illustrates the details of the LFI process.

Figure 20-1. How the LFI Process Works

[View full size image]

As shown in Figure 20-1, incoming packets arriving at the router are comprised of a mix of both IP voice packets and "jumbograms," the latter representing the traditionally larger data packets. The arriving packets are classified into the queues based on the traffic classification policy configured by the user. After the packets are queued, the fragmentation process configured on the router allows large packets to be fragmented. The fragment size is usually specified based on the required delay of the IP voice packets, which are generally small in nature. The large data packets undergo the fragmentation process so that they are sufficiently small to be interleaved with the IP voice packets. In the next step, the jumbogram packet fragments, and the IP voice packets are interleaved. Because Weighted Fair Queuing (WFQ) is used on the interface, the packets are scheduled using the WFQ strategy for their transmission in the output interface queue.


Configuring Cisco IOS MLP LFI for Frame Relay on a Cisco Router

This section describes the configuration tasks involved in setting up the LFI feature for Frame Relay virtual circuits on a Cisco router. Note that the Cisco IOS software supports LFI via MLP, LFI via MLP over Frame Relay, and LFI via MLP over ATM. In this section, only the configuration tasks concerning LFI via MLP over Frame Relay virtual circuits are discussed.

NOTE

The Cisco IOS MLP LFI feature for Frame Relay and ATM virtual circuits is released in Cisco IOS Release 12.1(5)T.

There are no new Frame Relay-specific commands involved in configuring LFI over Frame Relay virtual circuits. LFI over Frame Relay uses existing MLP commands to enable the feature. However, note that when configuring LFI over Frame Relay virtual circuits, Frame Relay Traffic Shaping must be enabled on the Frame Relay interface.

There are two major configuration tasks involved in enabling MLP LFI over Frame Relay virtual circuits on a Cisco router. The tasks are as follows:

  1. Enable MLP by creating a virtual template interface.

  2. Associate the virtual template interface with a Frame Relay PVC.

For the first major configuration task, create a virtual template interface on a Cisco router to enable MLP by performing the configuration steps described below:

Step 1. | Beginning from the global configuration mode, create a virtual template interface with interface virtual-template number. This enters the user into the interface configuration mode.
Step 2. | Set up the bandwidth on the virtual template interface with the bandwidth kbps interface configuration command. This step is required so that the fragment size can be calculated later.
Step 3. | Attach the policy-map to the output interface with the service-policy output policy-name interface configuration command. This step associates a preconfigured policy-map with the virtual template interface. The policy-map performs traffic classification for the real-time delay-sensitive traffic.
Step 4. | Enable MLP on the virtual template interface with ppp multilink interface configuration command.
Step 5. | Use the ppp multilink fragment-delay milliseconds interface configuration command to configure the maximum delay allowed for transmission of a packet fragment on an MLP bundle.
Step 6. | Use the ppp multilink interleaves interface configuration command to enable interleaving of real-time packets among the fragments of larger packets on an MLP bundle.

NOTE

The fragment size at the MLP bundle can be set by configuring the bandwidth and multilink fragment-delay commands at the virtual-template interface. These commands are used to calculate the fragment size via the following formula:

Fragment size = bandwidth * fragment delay / 8

In the second major configuration task, you need to associate the virtual template with the Frame Relay PVC. Follow the configuration steps listed below, beginning in the global configuration mode:

Step 1. | Enter the interface configuration mode of the selected Frame Relay interface and enable Frame Relay encapsulation with the encapsulation frame-relay interface configuration command.
Step 2. | Enable Frame Relay Traffic Shaping on the interface with the frame-relay traffic-shaping interface configuration command. FRTS is essential to enable the LFI feature for Frame Relay.
Step 3. | Use the frame-relay interface-dlci dlci [ppp virtual-template-name] interface configuration command to associate the virtual template interface with the Frame Relay PVC (DLCI).
Step 4. | In the Frame Relay interface-dlci configuration mode, use class map-class-name to associate a Frame Relay map class with the Frame Relay DLCI.

NOTE

First-in, first-out (FIFO) queuing is the only queuing strategy allowed in the Frame Relay PVC associated with MLP. Fancy queuing (PQ or CQ) for FRTS cannot be used with MLP on a Frame Relay PVC.

When an MLP bundle is created on the Cisco router, the MLP bundle can have only one link. Example 20-1 shows a configuration example of LFI using MLP over Frame Relay virtual circuits. The configurations are set up with a virtual template interface.

Example 20-1. Configuration Example of LFI Using MLP over Frame Relay Virtual Circuits with Virtual Template Interface
Router#show running-config
<output omitted>
hostname Router
!
!
class-map match-all SANJOSE
  match access-group 100
!
!
policy-map CALIFORNIA
  class SANJOSE
    priority 48
!
!
!
interface Serial1/2
 no ip address
 encapsulation frame-relay
 ! Frame Relay Traffic Shaping (FRTS) must be enabled.
 frame-relay traffic-shaping
!
interface Serial1/2.1 point-to-point
 frame-relay interface-dlci 40 ppp Virtual-Template1
  class MLP
!
!
interface Virtual-Template1
 bandwidth 78
 ip address 131.180.50.5 255.255.255.0
 service-policy output CALIFORNIA
 ppp multilink
 ppp multilink fragment-delay 8
 ppp multilink interleave
!
!
!
map-class frame-relay MLP
 frame-relay cir 64000
 frame-relay bc 300
 frame-relay be 0
!
access-list 100 permit udp any any precedence critical

The next section demonstrates the relevant Cisco IOS show commands and debug commands useful for monitoring and maintaining MLP LFI for Frame Relay virtual circuits on a Cisco router.


Monitoring and Troubleshooting the Cisco IOS MLP LFI over Frame Relay Feature

This section introduces and explains the various Cisco IOS commands for monitoring and troubleshooting the Cisco IOS MLP LFI feature, configured over Frame Relay.

The first Cisco IOS show command useful for monitoring LFI using MLP over Frame Relay virtual circuits is the show frame-relay pvc privileged EXEC mode command. This command shows the statistics for the Frame Relay PVC using MLP on a Cisco router, as shown in Example 20-2.

Example 20-2. Output of the show frame-relay pvc Command on a Cisco Router Configured with LFI Using MLP over Frame Relay Virtual Circuits
Router#show frame-relay pvc 40

PVC Statistics for interface Serial1/2 (Frame Relay DTE)

DLCI = 40, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial1/2.1

  input pkts 28            output pkts 32           in bytes 2011
  out bytes 2412           dropped pkts 0           in pkts dropped 0
  out pkts dropped 0                out bytes dropped 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 2         out bcast bytes 666
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
  pvc create time 00:01:20, last time pvc status changed 00:01:04
  Bound to Virtual-Access4 (up, cloned from Virtual-Template1)
  cir 64000     bc 640       be 0         byte limit 80     interval 10
  mincir 32000     byte increment 80    Adaptive Shaping none
  pkts 32        bytes 2412      pkts delayed 3         bytes delayed 158
  shaping inactive
  traffic shaping drops 0
  Queueing strategy: fifo
  Output queue 0/40, 0 drop, 0 dequeued

As shown, the show frame-relay pvc dlci command displays the statistics pertaining to the Frame Relay PVC as well as the MLP information. You can observe in Example 20-2 that DLCI 40 is bound to a logical virtual-access interface 1, which is cloned and created from the Virtual-Template 1 interface that has been configured.

In the next example, the show ppp multilink privileged EXEC mode command displays information regarding the MLP bundle and its member links. Example 20-3 illustrates the output of the command executed at both routers R1 and R2.

Example 20-3. Output of show ppp multilink Command at a Router Configured with LFI Using MLP over Frame Relay Virtual Circuits
Router#show ppp multilink

Virtual-Access2, bundle name is Router2
  0 lost fragments, 0 reordered, 0 unassigned
  0 discarded, 0 lost received, 1/255 load
  0x376D received sequence, 0x3C sent sequence
  Member links: 1 (max not set, min not set)
Virtual-Access1  56 weight

The show ppp multilink command provides information such as the remote bundle name associated with it, packet statistics, sequencing statistics, the number of member links assigned to the bundle, and the weight. When MLP LFI is used, there can be only one link per MLP bundle.

The show policy-map interface privileged EXEC mode command shows information related to the QoS policy attached to the interface. The command is performed on router R1 for its virtual access interface. The output is shown in Example 20-4.

Example 20-4. Output of show policy-map interface Command at Router R1
R1#show policy-map inter virtual-access2
 Virtual-Access2

  Service-policy output: CALIFORNIA (1891)

    Class-map: SANJOSE (match-all) (1893/3)
      0 packets, 0 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: ip precedence 0  (1897)
      Weighted Fair Queueing
        Strict Priority

        Output Queue: Conversation 24
        Bandwidth 32 (kbps) Burst 800 (Bytes)
        (pkts matched/bytes matched) 0/0
        (total drops/bytes drops) 0/0

    Class-map: class-default (match-any) (1901/0)
      0 packets, 0 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: any  (1905)

The use of the show policy-map command is very similar to the same command used for Modular Quality of Service Command Line Interface (MQC) and queuing in the other chapters of this book.

Example 20-5 exemplifies the output of the show interface privileged EXEC mode command on a Cisco router configured with LFI using MLP over Frame Relay virtual circuits. The example shows information about the virtual access interface, including interleaving information and statistics.

Example 20-5. Output of the show interface Virtual-Access Command on a Cisco Router Configured with LFI Using MLP over Frame Relay Virtual Circuits
Router#show interface Virtual-Access2
Virtual-Access5 is up, line protocol is up
  Hardware is Virtual Access interface
  Internet address is 131.180.50.5 /24
  MTU 1500 bytes, BW 78 Kbit, DLY 100000 usec,
     reliability 255/255, txload 3/255, rxload 3/255
  Encapsulation PPP, loopback not set
  Keepalive set (10 sec)
  DTR is pulsed for 5 seconds on reset
  LCP Open, multilink Open
  Open: IPCP
  Last input 00:00:58, output never, output hang never
  Last clearing of "show interface" counters 00:06:20
  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
  Queueing strategy: weighted fair
  Output queue: 0/1000/64/0/12 (size/max total/threshold/drops/interleaves)
     Conversations  0/2/32 (active/max active/max total)
     Reserved Conversations 0/0 (allocated/max allocated)
     Available Bandwidth 10 kilobits/sec
  5 minute input rate 1000 bits/sec, 2 packets/sec
  5 minute output rate 1000 bits/sec, 3 packets/sec
     760 packets input, 58674 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
     1080 packets output, 109120 bytes, 0 underruns
     0 output errors, 0 collisions, 0 interface resets
     0 output buffer failures, 0 output buffers swapped out
     0 carrier transitions

To verify issues pertaining to MLP LFI fragmentation on a Cisco router, use the debug ppp multilink fragments Cisco IOS debug command. A sample output of the debug command being executed on router R1 is shown in Example 20-6.

Example 20-6. Output of debug ppp multilink fragments Command on Router R1
Router#debug ppp multilink fragments
<output omitted>
02:22:45: Vi4 MLP: I frag 0000003D size 78 direct
02:22:45: Vi4 MLP: I frag 0000003E size 78 direct
02:22:45: Vi4 MLP: I frag 0000003F size 78 direct
02:22:45: Vi4 MLP: I frag 00000040 size 78 direct
02:22:45: Vi4 MLP: I frag 00000041 size 78 direct
02:22:45: Vi4 MLP: I frag 00000042 size 78 direct
02:22:45: Vi4 MLP: I frag 00000043 size 78 direct
02:22:45: Vi4 MLP: I frag 00000044 size 78 direct
02:22:45: Vi4 MLP: I frag 00000045 size 78 direct
02:22:45: Vi4 MLP: I frag 00000046 size 78 direct
02:22:45: Vi4 MLP: I frag 00000047 size 78 direct
02:22:45: Vi4 MLP: I frag 40000048 size 40 direct
02:22:45: Vi4 MLP: O frag 8000002F size 78
02:22:45: Vi4 MLP: O frag 00000030 size 78
02:22:45: Vi4 MLP: O frag 00000031 size 78
02:22:45: Vi4 MLP: O frag 00000032 size 78
02:22:45: Vi4 MLP: O frag 00000033 size 78
02:22:45: Vi4 MLP: O frag 00000034 size 78
02:22:45: Vi4 MLP: O frag 00000035 size 78
02:22:45: Vi4 MLP: O frag 00000036 size 78
02:22:45: Vi4 MLP: O frag 00000037 size 78
02:22:45: Vi4 MLP: O frag 00000038 size 78
02:22:45: Vi4 MLP: O frag 00000039 size 78


Summary

This chapter looked at the Cisco IOS MLP LFI feature and focused on configuring MLP LFI over Frame Relay virtual circuits. To support real-time delay-sensitive traffic on slow bandwidth point-to-point Frame Relay links, you can enable the LFI feature via MLP over the Frame Relay PVC. This allows real-time interactive traffic to be interleaved with non-real-time traffic. In comparison with smaller real-time traffic such as Voice over IP, non-real-time traffic generally consists of larger data packets. The large data packets can be fragmented and interleaved with the real-time packets to ensure good latency bound for the real-time applications.

In addition, this chapter looked at a scenario on implementing the Cisco IOS MLP LFI to support Frame Relay virtual circuits. This chapter also discussed the major Cisco IOS configuration tasks involved. Finally, this chapter looked at the relevant Cisco IOS commands that can be used to monitor and troubleshoot the Cisco IOS MLP LFI feature on Frame Relay networks. The next chapter discusses Weighted Random Early Detection (WRED) for Frame Relay. WRED is a congestion avoidance QoS feature supported on Frame Relay networks.


Review Questions

1: | What are the main benefits of MLP LFI for Frame Relay?
2: | What are the main applications of LFI?
3: | What are the supported directions for load threshold calculation?
4: | How is the fragment size for MLP LFI derived?
5: | How many links can an MLP bundle have on a Cisco router?


Reference

Cisco IOS 12.1(5)T Release Documentation, Link Fragmentation and Interleaving for Frame Relay and ATM Virtual Circuits: http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121newft/121t/121t5/dtlfifra.htm


Case Study: LFI over Frame Relay Using MLP

To demonstrate the use of the Cisco IOS MLP LFI for Frame Relay virtual circuits, a scenario entailing a simple Frame Relay network is used. Figure 20-2 shows the topological diagram of the Frame Relay network is used for the configuration examples.

Figure 20-2. Frame Relay Network to Demonstrate MLP LFI over Frame Relay

In this setup, a low-speed Frame Relay connection of 56 kbps connects two remote offices running both real-time and non-real-time applications. VoIP and Telnet traffic is the mainstream real-time interactive traffic of concern. LAN-to-LAN file transfers using FTP across the Frame Relay WAN makes up the majority of the non-real-time traffic.

The VoIP users complain about regular voice echo and talker overlap in their VoIP applications, especially during the busiest period of the day when other FTP users are transmitting bulk traffic across the network. The interactive Telnet users also complain about delays and timeouts associated with their sessions. The senior network engineer identified the cause of the problem as the simultaneous transmission of both real-time and non-real-time traffic over the low-bandwidth link. The slow Frame Relay link is unable to sustain the combined burst of traffic from the different applications without causing increased latency for the real-time interactive traffic.

Generally, the size of the VoIP packets is between 60 to 200 bytes, including a 40-byte RTP/UDP/IP header. When the FTP applications are transmitting bulk traffic with an average packet size of 1500 bytes, the smaller VoIP packets are queued up behind the large data packets. In general, this problem causes increased latency and jitters for real-time interactive traffic when the network processes large packets over the slow links without fragmenting them.

To reduce the delay and jitters for the real-time VoIP applications over the slow Frame Relay link, the company decided to implement the LFI via MLP feature on the Cisco routers connected to the Frame Relay network. Using MLP LFI over Frame Relay, the objective is to fragment the larger data packets and then interleave the fragments with the real-time voice packets. This provides good latency bound for the voice traffic over a low-speed connection. In addition, because the Real-Time Transport Protocol (RTP) Header Compression is considerably larger compared with its voice payload, it is inefficient to transmit RTP traffic over a slow bandwidth link without utilizing compression. RTP Header Compression should be used when the amount of RTP traffic is substantial on the link with limited bandwidth.

NOTE

The output shown by different Cisco IOS software releases may differ slightly. The Cisco IOS release used in the example is 12.2(0.12)T.

Configuration Examples

The configurations of the routers in Figure 20-2 are shown in Example 20-7.

Example 20-7. Configuration Examples of Routers R1 and R2 in Figure 20-2
! Router R1:

<output omitted>

class-map match-all VOICE
  match ip precedence 5
!
!
policy-map LFI
  class VOICE
    priority 32
!
interface Ethernet1/2
 ip address 172.16.2.1 255.255.255.0
!
interface Serial2/0
 no ip address
 encapsulation frame-relay
 frame-relay traffic-shaping
!
interface Serial2/0.102 point-to-point
 frame-relay interface-dlci 102 ppp Virtual-Template1
  class MLP
!
interface Virtual-Template1
 bandwidth 56
 ip address 172.16.1.1 255.255.255.252
 service-policy output LFI
 ppp multilink
 ppp multilink fragment-delay 8
 ppp multilink interleave
!
ip route 172.16.3.0 255.255.255.0 172.16.1.2
!
map-class frame-relay MLP
 frame-relay cir 56000
 no frame-relay adaptive-shaping
!
!
dial-peer voice 1 voip
 destination-pattern 4088532000
 session target ipv4:172.16.1.2
 dtmf-relay cisco-rtp
 ip precedence 5
!
dial-peer voice 2 pots
 port 3/0
 destination-pattern 4088531000
________________________________________________________________
! Router R2:

<output omitted>

class-map match-all VOICE
  match ip precedence 5
!
!
policy-map LFI
  class VOICE
    priority 32
!
interface Ethernet2/1
 ip address 172.16.3.1 255.255.255.0
!
interface Serial1/1
 no ip address
 encapsulation frame-relay
 frame-relay traffic-shaping
!
interface Serial1/1.201 point-to-point
 no ip mroute-cache
 frame-relay interface-dlci 201 ppp Virtual-Template1
  class MLP
!
interface Virtual-Template1
 bandwidth 56
 ip address 172.16.1.2 255.255.255.252
 service-policy output LFI
 ppp multilink
 ppp multilink fragment-delay 8
 ppp multilink interleave
!
ip route 172.16.2.0 255.255.255.0 172.16.1.1
!
map-class frame-relay MLP
 frame-relay cir 56000
 no frame-relay adaptive-shaping
!
!
dial-peer voice 1 voip
 destination-pattern 4088531000
 session target ipv4:172.16.1.1
 dtmf-relay cisco-rtp
 ip precedence 5
!
dial-peer voice 2 pots
 port 0/0
 destination-pattern 4088532000

NOTE

PPP over Frame Relay supports authentication with CHAP or PAP. Refer to Chapter 10, "Point-to-Point Protocol over Frame Relay," for reference on PPP over Frame Relay.

As you can see in the running configurations of routers R1 and R2 in Example 20-7, the configurations set up the virtual template interfaces of routers R1 and R2 with a bandwidth of 56000 bps and a fragment delay of 8 ms. This effectively creates a fragment size of 56 bytes, using the formula for fragment size calculation shown earlier in this chapter. In addition, the ppp multilink interleave command allows packets smaller than 56 bytes to be interleaved with the fragments.

To examine the feature at work, actual traffic has to be sent across the Frame Relay network to cause congestion. First of all, a VoIP call is placed across the Frame Relay network to simulate the real-time traffic. The fragment size in use is approximately 56 bytes. Different codecs have different voice payload sizes; if a different codec is used, the fragment size may have to be increased. Data transfers are set up between the terminals on each site to create the data traffic on the Frame Relay network. The goal is to verify that fragmentation and interleaving can occur between the routers.

The show frame-relay pvc command verifies the information and statistics for Frame Relay DLCI 102 configured with LFI using MLP over Frame Relay on router R1. This is exemplified in Example 20-8.

Example 20-8. Output of the show frame-relay pvc Command at Router R1
R1#show frame-relay pvc 102

PVC Statistics for interface Serial2/0 (Frame Relay DTE)

DLCI = 102, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial2/0.102

  input pkts 30            output pkts 82710        in bytes 10320
  out bytes 6679530        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 30        out bcast bytes 10380
  pvc create time 05:21:41, last time pvc status changed 00:36:54
  Bound to Virtual-Access1 (up, cloned from Virtual-Template1)
  cir 56000     bc 56000     be 0         byte limit 875    interval 125
  mincir 28000     byte increment 875   Adaptive Shaping none
  pkts 41497     bytes 3347631   pkts delayed 274       bytes delayed 15152
  shaping inactive
  traffic shaping drops 0
  Queueing strategy: fifo
Output queue 0/40, 0 drop, 0 dequeued

Example 20-8 has verified that Frame Relay DLCI 102 is bound to a logical virtual-access interface 1, which is in turn cloned and created from Virtual-Template 1 interface.

The show ppp multilink command displays information regarding the MLP bundle and its member links on routers R1 and R2. Example 20-9 illustrates the output of the show ppp multilink command executed at both routers R1 and R2.

Example 20-9. Output of show ppp multilink Command at Routers R1 and R2
R1#show ppp multilink

Virtual-Access2, bundle name is R2
  0 lost fragments, 0 reordered, 0 unassigned
  0 discarded, 0 lost received, 1/255 load
  0x376D received sequence, 0x3C sent sequence
  Member links: 1 (max not set, min not set)
Virtual-Access1  56 weight
________________________________________________________________
R2#show ppp multilink

Virtual-Access2, bundle name is R1
  0 lost fragments, 0 reordered, 0 unassigned
  0 discarded, 0 lost received, 1/255 load
  0x3C received sequence, 0x376D sent sequence
  Member links: 1 (max not set, min not set)
Virtual-Access1  56 weight

The show policy-map interface command shows information related to the QoS policy attached to the interface on router R1, as shown in Example 20-10.

Example 20-10. Output of show policy-map interface Command at Router R1
R1#show policy-map interface virtual-access2
 Virtual-Access2

  Service-policy output: LFI (1891)

    Class-map: VOICE (match-all) (1893/3)
      42429 packets, 5049533 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: ip precedence 0  (1897)
      Weighted Fair Queueing
        Strict Priority
        Output Queue: Conversation 24
        Bandwidth 32 (kbps) Burst 800 (Bytes)
        (pkts matched/bytes matched) 43635/6846161
        (total drops/bytes drops) 1206/1796628

    Class-map: class-default (match-any) (1901/0)
      0 packets, 0 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: any  (1905)

In the next example, the effects on router R1 are examined after both real-time and non-real-time traffic have traversed the Frame Relay network.

Example 20-11 exemplifies the output of the show interface privileged EXEC command on router R1, which shows the information about the virtual access interface before interleaving occurs.

Example 20-11. Output of the show interface Command on Router R1 Before Interleaving Occurs
R1#show interface Virtual-Access2
Virtual-Access5 is up, line protocol is up
  Hardware is Virtual Access interface
  Internet address is 172.16.1.1/30
  MTU 1500 bytes, BW 56 Kbit, DLY 100000 usec,
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation PPP, loopback not set
  Keepalive set (10 sec)
  DTR is pulsed for 5 seconds on reset
  LCP Open, multilink Open
  Open: IPCP
  Last input 00:00:58, output never, output hang never
  Last clearing of "show interface" counters 00:00:03
  Input queue: 0/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/1/32 (active/max active/max total)
     Reserved Conversations 0/0 (allocated/max allocated)
     Available Bandwidth 10 kilobits/sec
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
     0 packets input, 0 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
     0 packets output, 0 bytes, 0 underruns
     0 output errors, 0 collisions, 0 interface resets
     0 output buffer failures, 0 output buffers swapped out
     0 carrier transitions

Example 20-12 illustrates the output of the show interface command on router R1, which shows the information of the virtual-access interface after interleaving has occurred.

Example 20-12. Output of the show interface Command on Router R1 After Interleaving Has Occurred
R1#show interface Virtual-Access2
Virtual-Access5 is up, line protocol is up
  Hardware is Virtual Access interface
  Internet address is 172.16.1.1/30
  MTU 1500 bytes, BW 56 Kbit, DLY 100000 usec,
     reliability 255/255, txload 3/255, rxload 3/255
  Encapsulation PPP, loopback not set
  Keepalive set (10 sec)
  DTR is pulsed for 5 seconds on reset
  LCP Open, multilink Open
  Open: IPCP
  Last input 00:00:37, output never, output hang never
  Last clearing of "show interface" counters 00:06:20
  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
  Queueing strategy: weighted fair
  Output queue: 0/1000/64/0/12 (size/max total/threshold/drops/interleaves)
     Conversations  0/2/32 (active/max active/max total)
     Reserved Conversations 0/0 (allocated/max allocated)
     Available Bandwidth 10 kilobits/sec
  5 minute input rate 1000 bits/sec, 2 packets/sec
  5 minute output rate 1000 bits/sec, 3 packets/sec
     760 packets input, 58674 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
     1080 packets output, 109120 bytes, 0 underruns
     0 output errors, 0 collisions, 0 interface resets
     0 output buffer failures, 0 output buffers swapped out
     0 carrier transitions

Observe that in the output of the show interface virtual-access command in Example 20-12, interleaving statistics is displayed after interleaving of the real-time packets and fragments has occurred.

Finally, the debug ppp multilink fragments command is used to display statistics and information pertaining to PPP multilink fragments. This command is enabled on router R1 during the transmission of traffic. An example of the output of debug ppp multilink fragments at router R1 is given in Example 20-13.

Example 20-13. Output of debug ppp multilink fragments Command on Router R1
R1#debug ppp multilink fragments
<output omitted>
00:27:02: Vi2 MLP-FS: I seq 80000450 size 56
00:27:02: Vi2 MLP-FS: I seq 451 size 56
00:27:02: Vi2 MLP-FS: I seq 452 size 56
00:27:02: Vi2 MLP-FS: I seq 453 size 56
00:27:02: Vi2 MLP-FS: I seq 454 size 56
00:27:02: Vi2 MLP-FS: I seq 455 size 56
00:27:02: Vi2 MLP-FS: I seq 456 size 56
00:27:02: Vi2 MLP-FS: I seq 457 size 56
00:27:02: Vi2 MLP-FS: I seq 458 size 56
00:27:02: Vi2 MLP-FS: I seq 459 size 56
00:27:02: Vi2 MLP-FS: I seq 45A size 56
00:27:02: Vi2 MLP-FS: I seq 45B size 56
00:27:02: Vi2 MLP-FS: I seq 45C size 56
00:27:02: Vi2 MLP-FS: I seq 45D size 56
00:27:02: Vi2 MLP-FS: I seq 45E size 56
00:27:02: Vi2 MLP-FS: I seq 45F size 56
00:27:02: Vi2 MLP-FS: I seq 460 size 56
00:27:02: Vi2 MLP-FS: I seq 461 size 56
00:27:02: Vi2 MLP-FS: I seq 462 size 56
00:27:02: Vi2 MLP-FS: I seq 463 size 56
00:27:02: Vi2 MLP-FS: I seq 464 size 56
00:27:02: Vi2 MLP-FS: I seq 40000465 size 40
00:27:02: Vi2 MLP: O seq 80000450 size 56
00:27:02: Vi2 MLP: O seq 451 size 56
00:27:02: Vi2 MLP: O seq 452 size 56
00:27:02: Vi2 MLP: O seq 453 size 56
00:27:02: Vi2 MLP: O seq 454 size 56
00:27:02: Vi2 MLP: O seq 455 size 56
00:27:02: Vi2 MLP: O seq 456 size 56
00:27:02: Vi2 MLP: O seq 457 size 56
00:27:02: Vi2 MLP: O seq 458 size 56
00:27:02: Vi2 MLP: O seq 459 size 56
00:27:02: Vi2 MLP: O seq 45A size 56
00:27:02: Vi2 MLP: O seq 45B size 56
00:27:02: Vi2 MLP: O seq 45C size 56
00:27:02: Vi2 MLP: O seq 45D size 56


Part V. Cisco Frame Relay Solutions for Congestion Avoidance and Signaling

Previous Page
Next Page

Part V: Cisco Frame Relay Solutions for Congestion Avoidance and Signaling

Chapter 21 Weighted Random Early Detection (WRED) for Frame Relay

Chapter 22 Resource Reservation Protocol (RSVP) for Frame Relay


Chapter 21. Weighted Random Early Detection (WRED) for Frame Relay

By now, readers should recognize the benefits of Quality of Service (QoS) features, such as traffic shaping, traffic policing or queuing, and how these QoS features help to improve the performance of Frame Relay services for mission-critical applications during congestion. Mission-critical traffic, such as Voice over IP (VoIP), is normally classified as higher-priority traffic because its delay-sensitive nature demands an improved level of QoS handling with consistent delay. In general, QoS features allow Frame Relay networks to provide improved and predictable services to mission-critical traffic.

The previous chapters discussed the congestion management QoS features with respect to queuing on Frame Relay networks. This chapter covers the Weighted Random Early Detection (WRED) feature for Frame Relay. WRED is a congestion avoidance QoS feature that provides early detection of congestion on the network. When traffic enters a router, the router, in an effort to avoid congestion, uses WRED to selectively discard packets forwarded on its egress interface as the router begins to experience congestion. The discard policy initiated by WRED can be configured to provide differentiated services for different classes of traffic.

This chapter begins with an overview of the WRED feature in general and explains how WRED can be used to provide congestion avoidance on a Frame Relay virtual circuit. Subsequently, this chapter looks at the Cisco IOS configuration tasks required to enable the WRED feature for a Frame Relay virtual circuit on a Cisco router. At the end of the chapter, the Cisco IOS show commands for monitoring and troubleshooting the WRED feature for Frame Relay networks are explained.

The topics and questions that this chapter addresses include the following:

  • Overview of WRED

  • WRED for Frame Relay

  • Configuring WRED for Frame Relay on a Cisco router

  • Monitoring and maintaining WRED on a Cisco router

After completing this chapter, readers will recognize the important benefits of WRED. Some of its benefits include providing early detection of congestion on the network and allowing the router to provide differentiated performance and services for different classes of traffic. Readers will become familiar with how WRED can be applied to a Frame Relay network. Following this, readers will learn how to configure WRED for Frame Relay on a Cisco router with the Cisco IOS software. Finally, readers will learn the relevant Cisco IOS show commands for monitoring and maintaining WRED for Frame Relay on a Cisco router.


Overview of Congestion Avoidance Mechanisms

This section provides an overview of the congestion avoidance mechanisms in the Cisco IOS software. This section also discusses the use and benefits of the supported congestion avoidance features. Congestion avoidance mechanisms help the network to monitor traffic loads and avoid congestion from building up at common network bottlenecks by initiating packet dropping. WRED and Tail Drop are the congestion avoidance techniques currently supported by the Cisco IOS software. WRED allows the network to provide differentiated services and to initiate a drop policy based on the IP precedence values of the packet headers. By contrast, Tail Drop treats all packets equally in its drop policy. Tail Drop and WRED are discussed in detail in subsequent sections. The next section talks about queue size associated with an output queue on an interface and how the size of this queue can be tuned.

Layer 3 Queues

In a Cisco router, each interface has a queue size associated with the output queue that indicates the number of packets that the queue can contain. When a router begins to experience congestion, the queue can quickly become congested, and the router has to initiate a drop policy to manage the packets in the queue. The congestion avoidance mechanism enabled on the interface controls the manner in which excess packets are dropped. The supported congestion avoidance mechanisms with regard to packet disposal are Tail Drop and WRED. Tail Drop is the default congestion avoidance mechanism. Tail Drop treats all packets as equal and does not provide differentiated services for different classes of traffic. Tail Drop is explained in the next section.

Every interface on a Cisco router has a default queue size associated with the queuing method used on the interface. The calculated queue size can also vary depending on the platform type. For example, a Fast Ethernet interface on a Cisco router with a bandwidth greater than E1 (2.048 Mbps) uses the default first-in, first-out (FIFO) queuing algorithm on the interface. The default size of the FIFO output queue is 40 packets. This is indicated by the show interface FastEthernet 0/0 command depicted in Example 21-1.

Example 21-1. The show interface Output of a Fast Ethernet Interface
Router#show interface FastEthernet 0/0
FastEthernet0/0 is up, line protocol is up
  Hardware is DEC21140A, address is 0005.0065.fc00 (bia 0005.0065.fc00)
  Internet address is 192.168.1.2/24
  MTU 1500 bytes, BW 100000 Kbit, DLY 100 usec,
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation ARPA, loopback not set
  Keepalive set (10 sec)
  Half-duplex, 100Mb/s, 100BaseTX/FX
  ARP type: ARPA, ARP Timeout 04:00:00
  Last input 00:00:03, output 00:00:00, output hang never
  Last clearing of "show interface" counters never
  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
  Queueing strategy: fifo
  Output queue: 0/40 (size/max)
  5 minute input rate 2000 bits/sec, 1 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
     48735 packets input, 14890396 bytes
     Received 47669 broadcasts, 0 runts, 0 giants, 0 throttles
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
     0 watchdog
     0 input packets with dribble condition detected
     18358 packets output, 2185553 bytes, 0 underruns
     62 output errors, 1 collisions, 17 interface resets
     0 babbles, 0 late collision, 0 deferred
     62 lost carrier, 0 no carrier
     0 output buffer failures, 0 output buffers swapped out

The size of the output queue on the interface can be tuned with the hold-queue interface configuration command. For other queuing methods, such as CBWFQ and LLQ, the queue size can be adjusted for a particular traffic class defined in the policy-map with the queue-limit command. Generally, when changing the size of the queue, the chosen queue size should not be excessively large or small. A queue with a large size or limit can lead to increased latency from excessive queuing. On the other hand, small queue size can lead to frequent drops, which can result in excessive retransmission at the upper-layer protocols, such as TCP.

Tail Drop

Before WRED was supported, Tail Drop was the default congestion avoidance technique on an interface of a Cisco router. With Tail Drop, all packets in the queues are treated equally; Tail Drop does not provide any differentiated treatment to the packets in the queues based on their associated classes of service. When congestion occurs and the queue becomes packed full, Tail Drop initiates packet drops for both high-priority and low-priority traffic without any regard to priority. Tail Drop continues to drop packets from the queues, and the packet drops occur until the congestion in the queues ease and the queues are no longer full. Figure 21-1 illustrates the Tail Drop process on an interface of a Cisco router.

Figure 21-1. Tail Drop Process

Random Early Detection (RED)

Random Early Detection (RED) is a queue management technique proposed by Sally Floyd and Van Jacobson in the early 1990s. RED is a congestion avoidance method used to manage congestion primarily on TCP/IP networks or on any other transport protocols that can temporarily throttle their transmission rate in response to packet drops. When RED is applied on a router interface, queue thresholds are defined for the output queue on the interface. When the network slowly becomes congested with traffic and the predetermined minimum threshold is exceeded, RED delivers implicit feedback to the TCP transmission source by randomly dropping packets from the queue. TCP detects the packet loss, knows that congestion has occurred, and then drives down its transmission rate. Thus, RED controls the average queue size by randomly dropping packets before the onset of high congestion.

The drop probability is based on the minimum threshold, the maximum threshold, and the mark probability denominator. The rate of packet drop is increased linearly as the average queue size increases until the maximum threshold is hit. The packet drop probability denominator is used to calculate the number of packets dropped when the average queue size is at the maximum threshold. For instance, with a packet drop probability denominator of 10, one out of every ten packets is dropped. Tail Drop still occurs when the average or mean queue size exceeds the maximum drop threshold level.

Transmission Control Protocol (TCP)

The effectiveness of RED depends heavily on the abilities of the data transport mechanism. For the most part, the transport protocol must be robust in response to packet loss. Transmission Control Protocol (TCP) has a robust congestion control mechanism, and it can quickly adapt its transmission rate to a tempo that the network can support. TCP can respond to packet loss by lowering its throughput rate with a smaller TCP transmission window one-half of the current size. This is triggered by the TCP back-off algorithm. When the congestion is cleared, TCP slowly increases its output rate but it can exponentially raise its output rate in an extended period of no-congestion. This is known as the TCP slow start algorithm. Most importantly, TCP is the most heavily used network transport protocol in use today and is most effective when used with RED as a congestion avoidance mechanism.

NOTE

RED should not be used with a transport protocol that is not robust in response to packet loss, such as AppleTalk.

WRED

WRED combines IP precedence with RED to provide differentiated treatment for packets with different IP precedence levels. WRED provides early detection of congestion in a similar way to RED, but it extends the capabilities of RED with a method for handling differentiated classes of traffic. WRED provides different maximum and minimum drop threshold levels based on the IP precedence value. Logically, the minimum drop threshold level is higher for traffic with a lower precedence, whereas packets with a higher precedence have a much higher minimum drop threshold level. In such a way, the lower precedence traffic is dropped before the higher precedence traffic becomes affected.

In most typical implementations, WRED is used at the core routers of a network. The edge routers provide a traffic classification function by assigning IP precedences to packets entering the network. The IP precedence values carried by the IP packets reflect the treatment the packets receive at the core routers with WRED.

Example 21-2 shows the WRED default parameters and packet drop statistics on a router interface, after WRED is enabled with the random-detect at the interface level.

Example 21-2. WRED Default Drop Parameters and Statistics
Router#show queueing random-detect
Current random-detect configuration:
  Serial2/2
    Queueing strategy: random early detection (WRED)
    Exp-weight-constant: 9 (1/512)
    Mean queue depth: 39

    Class     Random drop       Tail drop        Minimum   Maximum     Mark
    (Prec)    pkts/bytes        pkts/bytes      threshold threshold probability
        0      504/22176         1068/47114         20        40       1/10
        1        0/0                0/0             22        40       1/10
        2        0/0                0/0             24        40       1/10
        3        0/0                0/0             26        40       1/10
        4        0/0                0/0             28        40       1/10
        5        0/0                0/0             31        40       1/10
        6        0/0                0/0             33        40       1/10
        7        0/0                0/0             35        40       1/10
     rsvp        0/0                0/0             37        40       1/10

Observe in Example 21-2 that with WRED, each class of precedence has different default minimum drop threshold levels. The maximum drop threshold level is equal to the output hold queue size. When congestion builds up at the interface and the mean queue-depth steadily rises to between the maximum and minimum drop thresholds, WRED randomly drops packets that exceed the minimum drop thresholds corresponding to the packets' precedence levels. When the mean queue-depth is equal to the maximum drop threshold, WRED drops packets with a probability equal to the Mark probability. Finally, Tail Drop occurs when the mean queue-depth exceeds the maximum drop threshold. Also take note that when the minimum drop thresholds are configured so that they are all of equal value, WRED becomes the standard RED policy without any differentiated treatments for traffic.

Flow-Based WRED

A flow-based WRED is also supported on Cisco routers. Packets are classified into flows, based on parameters such as destination and source addresses and ports. Flow-based WRED maintains the state or count of the number of active flows, which have packets in the output queues. With this value and the output queue size, the number of buffers available per flow can be determined. Once a flow exceeds the per-flow limit, the statistical probability of a packet from the flow being dropped is increased. Flow-based WRED provides a greater fairness with regard to how packets are dropped.

WRED Support for Frame Relay

The WRED feature is supported for Frame Relay. It can be configured at the Frame Relay interface level or within the Class-Based Weighted Fair Queuing (CBWFQ) queuing structure based on traffic classes using Modular Quality of Service Command Line Interface (MQC).

On a Frame Relay network, WRED is used as a congestion avoidance policy to offer differentiated service levels to customers. For example, traffic with a precedence level of 0 has a much higher chance of being dropped on a congested connection than "premium" class traffic with a higher precedence level of 4.

Similar to the WRED feature, to avoid congestion, WRED support for Frame Relay depends on a robust higher layer transport protocol to respond to packet loss as an indicator to drop down the transmission rate.

The next section illustrates the main Cisco IOS configuration tasks needed to configure the WRED feature for Frame Relay or within the policy-map structure for enabling WRED with CBWFQ or LLQ.


Configuring WRED for Frame Relay

This section demonstrates the configuration tasks required to enable WRED for Frame Relay. WRED can be configured at the interface level or within the policy-map to initiate the WRED drop mechanism on a per-class basis for CBWFQ or LLQ.

Enabling WRED on an Interface

To enable WRED on an interface, use the following commands, beginning in the global configuration mode:

Step 1. | Enter the interface configuration mode of the Frame Relay interface on which you want to enable WRED.
Step 2. | Enable WRED with the random-detect interface configuration command.
Step 3. | (optional) Change the weight factor used in calculating the average queue length with random-detect exponential-weighting-constant exponent. An integer value between 1 and 16 is accepted.
Step 4. | (optional) Use the random-detect precedence precedence min-threshold max-threshold mark-prob-denominator interface configuration command to configure the parameters for packets with a specific IP precedence value. By default, the minimum threshold for IP precedence 0 corresponds to half the maximum threshold for the interface. The default output queue size is 40. Use this command to configure the parameter for each IP precedence value. Note that RED can be enabled by configuring the same values for each IP precedence class.
Step 5. | (optional) To enable flow-based WRED, first enable WRED and then flow-based WRED with random-detect flow interface configuration command. To adjust the flow threshold multiplier, use the random-detect flow average-depth-factor scaling-factor interface configuration command. To adjust the maximum flow count, use the random-detect flow count number interface configuration command.

Enabling WRED in a Traffic Policy

To enable WRED in a traffic policy within a CBWFQ structure, use the following commands, beginning in global configuration mode:

Step 1. | Enter the policy-map configuration mode by specifying the name of the traffic policy with the policy-map policy-map global configuration command.
Step 2. | In the policy-map, specify the name of traffic class with the class class-name command.
Step 3. | In the policy-map-class configuration mode, enable WRED with the random-detect command.
Step 4. | (optional) You can configure the parameters for IP precedence in WRED or turn on flow-based WRED using the same commands shown in the previous section, which described configuring WRED for the interface.

Scenario: Comparison of Tail Drop and WRED for Frame Relay

Figure 21-2 shows the network topology used in this scenario to observe the difference between Tail Drop and WRED for Frame Relay.

Figure 21-2. Network to Verify Tail Drop and WRED

[View full size image]

In Figure 21-2, routers R1 and R2 are connected to a low-speed Frame Relay network. The access speed of the Frame Relay connection is deliberately set to a slow 9600 bps so that congestion can be speedily built up and observed at router R1's egress interface. Two PCs are connected to the LAN segments attached to the routers, as shown in the diagram. The PCs are running a TCP Session Emulator application. One of them simulates a TCP client, and the other acts as a TCP server. When the Frame Relay is up and running, TCP connections are established between the PCs. This creates the TCP traffic required to achieve congestion, allowing the observation of WRED and Tail Drop in action.

The configurations of the routers in Figure 21-2 are shown in Example 21-3.

Example 21-3. Configurations of the Routers in Figure 21-2
! Router R1

<output omitted>

interface FastEthernet0/0
 ip address 10.0.0.1 255.255.255.0
!
interface Serial4/3
 no ip address
 encapsulation frame-relay
 no fair-queue
!
interface Serial4/3.102 point-to-point
 ip address 172.16.1.1 255.255.255.252
 frame-relay interface-dlci 102
!
router eigrp 1
 network 10.0.0.0 0.0.0.255
 network 172.16.1.0 0.0.0.3
 no auto-summary

! Router R2

<output omitted>

interface FastEthernet0/1
 ip address 10.0.1.1 255.255.255.0
!
interface Serial2/2
 no ip address
 encapsulation frame-relay
 no fair-queue
!
interface Serial2/2.201 point-to-point
 ip address 172.16.1.2 255.255.255.252
 frame-relay interface-dlci 201
!
router eigrp 1
 network 10.0.1.0 0.0.0.255
 network 172.16.1.0 0.0.0.3
 no auto-summary

The TCP Session Emulator running at the PCs is used to generate TCP traffic onto the network to emulate TCP session flows between a TCP client and a TCP server. The dozens of TCP connections initiated are sufficient to flood the slow 9.6 kbps Frame Relay link.

In the next section, when the TCP sessions are initiated between the PCs, observe the behavior of Tail Drop and WRED in response to a spike in traffic on router R2's serial interface.


Monitoring and Troubleshooting Tail Drop and WRED

The show interface privileged EXEC mode command can be used to display the queuing strategy used on the interface, as shown in Example 21-4.

Example 21-4. Output of show interface Command on Router R2
R2#show interface serial2/2
Serial2/2 is up, line protocol is up
  Hardware is CD2430 in sync mode
  MTU 1500 bytes, BW 128 Kbit, DLY 20000 usec,
     reliability 255/255, txload 11/255, rxload 1/255
  Encapsulation FRAME-RELAY, loopback not set
  Keepalive set (10 sec)
  LMI enq sent  123, LMI stat recvd 123, LMI upd recvd 0, DTE LMI up
  LMI enq recvd 0, LMI stat sent  0, LMI upd sent  0
  LMI DLCI 1023  LMI type is CISCO  frame relay DTE
  FR SVC disabled, LAPF state down
  Broadcast queue 0/64, broadcasts sent/dropped 286/0, interface broadcasts 266
  Last input 00:00:01, output 00:00:01, output hang never
  Last clearing of "show interface" counters 00:20:29
  Queueing strategy: fifo
  Output queue 0/40, 6107 drops; input queue 0/75, 0 drops
  5 minute input rate 0 bits/sec, 5 packets/sec
  5 minute output rate 6000 bits/sec, 21 packets/sec
     8524 packets input, 389129 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
     26433 packets output, 1174563 bytes, 0 underruns
     0 output errors, 0 collisions, 3 interface resets
     0 output buffer failures, 0 output buffers swapped out
     2 carrier transitions
     DCD=up  DSR=up  DTR=up  RTS=up  CTS=up

As shown in Example 21-4, FIFO is the queuing strategy in use, and the default output queue size is 40 packets.

Alternatively, the show queueing interface interface-number privileged EXEC mode command can be used to display the queuing strategy used on the interface. The shorter form of the command, show queueing, displays a summary of the queuing strategies in use by all interfaces on the router. Example 21-5 and Example 21-6 show the output of show queueing interface and show queueing, respectively.

Example 21-5. Output of show queueing interface Command
R2#show queueing interface serial2/2
Interface Serial2/2 queueing strategy: none

Example 21-6. Output of show queueing Command
R2#show queueing
Current fair queue configuration:

  Interface           Discard     Dynamic      Reserved
                      threshold   queue count  queue count
  Serial0/0           64          256          0
  Serial0/1           64          256          0
  Serial2/0           64          32           0
  Serial2/1           64          32           0
  Serial2/3           64          256          0
  Serial2/4           64          32           0
  Serial2/5           64          32           0
  Serial2/6           64          32           0
  Serial2/7           64          32           0

Current DLCI priority queue configuration:
Current priority queue configuration:
Current custom queue configuration:
Current random-detect configuration:

Monitoring Tail Drop and WRED

TCP sessions are now initiated between the TCP client and TCP server, and the behavior of Tail Drop and WRED are observed. Example 21-7 shows the output of show interface on router R2 after the TCP sessions are started.

Example 21-7. Output of show interface Command on Router R2 for Tail Drop
R2#show interface serial2/2
Serial2/2 is up, line protocol is up
  Hardware is CD2430 in sync mode
  MTU 1500 bytes, BW 128 Kbit, DLY 20000 usec,
     reliability 255/255, txload 15/255, rxload 5/255
  Encapsulation FRAME-RELAY, loopback not set
  Keepalive set (10 sec)
  LMI enq sent  23, LMI stat recvd 23, LMI upd recvd 0, DTE LMI up
  LMI enq recvd 0, LMI stat sent  0, LMI upd sent  0
  LMI DLCI 1023  LMI type is CISCO  frame relay DTE
  FR SVC disabled, LAPF state down
  Broadcast queue 0/64, broadcasts sent/dropped 54/0, interface broadcasts 50
  Last input 00:00:00, output 00:00:00, output hang never
  Last clearing of "show interface" counters 00:03:53
  Queueing strategy: fifo
  Output queue 31/40, 1642 drops; input queue 0/75, 0 drops
  5 minute input rate 3000 bits/sec, 7 packets/sec
  5 minute output rate 8000 bits/sec, 24 packets/sec
     1960 packets input, 89843 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
     5705 packets output, 254216 bytes, 0 underruns
     0 output errors, 0 collisions, 0 interface resets
     0 output buffer failures, 0 output buffers swapped out
     0 carrier transitions
     DCD=up  DSR=up  DTR=up  RTS=up  CTS=up

As observed in the output of the show interface command in Example 21-7, congestion has kicked in on interface serial2/2 on router R2. This is because an aggregate traffic throughput of approximately 11000 bps (33 packets per second in both ingress and egress directions) has been put onto the slow 9600 bps Frame Relay link. A large number of packets have been tail dropped from the output queue.

Next, WRED is activated on router R2's egress interface serial2/2 with the random-detect interface configuration command. When WRED is configured at the interface level, WRED acts on the Frame Relay interface. Then again, if CBWFQ is used, WRED can be configured with class-map inside the policy-map to use WRED as the congestion avoidance method for the specified class of traffic.

The counters on router R2 are cleared with the clear counter command, and the same TCP session configuration between the client and server PCs is restarted. Example 21-8 shows the output of the show interface command, and Example 21-9 shows the output of the show queueing random-detect command.

Example 21-8. Output of show interface Command on Router R2 for WRED
R2#show interface serial2/2
Serial2/2 is up, line protocol is up
  Hardware is CD2430 in sync mode
  MTU 1500 bytes, BW 128 Kbit, DLY 20000 usec,
     reliability 255/255, txload 15/255, rxload 5/255
  Encapsulation FRAME-RELAY, loopback not set
  Keepalive set (10 sec)
  LMI enq sent  24, LMI stat recvd 24, LMI upd recvd 0, DTE LMI up
  LMI enq recvd 0, LMI stat sent  0, LMI upd sent  0
  LMI DLCI 1023  LMI type is CISCO  frame relay DTE
  FR SVC disabled, LAPF state down
  Broadcast queue 0/64, broadcasts sent/dropped 55/0, interface broadcasts 51
  Last input 00:00:00, output 00:00:00, output hang never
  Last clearing of "show interface" counters 00:03:57
  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 1605
  Queueing strategy: random early detection(RED)
  5 minute input rate 3000 bits/sec, 8 packets/sec
  5 minute output rate 7000 bits/sec, 23 packets/sec
     1954 packets input, 88628 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
     5778 packets output, 256362 bytes, 0 underruns
     0 output errors, 0 collisions, 0 interface resets
     0 output buffer failures, 0 output buffers swapped out
     0 carrier transitions
     DCD=up  DSR=up  DTR=up  RTS=up  CTS=up

Example 21-9. Output of show queueing random-detect Command on Router R2
R2#show queueing random-detect
Current random-detect configuration:
  Serial2/2
    Queueing strategy: random early detection (WRED)
    Exp-weight-constant: 9 (1/512)
    Mean queue depth: 39

    Class     Random drop       Tail drop        Minimum   Maximum     Mark
    (Prec)    pkts/bytes        pkts/bytes      threshold threshold probability
        0      504/22176         1068/47114         20        40       1/10
        1        0/0                0/0             22        40       1/10
        2        0/0                0/0             24        40       1/10
        3        0/0                0/0             26        40       1/10
        4        0/0                0/0             28        40       1/10
        5        0/0                0/0             31        40       1/10
        6        0/0                0/0             33        40       1/10
        7        0/0                0/0             35        40       1/10
     rsvp        0/0                0/0             37        40       1/10

The output of the show interface command in Example 21-8 now indicates that the queuing strategy used is RED.

In these observations, WRED starts dropping packets randomly within the first 10 seconds after the onset of TCP traffic. This happens when the mean queue-depth exceeds the minimum drop threshold level. On the other hand, Tail Drop discards packets only after the output hold queue is fully congested. With Tail Drop, packet drops are observed at the interface after approximately 15 seconds. By randomly dropping packets from the queue, WRED distributes the packet losses in time and absorbs the spikes. With sustained congestion, the mean queue-depth eventually exceeds the maximum drop threshold level, and WRED uses Tail Drop until the mean queue-depth falls below the maximum drop threshold level again. This is shown in Example 21-9.

Finally, notice again in the output of Example 21-9, all the packets dropped by WRED fall under the class precedence 0. By default, all untagged traffic has IP precedence 0. However, when the router R2 receives packets tagged with different classes of services on the congested interface (by means of different IP precedence levels), packets with a higher precedence have a lower chance of being dropped when compared with packets with a lower precedence.


Summary

This chapter talked about the congestion avoidance techniques supported on Cisco routers to monitor and manage traffic loads and to avoid congestion at the network bottlenecks. By dropping packets, Tail Drop and RED provide the means to avoid congestion.

Tail Drop, the default congestion avoidance mechanism if WRED is not enabled, treats all packets equally without providing any differentiated services between the different classes of traffic. Tail Drop discards packets from the output queue when the queue becomes filled.

By contrast, the WRED congestion avoidance technique allows the router to selectively discard packets based on the IP precedence values assigned to the packets when the router begins to experience congestion. WRED provides differentiated treatment for different classes of service. Normally, it ensures that the standard or low-priority packets are discarded before the higher-priority packets. In a Frame Relay environment, WRED can be applied to the main interface or directly to a Frame Relay PVC with CBWFQ or LLQ in a policy-map.

This chapter also discussed the Cisco IOS configuration tasks required to enable Tail Drop and WRED for Frame Relay on a Cisco router. Then this chapter demonstrated the relevant Cisco IOS show commands for monitoring and maintaining Tail Drop and WRED for Frame Relay on Cisco routers.

In the next chapter, the Resource Reservation Protocol (RSVP) Support for Frame Relay feature is discussed.


Review Questions

1: | How do RED and WRED compare?
2: | Explain why WRED is most useful with TCP protocol traffic.
3: | What is the default queuing method used on an interface with speed greater than E1 (2.048 Mbps)?
4: | What Cisco IOS show command can be used to verify the queuing method used on an interface?
5: | What is the Cisco IOS configuration command to enable FIFO queuing?


References

  • Cisco IOS 12.1 Release Documentation, Congestion Avoidance Overview: http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121cgcr/qos_c/qcprt3/qcdconav.htm

  • Cisco IOS 12.1(5)T Release Documentation, DiffServ Compliant Weighted Random Early Detection: http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121newft/121t/121t5/dtdswred.htm


Chapter 22. Resource Reservation Protocol (RSVP) for Frame Relay

This chapter covers the Resource Reservation Protocol (RSVP) feature and its supported use on Frame Relay networks. RSVP is a signaling QoS feature that provides Call Admission Control to allow end systems or hosts located on either side of a network to establish a reserved-bandwidth path between them. In such a way, the quality of service (QoS) for real-time applications between the end systems is ensured.

This chapter begins with a general overview of the RSVP feature and subsequently focuses on RSVP support for Frame Relay. The focus of this chapter is to explain the major configuration tasks required for setting up an RSVP reserved-bandwidth path on a Frame Relay network. In addition, the Cisco IOS show commands for monitoring and maintaining the RSVP feature on a Frame Relay network are covered.

The topics and questions that this chapter addresses include the following:

  • General overview of RSVP

  • RSVP support for Frame Relay and the benefits of the RSVP feature on a Frame Relay network

  • Configuring RSVP support for Frame Relay on a Cisco router

  • Monitoring and maintaining RSVP support for Frame Relay on a Cisco router

After completing this chapter, readers will recognize the benefits of the RSVP feature and become familiar with its use on Frame Relay networks. Readers will become familiar with the Cisco configuration commands required to enable RSVP support for Frame Relay on a Cisco router. Readers will also recognize the Cisco IOS show commands for monitoring and maintaining RSVP for Frame Relay on a Cisco router.


General Overview of RSVP

This section addresses the characteristics of real-time interactive traffic and standard data traffic on the network and discusses the QoS requirements of each major type of traffic. This section also introduces the RSVP feature and describes how it allows end systems to request QoS guarantees from the network.

Standard Data Traffic Versus Real-Time Traffic

The emergence of voice traffic into traditional data networks has made it very common to see both voice and standard data traffic sharing the same network resources. However, both forms of traffic have different characteristics and distinctive requirements.

Standard data traffic is typically composed of traffic on the network that is not real-time sensitive in nature. A common example of standard data traffic is LAN-to-LAN file transfers. Data traffic typically relies on an underlying datagram service for transport and does not require consistent network latency to ensure good application performance.

During congestion of the transport network, the end hosts or application-level software provide the necessary flow controls to recover from packet loss or delay. By contrast, real-time and interactive traffic are composed of traffic that is intolerant to network latency, delay, packet loss, and jitters. Real-time traffic, such as voice and video information, requires consistent network latency in order to prevent signal delay or loss. The failure of consistent network latency can result in the distortion and quality degradation of the audio signal or video image. Similarly, interactive traffic, such as Telnet or SSH, requires a consistent degree of network delay to ensure an acceptable level of performance.

As such, the stringent requirements of real-time and interactive traffic are very different from those required by standard data traffic. RSVP provides a QoS signaling mechanism that allows end systems to request QoS guarantees from the network for real-time and interactive traffic.

Bandwidth Reservation Service

The RSVP protocol is a QoS signaling mechanism that provides an IP service to allow end systems or hosts running real-time applications to establish a reserved bandwidth path between the sender and receiver. RSVP signals are exchanged across the network to allocate resources required by the applications from the pool of available bandwidth on the network. This prevents large data file transfers from impairing the available resources on the network and ensures a consistent latency for real-time traffic.

RSVP can work in conjunction with other QoS features that also reserve bandwidth, such as Class-Based Weighted Fair Queuing (CBWFQ) or IP Real-Time Protocol (RTP) priority. For instance, Weighted Fair Queuing (WFQ) can coexist with RSVP on the same interface. RSVP can use the WFQ queuing algorithm to ensure QoS for its data flows. When you enable multiple bandwidth reserving features, portions of the interface's available pool of bandwidth are assigned to each of these features. An internal interface-based or PVC-based bandwidth manager manages the pool of available bandwidth and prevents the aggregate amount of bandwidth reserved by these features from oversubscribing the interface or PVC. The available pool of bandwidth can be verified with the show queue type num privileged EXEC command, as shown in Example 22-1.

Example 22-1. Output of show queue type num Command
Router#show queue serial2/3
  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 18572278
  Queueing strategy: weighted fair
  Output queue: 0/1000/64/18572268 (size/max total/threshold/drops)
     Conversations  0/3/256 (active/max active/max total)
     Reserved Conversations 0/0 (allocated/max allocated)
     Available Bandwidth 96 kilobits/sec

By default, the pool of bandwidth available to the interface is 75 percent of the total bandwidth of the interface. However, this pool of bandwidth available to the interface can be configured via the max-reserved-bandwidth interface configuration command. A configuration example is shown in Example 22-2.

Example 22-2. Changing the Available Bandwidth at the Interface with max-reserved-bandwidth Command
Router#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z
Router(config)#interface serial2/3
Router(config-if)#max-reserved-bandwidth 100
Reservable bandwidth is being reduced
Some existing reservations may be terminated.
Router(config-if)#
Router#show queue serial2/3
  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 18572078
  Queueing strategy: weighted fair
  Output queue: 0/1000/64/18572268 (size/max total/threshold/drops)
     Conversations  0/3/256 (active/max active/max total)
     Reserved Conversations 0/0 (allocated/max allocated)
     Available Bandwidth 128 kilobits/sec

In Example 22-2, the total bandwidth available at the interface is 128 kbps. By default, 96 kbps (75 percent) is available for use by bandwidth-reserving QoS features configured at the interface. The max-reserved-bandwidth configuration command changes this to 100 percent, and all bandwidth available can now be reserved.

Unlike other bandwidth-reserving QoS features, such as CBWFQ or Low Latency Queuing (LLQ), RSVP does not automatically reserve any bandwidth when it is configured. When a traffic flow that meets the RSVP reservation criteria arrives at the router, RSVP attempts to reserve bandwidth out of the remaining pool of available bandwidth.


RSVP Support for Frame Relay

The RSVP Support for Frame Relay feature allows RSVP to be configured at the Frame Relay PVC level for better management of congestion, in conjunction with Frame Relay Traffic Shaping and its associated per-VC queuing features.

NOTE

The RSVP Support for Frame Relay feature was released in Cisco IOS Software Release 12.1(5)T.

Common queuing features, such as WFQ, can be configured at the interface or VC level to manage congestion on a router. However, in a Frame Relay environment, the congestion point is most often at the PVC level instead of the interface level, largely because of the bandwidth limitations enforced by the committed information rate (CIR).

The CIR is the sending rate at which traffic traversing a Frame Relay network is guaranteed its delivery. When a Frame Relay network is oversubscribed, the CIR is exceeded and packets might be dropped as a result of congestion. As such, if packets are dropped from a real-time voice traffic flow, the packet loss can adversely affect the voice quality of the transmission. Therefore, the Frame Relay Traffic Shaping feature is configured on the Frame Relay interface to prevent the outbound traffic rate from exceeding the configured CIR value. For example, oversubscription can happen when the sum of the RSVP traffic and other traffic exceeds the CIR.

At the same time, per-VC queuing features, such as fancy queuing (PQ and CQ), WFQ, CBWFQ, and LLQ, can be used on the VC to provide QoS guarantees for the traffic. RSVP can coexist with other QoS features on the VC to reserve bandwidth and enforce QoS. When multiple bandwidth-reserving features, such as LLQ and CBWFQ, are concurrently configured, the bandwidth is assigned and reserved at the time of configuration. This bandwidth is deducted from the pool of available bandwidth managed by the bandwidth manager. However, if the configured bandwidth exceeds the pool of available bandwidth, the command is rejected. RSVP, on the other hand, performs bandwidth reservation only at the time of arrival of the RSVP traffic. RSVP attempts to reserve its required bandwidth from the bandwidth remaining in the pool.

Benefits of RSVP Protocol Support for Frame Relay

RSVP provides several important benefits to its users, such as those listed here:

  • If the minimum CIR (MINCIR) is defined, RSVP can provide admission control based on the MINCIR value defined for the VC, instead of the amount of bandwidth available on the interface (which is, by default, 75 percent of the total bandwidth).

  • RSVP allows resources to be reserved at the Frame Relay VC level, which is the point of congestion, to enforce QoS for high-priority traffic.

  • RSVP supports both point-to-point and multipoint Frame Relay subinterfaces. This allows deployment of services such as Voice over IP (VoIP).

  • RSVP can coexist with CBWFQ and IP RTP priority bandwidth-reserving features. These features consult with the bandwidth manager during bandwidth reservation to prevent oversubscription.

  • RSVP, which is an IP service, can now be integrated into a Frame Relay environment to provide QoS enforcement on a per-VC basis.

The next section discusses the major configuration tasks involved in establishing a reserved-bandwidth path using the RSVP Support for Frame Relay feature.


Configuring RSVP Support for Frame Relay

This section explains the major configuration tasks involved in establishing a reserved-bandwidth path via the RSVP Support for Frame Relay feature between two users on a Frame Relay network.

To enable RSVP Support for Frame Relay, perform the configuration steps described below, beginning from the global configuration mode. Note that some configuration steps are listed as optional.

Step 1. | Enter the interface configuration mode of the Frame Relay interface and enable Frame Relay encapsulation with the encapsulation frame-relay interface configuration command. As required, create a point-to-point or multipoint subinterface under the main Frame Relay interface.
Step 2. | For a point-to-point subinterface, assign a Frame Relay DLCI to the subinterface with the frame-relay interface-dlci dlci interface configuration command. For a multipoint subinterface or the physical interface with multiple VCs, use the frame-relay map ip ip-address dlci [broadcast] command.
Step 3. | Enable Frame Relay Traffic Shaping with the frame-relay traffic-shaping interface configuration command on the physical interface. This enables FRTS and per-VC queuing for all PVCs and SVCs on the Frame Relay interface.
Step 4. | (optional) Enable the LMI type on the Frame Relay interface with the frame-relay lmi-type command. With Cisco IOS release 11.2, by default, the Frame Relay interface performs Local Management Interface (LMI) autosense.
Step 5. | Enable RSVP on the Frame Relay interface and subinterface with the ip rsvp bandwidth reserve-bandwidth-in-kbps largest-reserve-bandwidth-in-kbps interface configuration command. If subinterfaces are used, this command must be configured for the subinterfaces.
Step 6. | Configure Frame Relay Traffic Shaping parameters in a Frame Relay map-class with the map-class frame-relay map-class-name command. Within the Frame Relay map class, define the incoming or outgoing CIR for the Frame Relay PVC with the frame-relay cir {in|out} bps map-class configuration command.
Step 7. | (optional) Configure the Frame Relay MINCIR value in the Frame Relay map class with frame-relay mincir {in|out} bps map-class configuration command. When MINCIR is defined, RSVP can provide admission control based on the MINCIR value defined for the VC.
Step 8. | Configure WFQ in the Frame Relay map class with frame-relay fair-queue map-class configuration command. This turns on fair-queuing for the RSVP traffic flows on the PVC.
Step 9. | Configure FRF.12 Fragmentation for the Frame Relay PVC with the frame-relay fragment fragment-size map-class configuration command. This turns on FRF.12 class-based fragmentation on the Frame Relay PVC.
Step 10. | Associate the configured Frame Relay map class to the Frame Relay PVC with the frame-relay class class-name interface configuration command at the physical or subinterface level.

Verifying RSVP Support for Frame Relay

The examples in this section show a scenario in which the RSVP Support for Frame Relay feature is set up on the Frame Relay network depicted in Figure 22-1 with the configuration commands shown. The configurations on the routers are shown in Example 22-3.

Example 22-3. Configurations of Routers in Figure 22-1
! Router R1

<output omitted>

interface FastEthernet0/0
 ip address 10.0.0.1 255.255.255.0
!
interface Serial4/2
 no ip address
 encapsulation frame-relay
 frame-relay traffic-shaping
 ip rsvp bandwidth 96 96
!
interface Serial4/2.102 point-to-point
 ip address 172.16.1.1 255.255.255.252
 frame-relay interface-dlci 102
  class rsvp
 ip rsvp bandwidth 64 64
!
interface Serial4/2.103 multipoint
 ip address 172.16.2.1 255.255.255.240
 ip ospf network broadcast
 frame-relay class rsvp_p2mp
 frame-relay map ip 172.16.2.2 103 broadcast
 ip rsvp bandwidth 32 32
!
!
router ospf 1
 network 10.0.0.0 0.0.0.255 area 0
 network 172.16.1.0 0.0.0.3 area 0
 network 172.16.2.0 0.0.0.15 area 1
!
map-class frame-relay rsvp
 frame-relay cir 256000
 no frame-relay adaptive-shaping
 frame-relay fair-queue
 frame-relay fragment 200
!
map-class frame-relay rsvp_p2mp
 frame-relay cir 128000
 no frame-relay adaptive-shaping
 frame-relay fair-queue
 frame-relay fragment 200

! Router R2

<output omitted>

interface FastEthernet0/0
 ip address 20.0.0.2 255.255.255.0
!
interface Serial5/2
 no ip address
 encapsulation frame-relay
 frame-relay traffic-shaping
 ip rsvp bandwidth 64 64
!
interface Serial5/2.201 point-to-point
 ip address 172.16.1.2 255.255.255.252
 frame-relay interface-dlci 201
  class rsvp
 ip rsvp bandwidth 64 64
!
router ospf 1
 log-adjacency-changes
 network 20.0.0.0 0.0.0.255 area 0
 network 172.16.1.0 0.0.0.3 area 0
!!
!
map-class frame-relay rsvp
 frame-relay cir 256000
 no frame-relay adaptive-shaping
 frame-relay fair-queue
 frame-relay fragment 200

! Router R3

<output omitted>

interface FastEthernet1/0
 ip address 30.0.0.1 255.255.255.0
!
interface Serial1/2
 no ip address
 encapsulation frame-relay
 frame-relay traffic-shaping
 ip rsvp bandwidth 32 32
!
interface Serial4/2.301 multipoint
 ip address 172.16.2.2 255.255.255.240
 ip ospf network broadcast
 frame-relay class rsvp
 frame-relay map ip 172.16.2.1 301 broadcast
 ip rsvp bandwidth 32 32
!
!
router ospf 1
 network 30.0.0.0 0.0.0.255 area 1
 network 172.16.2.0 0.0.0.15 area 1
!
!
map-class frame-relay rsvp
 frame-relay cir 128000
 no frame-relay adaptive-shaping
 frame-relay fair-queue
 frame-relay fragment 200

Figure 22-1. Verifying RSVP Support for Frame Relay

In the configurations shown in Example 22-3, RSVP is configured to set up reserved-bandwidth paths between the routers on the Frame Relay network. For instance, between router R1 and R2, up to 64 kbps of bandwidth can be reserved by end systems or hosts on either side.

The next section demonstrates the commands for monitoring and troubleshooting RSVP Support for Frame Relay.


Monitoring and Troubleshooting RSVP Support for Frame Relay

Using the configured setup in Figure 22-1, this section looks at some commands that can be used to verify RSVP Support for Frame Relay. Because there are no explicit end systems available in this setup for setting up the reserved path, the Cisco IOS RSVP commands ip rsvp sender-host and ip rsvp reservation-host are used. These commands allow routers R1 and R2 to simulate RSVP PATH and RESV messages on the Frame Relay network and allow RSVP to be fully illustrated.

Example 22-4 shows the configuration commands needed to add on routers R1 and R2 for this purpose.

Example 22-4. Using ip rsvp sender-host and ip rsvp reservation-host to Routers R1 and R2
! Router R1

R1(config)# ip rsvp sender-host 20.0.0.2 10.0.0.1 udp 7000 7001 16 1

! Router R2

R2(config)# ip rsvp reservation-host 20.0.0.2 10.0.0.1 UDP 7000 7001 FF LOAD 16 1

The ip rsvp sender-host command causes router R1 to simulate an IP RSVP sender-host located at 10.0.0.1, which is requesting an RSVP reserved bandwidth path of 16 kbps to 20.0.0.2 on UDP port numbers 7000 and 7001. The ip rsvp reservation-host command is configured on router R2 to accept and reserve a bandwidth of 16 bps on UDP port numbers 7000 and 7001.

The next examples illustrate several show commands that can be used to verify RSVP operation on the routers.

The show ip rsvp neighbor command can be used to verify the immediate RSVP neighbor, as shown in Example 22-5, which is executed on router R2.

Example 22-5. Output of show ip rsvp neighbor Command
R2#show ip rsvp neighbor
Interfac Neighbor        Encapsulation
Se5/2.20 172.16.1.1      RSVP

The show ip rsvp interface command can be used to display the current active RSVP reservations on the routers' RSVP-enabled interfaces. An example is shown in Example 22-6.

Example 22-6. Output of show ip rsvp interface Command
R1#show ip rsvp interface
interface    allocated  i/f max  flow max pct UDP  IP   UDP_IP   UDP M/C
Se4/2        16K        96K      96K      16  0    0    0        0
Se4/2.102    16K        64K      64K      25  0    1    0        0
Se4/2.103    0M         32K      32K      0   0    0    0        0

In addition, the show ip rsvp installed and show ip rsvp installed detail commands can be used to display information about interfaces and their admitted reservations. Both commands are shown in Example 22-7 and Example 22-8.

Example 22-7. Output of show ip rsvp installed at Router R1
R1#show ip rsvp installed
RSVP: Serial4/2.102
BPS    To              From            Protoc DPort  Sport
16K    20.0.0.2        10.0.0.2        UDP    7000   7001
RSVP: Serial4/2.103 has no installed reservations

Example 22-8. Output of show ip rsvp installed detail at Router R1
R1#show ip rsvp installed detail

RSVP: Serial4/2 has the following installed reservations

RSVP: Serial4/2.102 has the following installed reservations
RSVP Reservation. Destination is 20.0.0.2, Source is 10.0.0.2,
  Protocol is UDP, Destination port is 7000, Source port is 7001
  Reserved bandwidth: 16K bits/sec, Maximum burst: 1K bytes, Peak rate: 16K bits/sec
  QoS provider for this flow:
    WFQ on FR PVC dlci 102 on Se4/2:  RESERVED queue 25.  Weight: 6
  Conversation supports 1 reservations
  Data given reserved service: 0 packets (0M bytes)
  Data given best-effort service: 0 packets (0 bytes)
  Reserved traffic classified for 1805 seconds
  Long-term average bitrate (bits/sec): 0M reserved, 0M best-effort
RSVP: Serial4/2.103 has no installed reservations


Summary

This chapter discussed the RSVP protocol, which is an IP service for end systems or hosts located on either side of a network to establish a reserved-bandwidth path between them. This chapter presented an overview of the RSVP protocol and described its use on a Frame Relay network, which is available with the RSVP Support for Frame Relay feature. This chapter showed the major Cisco IOS configuration tasks involved in configuring RSVP Support for Frame Relay on a Cisco router. It also explained the relevant Cisco IOS show commands for monitoring and maintaining RSVP Support for Frame Relay on a Cisco router.


Review Questions

1: | What is the main purpose of using RSVP with real-time interactive traffic?
2: | How much bandwidth is available for RSVP by default?
3: | What is the Cisco IOS command that allows users to change the default amount of bandwidth available for RSVP?
4: | What is the Cisco IOS command to verify the bandwidth available in the bandwidth pool?


Reference

Cisco IOS Release 12.1(5)T Documentation, RSVP Support for Frame Relay: http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121newft/121t/121t5/rsvp_fr.htm


Appendix A. Answers to Review Questions

    Chapter 1

    Chapter 2

    Chapter 3

    Chapter 4

    Chapter 5

    Chapter 6

    Chapter 7

    Chapter 8

    Chapter 9

    Chapter 10

    Chapter 11

    Chapter 12

    Chapter 13

    Chapter 14

    Chapter 15

    Chapter 16

    Chapter 17

    Chapter 18

    Chapter 19

    Chapter 20

    Chapter 21

    Chapter 22


Chapter 1

1: | What is Frame Relay?
A1: | Frame Relay is a high-speed packet-switched technology for interconnecting geographically dispersed LANs or WANs via a shared network. To minimize protocol overheads associated with legacy WAN technology such as X.25, Frame Relay does not perform any error correction functions at the data-link layer where it operates. Rather, Frame Relay relies on upper-layer protocols to recover from errors or loss of frames. The Frame Relay header only supports a CRC field to detect corrupted frames. Hence, Frame Relay requires a reliable physical layer transport medium.
2: | What is a virtual circuit?
A2: | A virtual circuit is an end-to-end logical connection between two end points set up by the Frame Relay carrier for data transfer. Virtual circuits can be permanent virtual circuits (PVCs) or switched virtual circuits (SVCs).
3: | What are the differences between a PVC and an SVC?
A3: | A PVC is a permanent logical network connection that does not terminate or tear down after the transfer of data is complete. An SVC has to be set up before data transfer can take place. The SVC is torn down after the transfer of data is complete or the connection is idle after some time.
4: | What is the CIR?
A4: | The CIR is the rate measured in bits per second at which a Frame Relay carrier agrees to transfer information under normal conditions, averaged over a minimum increment of time.


Chapter 2

1:

What are the main differences between DTE and DCE devices in a Frame Relay network?

A1:

A DTE device does not provide clocking and requires the clocking signals provided by a connected DCE device. A router is an example of a DTE device. A Frame Relay switch is an example of a DCE device that provides clocking signals to synchronize with connected Frame Relay access devices.

2:

List the most common industry cabling standards used for connecting serial interfaces to a Frame Relay network.

A2:

EIA/TIA-232, EIA/TIA-449, EIA/TIA-530, V.35, and X.21 are among the most popular cabling standards used for Frame Relay serial connections.

3:

What is global addressing?

A3:

DLCI is local significant. Global addressing assigns a unique DLCI to each Frame Relay DTE device on a Frame Relay network. The DLCI is used to uniquely identify each node on the Frame Relay network. Unlike local significant addressing, global addressing does not allow an assigned DLCI to be reused in any other parts of the network.

4:

Name the Frame Relay encapsulations supported by the Cisco IOS.

A4:

Cisco proprietary encapsulation and IETF (RFC 1490). The default encapsulation type used is Cisco.

5:

What are the main functionalities of Frame Relay multicasting and Inverse ARP?

A5:

Frame Relay multicasting conserves bandwidth and allows only the "interested" Frame Relay hosts to receive and process the transmitted multicast frames.

Inverse ARP provides a dynamic network layer address to Frame Relay DLCI address mapping. On a physical interface with multiple DLCIs configured, Inverse ARP allows the routers to learn the remote network layer address corresponding to each local DLCI address.


Chapter 3

1:

What are the three key factors that affect network planning?

A1:

The three factors identified as critical to successful network planning are knowledge of users' requirements, knowledge of the protocol mix, and knowledge of network traffic patterns.

2:

What are the different network topologies, and which is the most commonly seen for Frame Relay networks?

A2:

Star topology, fully meshed topology, and partially meshed topology are three network topologies. Star topology is also a subset of partially meshed topology. Star topology, also known as hub and spoke, is the most popular topology used in Frame Relay networks because it is the most cost effective.

3:

What are the types of traffic that are usually given the highest preference for handling and transmission?

A3:

Real-time traffic such as voice and video has very little tolerance for jitters, latency, and drops. As such, real-time traffic requires minimum delay and is usually given the highest preference for handling and transmission.

4:

What are the available options for backing up a Frame Relay virtual circuit?

A4:

A redundant Frame Relay virtual circuit can be provisioned to provide an active backup for the main Frame Relay virtual circuit. An ISDN dial-on-demand circuit can be used to provide backup in the event that the primary Frame Relay circuit fails.

5:

What is split horizon? How can split horizon be overcome on a partially meshed Frame Relay NBMA network?

A5:

Split horizon is used to prevent route instabilities on a network by preventing route updates learned on an interface from being advertised out on the same interface. Split horizon is a problem for dynamic distance vector routing protocols on Frame Relay NBMA networks, because a router is unaware that multiple logical virtual circuits can be multiplexed onto a single physical interface. IGRP and RIP are examples of dynamic distance vector routing protocols that face the split horizon issues on a Frame Relay NBMA network.

Split horizon can be overcome by using logical Frame Relay subinterfaces. Alternatively, dynamic link-state routing protocols, such as OSPF and ISIS, can be used on an NBMA Frame Relay network. Both OSPF and ISIS are aware of the entire topology of the network and are not affected by the split horizon issue.


Chapter 4

1:

What is the Cisco IOS command required for enabling Frame Relay encapsulation on an interface?

A1:

The Cisco IOS command to enable Frame Relay encapsulation on an interface is encapsulation frame-relay [ietf]. The ietf keyword is optional, and if it is not specified as part of the command, by default the Cisco encapsulation type is used.

2:

What are the differences between static and dynamic address mapping?

A2:

Static address mapping is created in the Frame Relay address-to-DLCI map table when the user manually sets up the static mapping with the frame-relay map configuration command. Unlike dynamic mappings, static mappings cannot be cleared in the Frame Relay map table using the clear frame-relay inarp command. A static mapping remains in the Frame Relay map table until the user manually deletes the static mapping with the no form of the frame-relay map command.

By contrast, dynamic mapping, also known as Inverse ARP, is enabled by default. Inverse ARP automatically performs the remote network layer address to local DLCI mapping and populates the resolved entries in the Frame Relay map table. Static mapping is required to provide spoke-to-spoke reachability on a hub-and-spoke Frame Relay network.

3:

What is the global configuration command required to configure a Cisco router as a Frame Relay switch?

A3:

The command frame-relay switching in the global configuration mode is required to enable Frame Relay switching functionalities on a Cisco router. To set up a Cisco router as a Frame Relay switch, it is necessary to configure the interfaces on the Frame Relay switch as a DCE device with the frame-relay intf-type dce command. The final frame-relay route command sets up the Frame Relay PVC switch connections.

4:

What is the command used for monitoring the contents of the address-to-DLCI mapping table?

A4:

The command is show frame-relay map.

5:

What is the debug command used for analyzing the details of the packets sent out of an interface on a specific DLCI?

A5:

The command is debug frame-relay packets.


Chapter 5

1:

Name and explain the algorithm that Frame Relay Traffic Shaping uses to perform rate enforcement of traffic.

A1:

Frame Relay Traffic Shaping uses the leaky bucket algorithm to implement rate enforcement of traffic. The leaky bucket contains a capacity of Bc + Be tokens. In one time interval (Tc), a Bc amount of tokens is replenished and added to the bucket. When the bucket is full, no further tokens are added, and the excess tokens are discarded. When data is transmitted, an amount of tokens equivalent to the data is subtracted from the bucket. When there are insufficient tokens in the bucket, user data is delayed and buffered.

2:

Identify the queuing components supported by Frame Relay Traffic Shaping.

A2:

The queuing components supported by Frame Relay Traffic Shaping are FIFO (default), priority queuing (PQ), and custom queuing (CQ). In the newer Cisco IOS 12.1T Releases, WFQ, CBWFQ and LLQ are supported.

3:

Explain the method to set up different traffic shaping parameters for different Frame Relay PVCs.

A3:

Frame Relay Traffic Shaping parameters are set up in the Frame Relay map-class configurations. Different map classes can be configured for different Frame Relay DLCIs. A Frame Relay map class is associated with a DLCI under the physical or multipoint subinterface DLCI via the frame-relay class map-class-name command. To associate a map class with a DLCI under a point-to-point subinterface, use the class vc-map-class-name command.

4:

Explain the main differences between adaptive shaping to BECN and adaptive shaping to ForeSight.

A4:

Adaptive shaping to BECN detects the presence of BECN-tagged frames received from a congested Frame Relay network. It depends on user traffic being tagged with the BECN bit and being sent in the opposite direction of the traffic, causing congestion.

A Frame Relay switch configured for adaptive shaping to Foresight uses Foresight messages to signal the congested state directly to the router. It does not rely on the presence of user-tagged traffic.


Chapter 6

1: | What are the differences between legacy Frame Relay switching using the frame-relay route interface command and the global connect command in the new switching capability offered by the Frame Relay switching enhancements feature?
A1: | The frame-relay route command enables a Cisco router to switch frames received on an incoming DLCI and ingress interface to an outgoing DLCI and egress interface. It does not support enhanced switching capabilities provided by a dedicated Frame Relay switch, such as policing and shaping. The connect command allows a Cisco router to set up sophisticated switching functionalities provided by the Frame Relay switching feature.
2: | What is the purpose of switched PVC, and what is the command and keyword required to set up the switched PVC on a Frame Relay switch?
A2: | Switched PVC is part of the new Frame Relay Switching Enhancements feature and is required to support Frame Relay switching on a Cisco router. On a Cisco router configured as a Frame Relay switch, a PVC is created with the existing frame-relay interface-dlci command, but the switched keyword is now available to specify the created DLCI as a switched PVC.
3: | What are the levels of congestion management supported by the Frame Relay Switching Enhancements feature?
A3: | Frame Relay congestion management can be set up at the individual switched PVC level or at the interface level.
4: | What are the steps required to set up congestion management on the Frame Relay switch?
A4: | Frame Relay congestion management allows a Frame Relay switch to define a threshold percentage pegged at the output queue size. Two types of threshold are supported: ECN threshold and DE threshold. When the queue level is at or above the ECN threshold, BECN and FECN bits are set in the frames crossing the PVC or interface. When the queue level is at or above the DE threshold, arriving frames with DE bits tagged are discarded.
5: | Identify the configuration mode and command required to enable Frame Relay traffic policing.
A5: | The frame-relay policing command is required to be configured on the incoming interface at the interface level.


Chapter 7

1: | Name the possible problems that can be averted by using Frame Relay End-to-End Keepalive instead of the NNI LMI for switch-to-switch communication.
A1: | By nature, Frame Relay NNI LMI protocol is not end-to-end, and hence, it does not necessarily reflect the true status of a multiple-hop Frame Relay PVC connection. Moreover, NNI LMI requires each intermediate switching node of an end-to-end Frame Relay PVC connection to support it. On the contrary, Cisco Frame Relay End-to-End Keepalive truly maintains the end-to-end status of a Cisco Frame Relay PVC connection, and it is required to be configured only between the two end-points of the connection.
2: | What is the use of the event window parameter?
A2: | The parameter specified for the event window indicates the number of events necessary to change the keepalive status of the PVC from the UP state to the DOWN state.
3: | What are the common applications of the Frame Relay End-to-End Keepalive feature?
A3: | Common uses include Frame Relay network management and backup applications. Frame Relay End-to-End Keepalive can be used to detect a broken connection in the Frame Relay network and, subsequently, trigger a backup connection to replace the broken link.
4: | What are the likely consequences when the time intervals for the send and receive timers are misconfigured?
A4: | The send and receive timers set up on the Frame Relay routers involved in End-to-End Keepalive signaling must match. If a mismatch is detected, the End-to-End Keepalive status is brought to the DOWN state.


Chapter 8

1:

How do ATM and Frame Relay technologies compare?

A1:

Both ATM and Frame Relay are high-speed Layer 2 technologies, but ATM is capable of a much higher data rate than Frame Relay, and ATM is generally deployed on high-speed backbones. ATM and Frame Relay protocols have many differences. For example, ATM uses a packet format, commonly known as a cell, with a fixed size of 53 bytes, whereas Frame Relay supports a variable-length packet size. Unlike Frame Relay, which is supported on serial interfaces, ATM requires dedicated hardware or ATM network interfaces. Compared with Frame Relay, ATM has the added benefit of providing distinct classes of service for different applications.

ATM and Frame Relay have some similarities, as well. For example, neither ATM nor Frame Relay has built-in error correction facilities in the protocol. ATM has an HEC field in the ATM header to detect errors, but it still relies on upper-layer protocol to effectively recover from cell loss or errors.

2:

What is the purpose of Frame Relay to ATM Interworking?

A2:

The primary purpose of Frame Relay to ATM Interworking is to allow disparate Layer 2 protocols to communicate with each other in an effort to create an end-to-end hybrid network for end users. Moreover, since not many networks today are built on a single Layer 2 technology, implementing Frame Relay to ATM Interworking ensures optimization of performance and the cost of network ownership.

3:

How do FRF.5 network interworking and FRF.8.1 service interworking compare?

A3:

The FRF.5 network interworking function specification allows two remote Frame Relay networks to be connected across an intermediate ATM network. The FRF.8.1 service interworking function specification allows an end user Frame Relay device to connect directly with an end user ATM device.

4:

How do FRF.8.1 translation and transparent modes compare?

A4:

FRF.8.1 translation mode performs a frame-to-cell translation between two pieces of terminal equipment using incompatible encapsulation types. FRF.8.1 transparent mode forwards the traffic between Frame Relay and ATM unaltered, but it requires the terminal equipment to use compatible encapsulation types.

5:

What happens when FRF.8.1 service interworking in the transparent mode is deployed between two pieces of terminal equipment with dissimilar encapsulation types?

A5:

Because of the incompatible encapsulation types and the fact that FRF.8.1 service interworking in the transparent mode does not perform translation, the two pieces of terminal equipment would not be able to communicate with each other.

6:

What is the FRF.8.1 bidirectional congestion indication support?

A6:

The FRF.8.1 service interworking function supports bidirectional congestion indication. When a packet travels from a Frame Relay network into an ATM network, the default FRF.8.1 behavior is to set the EFCI field in the ATM header if the DE bit is set in the Frame Relay header. In the opposite ATM-to-Frame Relay direction, the default FRF.8.1 behavior is to set the FECN bit in the Frame Relay header if the EFCI bit in the ATM header is set. These preserve the congestion indication information in the original protocol header when the packet crosses the protocol boundary.

7:

What is ATM equivalent to Frame Relay's DE bit?

A7:

The ATM equivalent to Frame Relay's DE bit is the CLP bit.


Chapter 9

1: | What is the main use of the Adaptive Frame Relay Traffic Shaping for Interface Congestion feature?
A1: | The Adaptive Frame Relay Traffic Shaping for Interface Congestion feature allows a Frame Relay router to react to congestion built up at the interface level. Thus, when the interface queue becomes congested, this feature allows packets to be dropped early at the PVC level.
2: | What is the difference between the frame-relay class class-name and class class-name commands?
A2: | The frame-relay class command associates a Frame Relay map-class to an interface or subinterface. All Frame Relay PVCs created under the interface or subinterface inherit the parameters defined in the Frame Relay map-class. On the other hand, the class class-name command is used to associate a Frame Relay map-class directly with a DLCI.
3: | What is the default queue depth for Frame Relay Adaptive Shaping for Interface Congestion?
A3: | The default queue depth is 0 packets. The queue depth size can be changed using the frame-relay adaptive-shaping interface-congestion [queue-depth] map-class configuration command. The value of queue-depth ranges from 0 to 40.
4: | What is the default queuing strategy at the interface level when Frame Relay Traffic Shaping is configured?
A4: | The queuing strategy is FIFO. To configure FIFO queuing on an interface, use the no fair-queue interface configuration command.
5: | Describe the actions when the current queue size exceeds the configured queue depth of the interface queue when Adaptive Frame Relay Traffic Shaping for Interface Congestion feature is enabled.
A5: | The router throttles the VC egress rate from CIR to MINCIR.
6: | Describe the actions when the current queue size falls below the configured queue depth of the interface queue when Adaptive Frame Relay Traffic Shaping for Interface Congestion feature is enabled.
A6: | The router increases the VC egress rate from MINCIR back to CIR.


Chapter 10

1: | How do Frame Relay encapsulations using RFC 1490/RFC 2427 and RFC 1973 compare?
A1: | RFC 1490 and RFC 2427 define specifications to support multiprotocol transport over Frame Relay. The NLPID field in the RFC 1490/RFC 2427 Frame Relay header identifies the protocol type carried within the Frame Relay frame. RFC 1973 defines a Frame Relay framing specification to carry PPP session packets. RFC 1973 uses a Frame Relay header similar to RFC 1490/RFC 2427. The NLPID field is used to indicate PPP session packets carried in the frame.
2: | How do a Frame Relay DLCI configured to use RFC 1490/RFC 2427 and a Frame Relay DLCI configured with RFC 1973 compare?
A2: | A Frame Relay DLCI using RFC 1490/RFC 2427 transports IP information directly over a Frame Relay VC. On the other hand, a Frame Relay DLCI using RFC 1973 encapsulates PPP packets inside a Frame Relay frame and transports them directly over a Frame Relay VC. The IP information is carried within the PPP packets.
3: | What value in the NLPID field indicates that a PPP packet is carried inside the frame?
A3: | The value of 0xCF indicates that PPP packets are carried inside a Frame Relay frame.
4: | What are the virtual template interface configurations used for in setting up PPP over Frame Relay?
A4: | The virtual-template interface allows a user to set up configuration options that are not associated to any physical interface. When the user sets up a PPP over Frame Relay session, virtual access interfaces required for PPP access are cloned from the virtual-template interface.
5: | What protocol in PPP negotiates the authentication process between two peer routers?
A5: | LCP negotiates the authentication process between two peer routers. LCP works at the data-link layer. It is responsible for establishing, configuring, maintaining, and terminating the PPP connection. Authentication is negotiated during link establishment.
6: | What protocol in PPP negotiates the network layer protocol transported by the PPP session?
A6: | NCP negotiates the network layer protocol transported by the PPP session. NCP works at the network layer and is responsible for establishing and configuring different network layer protocols.


Chapter 11

1:

What are the main differences between Frame Relay SVC and PVC implementations?

A1:

Frame Relay SVCs are virtual circuits that are provisioned on a call-by-call basis. When the Frame Relay SVC users have data to send, the Frame Relay SVC is provisioned only for the duration when data is being sent. After the duration has elapsed and no data is being transmitted, the Frame Relay SVC is torn down. Customers are typically billed based on the amount of service provided.

Frame Relay PVCs are fixed-path virtual circuits that involve only a one-time setup. Frame Relay PVCs are permanently provisioned, and Frame Relay PVC customers typically are charged a flat rate regardless of usage.

2:

What are the common considerations for network designers when implementing Frame Relay SVCs?

A2:

The common considerations that network designers take into account when implementing Frame Relay SVCs are the implementation complexities, cost, and network application (traffic pattern). Additionally, availability can be a factor because Frame Relay SVC networks are not widely implemented today.

3:

How is call setup for Frame Relay SVC negotiated between Frame Relay DTE and the Frame Relay switch?

A3:

SVC operation and signaling requires the data-link layer to be set up with ITU-T Q.922 LAPF. Q.922 provides a reliable link layer for Q.933 operation, and Q.933 call control information is transmitted over the reserved DLCI 0.

4:

How are the characteristics and parameters (values such as committed access rate) of a SVC connection set up on a Cisco router during call request?

A4:

The Frame Relay parameters, such as CIR, Bc, and Be, are typically supplied to the user by the Frame Relay SVC service provider. The parameters are set up with a Frame Relay map class, which is applied to the SVC during call setup time.

5:

What are the types of addressing schemes for SVC supported by Cisco routers, and what are their differences?

A5:

X.121 and E.164 are the supported addressing schemes for SVC on Cisco routers. E.164 is an international standard supported by the ITU, which defines the format for telephone numbers. For example, the E.164 international country code for Switzerland is 41. A maximum of 15 digits are supported in the E.164 addressing standard. X.121 is commonly used on X.25 networks and supports a maximum of 14 digits..

6:

What is the Cisco IOS configuration command to define the idle or inactive period for Frame Relay SVC connection to remain up when there is no active traffic?

A6:

The frame-relay idle-timer second map-class configuration command defines the period for which the Frame Relay SVC is allowed to stay up when there is no active traffic. After the period defined by the idle timer has elapsed, the Frame Relay SVC is torn down.


Chapter 12

1:

What are the main reasons for users to migrate their existing X.25 networks to Frame Relay?

A1:

Compared to modern digital transmission facilities with low error rates, X.25 is slow in performance. The robust error correction mechanism in X.25 is no longer relevant and is considered a high overhead for many X.25 users. Newer technologies, such as Frame Relay, ATM, and IP, are becoming widely available and offer better value and performance than the legacy X.25. These are the main reasons for users to migrate away from X.25. However, X.25 is still widely deployed in certain parts of the world, such as Asia. In some countries, X.25's error correction capabilities are needed because of the lack of quality transmission facilities.

2:

What are the protocol differences between Frame Relay and X.25?

A2:

Frame Relay offers only an error detection mechanism, but it does not perform any error correction functions. Rather, Frame Relay depends on upper-layer protocols, such as TCP/IP, to effectively recover from errors. Hence, Frame Relay relies on the availability of "clean" transmission media with low error rates. By contrast, X.25 is designed to operate over any transmission media, including legacy data networks with high interference and error rates. X.25 provides a reliable delivery mechanism and can effectively recover from errors.

3:

Name the main advantages and disadvantages of Frame Relay over X.25.

A3:

The advantages of Frame Relay over X.25 include the following: Frame Relay eliminates many protocol overheads inherent in the X.25 protocol. Frame Relay supports a higher transmission rate and boosts a better performance than X.25.

The disadvantages of Frame Relay over X.25 include the following: Because Frame Relay does not support error correction or recovery, it is not designed to operate over erroneous transmission media. The results can be disastrous if Frame Relay is used over a transmission media with high error rates. Therefore, Frame Relay requires better quality and more expensive physical cabling.

4:

What must the user check when configuring distance vector routing protocols over an X.25 interface?

A4:

X.25 is a packet-switched protocol similar to Frame Relay, so it is likewise susceptible to the Non-Broadcast Multi-Access (NBMA) nature of Frame Relay. Split horizon is an issue when configuring distance vector routing protocols, such as RIP or IGRP, on an X.25 interface. X.25 subinterfaces, which are similar to Frame Relay subinterfaces, can be created on Cisco routers to resolve the issue of split horizon. Furthermore, sophisticated link-state routing protocols, such as OSPF and IS-IS, can be used to overcome the problems with the NBMA nature of packet-switched networks.

5:

Describe the use of the X.25 profiles for X.25 configuration and name the Cisco IOS configuration command for creating an X.25 profile.

A5:

X.25 profiles help to simplify X.25 or LAPB configurations on a Cisco router. X.25 or LAPB configuration commands or hardware-specific configurations can be set up in an X.25 profile. The use of an X.25 profile avoids the need to allocate hardware IDB information. The completed X.25 profile can be applied to different configurations. For example, when configuring Annex G, a completed X.25 profile can be used to associate with multiple DLCI configurations by the profile name.

To create an X.25 profile, use the x25 profile profile-name global configuration command.


Chapter 13

1: | Describe the benefits of using Frame Relay QoS Autosense in setting up the Frame Relay Traffic Shaping feature on a group of Cisco routers.
A1: | Frame Relay QoS Autosense allows Frame Relay operators and users to simplify the configuration and management of Frame Relay configurations. Frame Relay QoS Autosense allows a service provider to use ELMI to disseminate traffic shaping parameters, such as CIR, Bc, and Be, to a group of Cisco routers running on ELMI. The group of Cisco routers uses the learned QoS parameters to set up Frame Relay Traffic Shaping accordingly.
2: | Describe the purpose of the Frame Relay Address Registration functionality of the Frame Relay ELMI feature.
A2: | Frame Relay Address Registration allows a Frame Relay user to autodiscover the interconnections between a group of Frame Relay devices (routers and network switches) via SNMP. This allows the user to centrally manage and monitor the connections between Frame Relay devices.
3: | What happens if a router that does not support Address Registration is connected to a Frame Relay switch that does support Address Registration?
A3: | When the Frame Relay router does not support Address Registration but the Frame Relay switch does, there is no successful exchange of version enquiry between them. The neighbor IP address 0.0.0.0 is learned by the supporting device instead of the management IP address.
4: | Which IP address on the router is selected as the management IP address if autoaddress registration is used?
A4: | By default, autoaddress registration selects the IP address of Ethernet interfaces on the router.
5: | In the context of Frame Relay Address Registration, what does the field 01 indicate in the output of the debug frame-relay lmi command when a Cisco router sends out a version status enquiry to its neighbor?
A5: | When the router is sending out a version status enquiry and 01 is observed, Address Registration is enabled on the local router.


Chapter 14

1: | Compare the use of Multilink Frame Relay with that of separate physical interfaces to aggregate bandwidth.
A1: | Using Multilink Frame Relay to aggregate bandwidth has many advantages over combining separate parallel physical connections. First of all, Multilink Frame Relay does not create a single point of failure when one of the bundle links fails. When a bundle link fails, active traffic across the bundle can be redirected across other active bundle links without causing traffic disruption to users. Multilink Frame Relay allows traffic to be effectively load balanced across the bundle links. Dynamic routing protocols see a Multilink Frame Relay bundle as a single interface, which simplifies addressing and reduces network layer and routing complexities.
2: | Name the protocol that Multilink Frame Relay uses to establish a bundle.
A2: | Multilink Frame Relay uses Multilink Link Integrity Protocol to establish a bundle.
3: | How many classes of bandwidth are defined in the FRF.16 implementation agreement? Name the class of bandwidth implemented by Cisco.
A3: | Four classes of bandwidth are defined by FRF.16: Classes A, B, C, and D. Cisco's implementation of Multilink Frame Relay currently only supports Class A. In Class A, the Multilink bundle is active as long as at least one bundle link is active. The Multilink bundle is brought down only when all bundle links are inactive.
4: | What is the restriction for the maximum number of Multilink Frame Relay interfaces that can be created?
A4: | The maximum number of MFR interfaces that can be created is limited by the maximum number of IDBs supported by the Cisco platform. Different Cisco platforms have different maximum numbers of IDBs. Refer to CCO at http://www.cisco.com/en/US/products/sw/iosswrel/ps1835/products_tech_note09186a0080094322.shtml for details on IDBs.
5: | What is the Cisco IOS configuration command to configure a physical interface as a bundle link or a member of the bundle?
A5: | The encapsulation frame-relay mfr mfr-number interface configuration command is used to configure a physical interface as a bundle link.
6: | How is load balancing performed across the bundle links of a Multilink bundle? What is the Cisco IOS configuration command to adjust the load balancing threshold across the bundle links?
A6: | Load balancing is performed across the bundle links in a round-robin fashion. By default, the threshold of each bundle link for load balancing is 300 bytes. This is the number of bytes that a bundle link transmits before rolling over to the next bundle link for transmission. The frame-relay multilink output-threshold command can be used to adjust the transmission threshold of each bundle link for load balancing.


Chapter 15

1:

How does compression help to achieve higher overall throughput on the link, and how does it benefit Frame Relay networks?

A1:

Generally, compression allows the size of the payload or headers to be reduced before they are transmitted. Reducing the size of the payload or header allows more data to be placed on the wire for transmission, thus increasing the overall throughput on the link. Compression maximizes the utilization of existing bandwidth on the link. Using compression on Frame Relay produces the same benefits as on other data-link layer media. In particular, compression helps to reduce the CIR requirements of Frame Relay users.

2:

How do header compression and payload compression compare?

A2:

Header compression works by compressing the size of the protocol headers in the traffic stream. Header compression depends on the redundant nature of the fields in the protocol headers. By contrast, payload compression works by compressing the size of the data payload in the traffic stream. Payload compression depends on the nature of the users' traffic. For example, less benefit can be gained by compressing already compressed data, such as JPEG.

3:

How do Stacker and Predictor compression algorithms compare?

A3:

Stacker uses an encoded dictionary of symbols and tokens to replace redundant strings of characters in the data stream. Predictor tries to predict the next sequence of characters in a data stream with an index to look up in a compression dictionary. If a match is found, Predictor replaces the matched sequence with the sequence that was looked up in the dictionary. Predictor is memory intensive but less CPU intensive. On the other hand, Stacker uses less memory. Predictor is generally considered more efficient than Stacker because of lower CPU requirements.

The compress stac and compress predictor commands can be used to configure Stacker and Predictor compression, respectively, for data link encapsulations, such as PPP, X.25, and HDLC.

4:

What are the Cisco IOS configuration commands for Frame Relay required to enable payload compression on multipoint interfaces and point-to-point subinterfaces?

A4:

On a multipoint interface, compression is typically configured as part of the frame-relay map command. For example, the frame-relay map protocol protocol-address dlci payload-compress FRF9 stac [hardware-options] command is used to enable FRF.9 payload compression on a multipoint interface. By contrast, on a point-to-point subinterface, the frame-relay payload command is configured directly on the DLCI. The frame-relay payload-compress FRF9 stac [hardware-options] command is used to enable FRF.9 payload compression directly on a point-to-point subinterface.

5:

What are the benefits associated with using hardware compression instead of software compression?

A5:

Compression is CPU intensive because compression algorithms perform extensive computations. The use of dedicated compression hardware allows the router to offload the CPU-intensive compression computations from the CPU. This frees up the CPU resources on the router to allow them to support other features.

6:

What is the Cisco IOS show command that allows users to monitor the payload compression configurations on Cisco routers?

A6:

The show compress privileged EXEC command is used to monitor the payload compression configurations on the Cisco IOS software. Below is an example of the output of the show compress command:

Router#show compress
Serial3/2
         Software compression enabled
         uncompressed bytes xmt/rcv 1089240/1200
         1  min avg ratio xmt/rcv 5.564/0.049
         5  min avg ratio xmt/rcv 5.563/0.051
         10 min avg ratio xmt/rcv 5.563/0.051
         no bufs xmt 0 no bufs rcv 0
         resyncs 0
       Additional Stacker Stats:
       Transmit bytes:  Uncompressed =        0 Compressed = 189045
       Received bytes:  Compressed =        920 Uncompressed = 0


Chapter 16

1: | What is fragmentation?
A1: | Fragmentation is a process that allows a sending source to segment a large data frame into smaller frames for transmission. The receiving destination performs reassembly of the large data frame when it has successfully received all fragments of the original frame.
2: | What is the primary purpose of fragmentation in Frame Relay?
A2: | Frame Relay Fragmentation breaks up larger data frames. The primary purpose of fragmentation in Frame Relay is to reduce the serialization delay of the smaller real-time sensitive frames on a slow Frame Relay link caused by smaller frames being held up behind larger data frames.
3: | How do Frame Relay FRF.12 Fragmentation, Frame Relay Fragmentation using FRF.11 Annex C, and Cisco proprietary fragmentation compare?
A3: | All three fragmentation standards perform fragmentation of large data frames into smaller frames to reduce serialization delay. FRF.12 Fragmentation is based on the Frame Relay Forum's standard implementation agreements and is supported across many vendors. FRF.12 supports the transport of both real-time as well as non-real-time traffic. Frame Relay Fragmentation with FRF.11 is used in a VoFR environment, whereby fragmented data is transported on a FRF.11 DLCI configured for VoFR. Cisco proprietary fragmentation is based on a proprietary fragmentation format supported only on Cisco platforms.
4: | Describe the benefits of using Frame Relay Fragmentation with hardware compression support.
A4: | In general, compression techniques increase the overall data rates of slow transmission links by compressing the payload in the packets. Performing both Frame Relay Fragmentation and compression compresses the overall size of the fragmented Frame Relay frames to achieve greater transmission efficiency over low-bandwidth links. Compression calculation requires intensive CPU resources. Using hardware-based compression allows Cisco routers to offload the compression calculations from the CPU to dedicated hardware to improve performance.
5: | What is the purpose of the sequence number field in the Frame Relay header for fragmentation?
A5: | The sequence number field in the header allows the receiving station to identify each fragment of the original packet to perform packet reassembly. When a fragment is lost during transmission, as identified by a missing sequence number, the receiving station aborts reassembly and discards the fragments.


Chapter 17

1: | Define the role of queuing in Frame Relay.
A1: | On a Frame Relay network that is experiencing congestion, queuing allows excess packets to be buffered in the queues until there is available bandwidth for transmission. Each supported queuing technique determines the way the packets are dequeued for transmission.
2: | Name the current queuing mechanisms for Frame Relay supported on Cisco routers.
A2: | Cisco supports FIFO, PQ, CQ (fancy queuing for FRTS), WFQ, Frame Relay PIPQ, Frame Relay CBWFQ, Frame Relay LLQ, and Frame Relay interface queuing and fragmentation.
3: | What is Frame Relay PIPQ?
A3: | Frame Relay PIPQ provides an interface-level PQ scheme for Frame Relay in which the prioritization is based on the destination PVC rather than on packet contents.
4: | How do PVC-level queues and interface-level queues compare?
A4: | Frame Relay Traffic Shaping enables a two-level queuing structure on Cisco routers. The majority of the Frame Relay queuing schemes are configured at the PVC level. Frame Relay frames pass through the PVC-level queues, and the frames are subjected to the PVC-level queuing schemes before they are sent to the interface-level queue for transmission.
5: | Describe the use of a Dual-FIFO queue in Frame Relay.
A5: | A Dual-FIFO queue is created on the Frame Relay interface when Frame Relay FRF.12 Fragmentation is enabled at the interface. A Dual-FIFO queue assigns two FIFO queues; one queue has a high priority, while the other queue has a low priority. The high-priority FIFO queue handles delay-sensitive voice packets, and the low-priority FIFO queue handles fragmented data packets.
6: | Describe the use of the Frame Relay broadcast queue.
A6: | The Frame Relay broadcast queue improves performance by identifying broadcast traffic and storing the excess broadcast traffic in the broadcast queue. The Frame Relay broadcast queue restricts or limits the amount of bandwidth consumed by broadcast traffic on the Frame Relay interface.


Chapter 18

1: | Describe the use of Cisco's MQC configuration.
A1: | MQC is a hierarchical QoS configuration structure for users to set up traffic polices. With MQC, a user identifies the traffic classes on the network by defining class maps with the class-map command. Next, policy maps, which are created with the policy-map command, are used to define the actions to be performed on traffic classes identified in the class maps. This completes the QoS policy configuration, and the policy map is finally attached to an interface or PVC via the service-policy command.
2: | How do CBWFQ and WFQ compare?
A2: | CBWFQ is an enhanced version of WFQ. CBWFQ supports up to 64 user-defined traffic classes. WFQ uses a proprietary priority management scheme that automatically sorts user traffic into conversations without any user intervention.
3: | How do LLQ and CBWFQ compare?
A3: | LLQ is an extended version of CBWFQ, whereby a strict priority queue is supported for voice or other real-time delay-sensitive traffic.
4: | Describe the role of the priority queue in LLQ.
A4: | The priority queue in the LLQ structure handles the priority traffic, while the remaining traffic is handled by the user-defined Class-Based Weighted Fair Queues (CBWFQs).
5: | Describe the mechanism of LLQ for Frame Relay.
A5: | LLQ is designed to support an integrated data/voice network where the voice traffic typically has a low tolerance for latency and jitter. LLQ reserves bandwidth in the priority queue to ensure that the delay-sensitive traffic is not starved of bandwidth. The remaining traffic classes are handled by user-defined Class-Based Weighted Fair Queues (CBWFQs).


Chapter 19

1: | Describe the benefits of the Frame Relay Queuing and Fragmentation at the Interface feature.
A1: | The Frame Relay Queuing and Fragmentation at the Interface feature simplifies QoS configurations, in particular for FRF.12 and LLQ for Frame Relay. On a large Frame Relay setup, the Frame Relay Queuing and Fragmentation at the Interface feature allows LLQ and FRF.12 to be applied collectively at the interface level, thereby eliminating the need to configure LLQ and FRF.12 on every individual Frame Relay PVC under the main interface.
2: | What is interleaving? Describe its main advantage.
A2: | Interleaving enables the intermixing of fragmented frames and nonfragmented frames for transmission. Interleaving improves bandwidth usage by fragmenting large data frames to the size of the smaller delay-sensitive voice frames and by allowing both types of frames to be intermixed for transmission.
3: | What are the legacy Frame Relay functionalities that are mutually exclusive with the Frame Relay Queuing and Fragmentation at the Interface feature?
A3: | Frame Relay Traffic Shaping, class-based (PVC) fragmentation, Frame Relay SVC, hierarchical shaping, and multiple shapers are mutually exclusive with the Frame Relay Queuing and Fragmentation at the Interface feature.
4: | What is the purpose of the subrate shaper?
A4: | Because Frame Relay Traffic Shaping is mutually exclusive with the Frame Relay Queuing and Fragmentation at the Interface feature, a subrate shaper is used to apply shaping to a traffic class in the QoS policy.
5: | When subrate shaping is enabled, what component of Frame Relay Queuing and Fragmentation at the Interface is automatically disabled?
A5: | Interleaving is automatically turned off.


Chapter 20

1: | What are the main benefits of MLP LFI for Frame Relay?
A1: | LFI supports the transmission of interactive delay-sensitive traffic over slow bandwidth links. LFI provides a special transmission queue for delay-sensitive traffic ahead of other queues. In addition, large data packets are fragmented by the MLP LFI feature to reduce delay over slow bandwidth links.
2: | What are the main applications of LFI?
A2: | LFI is applicable for interactive, real-time, and delay-sensitive traffic such as Voice over IP, Telnet, SSH, and IP video conferencing. These applications are susceptible to network delay and jitters.
3: | What are the supported directions for load threshold calculation?
A3: | The supported directions are inbound, outbound, or both.
4: | How is the fragment size for MLP LFI derived?
A4: | The fragment size is typically based on the required delay of the delay-sensitive voice packet.
5: | How many links can an MLP bundle have on a Cisco router?
A5: | An MPL bundle can have only one link.


Chapter 21

1: | How do RED and WRED compare?
A1: | Both RED and WRED depend on TCP's response to packet loss as a signal of network congestion and for it to dynamically throttle its throughput as a reaction to packet drops. WRED takes RED one step further by combining RED with IP precedence to determine the manner in which it drops packets from the congested queues. WRED makes use of the IP precedence values to provide differentiated services for different classes of traffic. Under WRED, lower-priority packets are selectively dropped when the router begins to experience congestion. On the other hand, higher-priority packets are allowed to stay longer in the queues during congestion.
2: | Explain why WRED is most useful with TCP protocol traffic.
A2: | WRED is most useful with TCP traffic because of the way TCP handles packet loss. During congestion, a TCP transmission source retransmits the lost segment after it detects a dropped data segment. At the same time, the TCP transmission source lowers its transmission rate to half of what it was before the drop was detected. This is the TCP back-off behavior. When congestion eases, TCP increases its output rate again with the slow-start algorithm. Hence, a TCP transmission source is able to slow down its transmission of packets when WRED selectively discards packets during congestion.
3: | What is the default queuing method used on an interface with speed greater than E1 (2.048 Mbps)?
A3: | The default queuing method on an interface with speed (bandwidth) greater than E1 is FIFO. Then, Weighted Fair Queuing is the default queuing method on interfaces with speed lower than E1.
4: | What Cisco IOS show command can be used to verify the queuing method used on an interface?
A4: | The show interface command can be used to verify the queuing method used on the specified interface.
5: | What is the Cisco IOS configuration command to enable FIFO queuing?
A5: | To enable FIFO queuing on an interface, the no fair-queue command is used.


Chapter 22

1: | What is the main purpose of using RSVP with real-time interactive traffic?
A1: | Real-time interactive traffic sends a constant flow of information, and hence, it requires a network pipe with a consistent delay. However, this is not always possible when the real-time traffic is delivered over a datagram service network, which only provides best-effort delivery. RSVP allows end systems and hosts to establish a reserved-bandwidth path between them to ensure QoS for their transmission.
2: | How much bandwidth is available for RSVP by default?
A2: | By default, 75 percent of the bandwidth on an interface can be reserved by RSVP.
3: | What is the Cisco IOS command that allows users to change the default amount of bandwidth available for RSVP?
A3: | The max-reserved-bandwidth percentage command allows users to change the default amount of bandwidth available for RSVP.
4: | What is the Cisco IOS command to verify the bandwidth available in the bandwidth pool?
A4: | The show queue command can be used to verify the bandwidth available in the pool.


Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [X] [Z]


SYMBOL

Previous Page
Next Page

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [X] [Z]

0 CIR (zero CIR)
75 percent rule, network planning


A

Previous Page
Next Page

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [X] [Z]

AAL5 (ATM adaptation layer 5)
access
bandwidth
optimizing 2nd
SVCs
configuring 2nd 3rd 4th
implementing
monitoring 2nd
virtual interfaces 2nd
active TCP/IP header compression [See also TCP/IP]
Adaptive Frame Relay Traffic Shaping for Interface Congestion [See also congestion]
case study 2nd
configuring 2nd
verifying 2nd
adaptive shaping
BECN 2nd
Foresight 2nd
ADD_LINK_ACK message
ADD_LINK_REJ message
adding
subrate shapers
addresses
ELMI
configuring 2nd
MIB 2nd
registering 2nd
addressing
global significance
local significance [See also local signiificance]
SVC
X.121
administration
broadcast traffic 2nd
congestion
congestion management
monitoring 2nd
ELMI Address Registration
networks
planning 2nd
performance 2nd
Advanced Integration Modules (AIM)
advertising
SAP
agents
MIB SNMP
AIM (Advanced Integration Modules)
Airline X.25 (AX25)
algorithms
compression
leaky bucket
Lempel-Ziv compression
LSZ
Predictor compression
Stacker compression 2nd
token bucket
Van Jacobson's
WFQ [See WFQ]
Annex G 2nd 3rd
case study 2nd
implementing 2nd
monitoring
troubleshooting
answers to review questions 2nd
any-to-any connectivity
remote sites
Application Specific Integrated Circuit (ASIC)
applications
LFI [See LFI]
LLQ
troubleshooting 2nd
PVCs/SVCs 2nd
real-time
provisioning bandwidth
architecture
hierarchical queuing 2nd
ASIC (Application Specific Inetgrated Circuit)
assignment
DLCI 2nd
association
FRTS map classes 2nd
virtual template interfaces
Asynchronous Transfer Mode [See ATM]
ATM
Cisco 2600 series routers
Cisco 3600 series routers 2nd
Cisco 7200 series routers
CLP 2nd
congestion 2nd
DE 2nd
Frame Relay protocol
comparing to 2nd
FRF.5 2nd
configuring 2nd 3rd 4th
FRF.8.1 2nd
IMA
internetworking 2nd
overview of 2nd
platform support
ATM (Asynchronous Transfer Mode)
ATM adaptation layer 5 (AAL5)
authentication
autonotification
ELMI Address Registration 2nd
configuring 2nd
MIB 2nd
Autosense (ELMI QoS) 2nd
configuring 2nd
avoidance (congestion)
RED
WRED 2nd
conifguring 2nd
troubleshooting 2nd
AX25 (Airline X.25)


B

Previous Page
Next Page

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [X] [Z]

B channels
switching on
B-ISDN (Broadband Integrated Services Digital Network)
backing up
VCs 2nd
backups
bandwidth-on-demand 2nd
Backward Explicit Congestion Notification (BECN)
bandwidth
CBWFQ
compression
data payload schemes
design 2nd
Express Header configuration
FRF.9 configuration 2nd
function of 2nd
hardware/software 2nd
monitoring 2nd
packet header schemes
packet-by-packet payload configuration
Predictor
ratios 2nd
RTP configuration 2nd
schemes 2nd
Stacker 2nd
TCP/IP configuration 2nd
troubleshooting
compresson
loss-less compression algorithm schemes
nonreversible data compression schemes
LFI [See LFI]
optimizing 2nd
planning
requirements
reservations services
bandwidth percent command
bandwidth-on-demand 2nd
bandwisth
troubleshooting
bandwith
virtual template interfaces
configuring
Bc (committed burst)
Be (excess burst)
BECN
FRTS
adaptive shaping 2nd
BECN (Backward Explicit Congestion Notification)
BFE (Blacker Front End)
bidirectional mode
End-to-End Keepalive
bit mapping
CLP to DE 2nd
DE to CLP 2nd
Blacker Front End (BFE)
BM13602
bottlenecks
RED
WRED 2nd
configuring 2nd
troubleshooting 2nd
broadband
ATM 2nd
Broadband Integrated Services Digital Network (B-ISDN)
broadcast queues 2nd
configuring 2nd
broadcast traffic
managing 2nd
bundles
configuring 2nd
load balancing 2nd
managing
resiliency
verifying
tearing down


C

Previous Page
Next Page

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [X] [Z]

capacity
bandwidth
planning
plannning
case studies
Adaptive Frame Relay Traffic Shaping for Interface Congestion 2nd
Annex G 2nd
fragmentation 2nd
PPP 2nd
SVCs 2nd
casestudies
LFI 2nd
CBWFQ 2nd
configuring 2nd
LLQ/PQ 2nd
troubleshooting 2nd
WFQ
comparing
CBWFQ (Class-Based Weighted Fair Queuing)
CBWFQ (class-based WFQ)
CEF (Cisco Express Forwarding)
cell loss priority (CLP)
Challenge Handshake Authentication Protocol (CHAP)
channels
B
switching on
CHAP (Challenge Handshake Authentication Protocol)
CIR
Frame Relay subscription
planning 2nd
maximum
MINCIR
moderated
zero CIR
CIR (committed information rate)
reducing
circuits
Cisco 90i IDSL Channel Unit
compression
Cisco 2600 series routers
ATM
Cisco 3600 series routers
ATM 2nd
Cisco 7200 series routers
ATM
Cisco 90i IDSL Channel Unit
Cisco Express Forwarding (CEF)
Cisco Frame Relay Enhanced LMI [See ELMI]
Cisco Frame Relay Switching Enhancements feature 2nd
configuring
monitoring 2nd
Cisco IOS MLP LFI feature [See also LFI]
Cisco MC3810 platform
Class-Based Weighted Fair Queuing [See CBWFQ]
class-based WFQ (CBWFQ)
class-map commands
configuring 2nd
classes
map
associating 2nd
FRTS 2nd
classification
mission-critical traffic
CLI
configuring
clockrate command
CLP
ATM 2nd
CLP (cell loss priority)
cnfport IGX switch port configuration command
commands
bandwidth percent
class-map
configuring 2nd
clockrate
cnfport IGX port configuration
debug 2nd
debug frame-relay end-to-end keepalive event
debug frame-relay events
debug frame-relay lmi
debug frame-relay packet
debug priority
encapsulation frame-relay
encapsulation x25
frame-relay adaptive-shaping foresight
frame-relay address registration ip
frame-relay broadcast-queue
frame-relay cir
frame-relay congesiton threshold ecn
frame-relay congestion threshold de
frame-relay congestion-management
frame-relay de-group
frame-relay fragment
frame-relay holdq
frame-relay idle-timer
frame-relay interface
frame-relay interface-dlci
frame-relay intf-type dce interface
frame-relay map 2nd
frame-relay mincir
frame-relay policing
frame-relay qos-autosense
frame-relay route
frame-relay svc
frame-relay switching 2nd
frame-relay traffic-shaping 2nd
frame-relay traffic-shaping interface configuration
hold-queue interface configuration
max reserved-bandwidth
no shutdown
policy-map global configuration
service-policy
shape
show
LFI 2nd
MFR 2nd
verifying connections 2nd
show compress 2nd
show frame-relay end-to-end keepalive
show frame-relay fragment
show frame-relay lmi
show frame-relay map 2nd 3rd
show frame-relay pvc 2nd 3rd 4th 5th 6th
show frame-relay qos-autosense
show frame-relay route
show frame-relay vofr global EXEC
show interface 2nd
show interface global EXEC
show interface serial
show interface serial privileged EXEC mode
show interface serial type/number global EXEC
show interface type slot/port privileged EXEC mode
show ip tcp header-compression
show policy-map privileged EXEC
show traffic-shape
show x25 map
snmp-server community
X.25
committed burst (Bc)
committed information rate (CIR)
Common Part Convergence Sublayer (CPCS)
Common Part Convergence Sublayer)
Common Part Indicator (CPI)
comparisons
ATM/Frame Relay protocol 2nd
CBWFQ to WFQ
hardware/software compression 2nd
PVCs/SVCs 2nd 3rd
Tail Drop/WRED
compatibility
hardware/software compression
components
BECN
adaptive shaping 2nd
Foresight
adaptive shaping 2nd
Compressed RTP (CRTP)
compression 2nd
algorithms
bandwidth
optimizing 2nd
CIR
reducing
CPU
DCP
design 2nd
Express Header configuration
FRF.(
verifying payloads
FRF.9 configuration 2nd
function of 2nd
hardware
compatibility
FRF.12 Fragmentation 2nd
hardware/software 2nd
latency
loss-less compression algorithm schemes
memory
monitoring 2nd
nonreversible data compression schemes
payloads
viewing
Predictor
ratios 2nd
RTP header configuration 2nd
RTP headers
verifying
schemes 2nd
data payload
packet headers
packet-by-packet payload configuration
software
compatibility
speed
Stacker 2nd
TCP/IP
verifying
TCP/IP header configuration 2nd
troubleshooting
Compression Service Adaptor (CSA)
Compression Service Adaptors (CSA)
conditions
FRF.12 Fragmentation
configuration 2nd
Adaptive Frame Relay Traffic Shaping for Interface Congestion 2nd
bundles 2nd
CBWFQ 2nd
Cisco Frame Relay Switching Enhancements feature
compression
FRF.9 payloads 2nd
congestion management
dynamic mapping 2nd
ELMI 2nd
encapsulation 2nd
hierarchical queuing architecture [See also hierarchical queuing architecture]
End-to-End Keepalive 2nd
routers 2nd
Express Header Compression
Fragmentation at the Interface 2nd
Frame Relay IP RTP Priority feature
FRF.12 Fragmentation
switched PVCs
FRF.5 2nd
FRF.8.1 2nd
FRTS 2nd
associating map classes 2nd
BECN adaptive shaping 2nd
broadcast queues 2nd
DE 2nd
DLCI priority levels
enabling 2nd
Foresight adaptive shaping 2nd
generic traffic shaping 2nd
map classes 2nd
monitoring 2nd
overview of 2nd
hardware compression 2nd
keepalives
LAPF parameters
LLQ
LMI 2nd
local significance 2nd
MQC 2nd
customizing class-map commands 2nd
Multilink Frame Relay
initializing 2nd
load balancing 2nd
Multilink Frame Relay Link Integrity Protocol 2nd
parameters 2nd 3rd 4th
MultiLink Frame Relay
routers 2nd
packet-by-packet payload compression
parameters
X.25 SVC connections
PIPQ 2nd
policing
incoming switched interfaces
PPP
case study 2nd
frame formats 2nd
interfaces 2nd
monitoring 2nd
requirements 2nd
RFC 1973 implementation 2nd
routers
LFI 2nd 3rd 4th
RSVP 2nd
RTP
header compression 2nd
static mapping 2nd
subinterfaces 2nd
point-to-point 2nd
SVCs 2nd 3rd 4th
monitoring 2nd
switches 2nd
TCP/IP
header compression 2nd
thresholds
queue depth
traffic shaping
UFM ports
virtual template interfaces
WFQ
interfaces
WRED 2nd
X.25 2nd
congestion 2nd
ATM 2nd
BECN/FECN
compression
DE
conifguring 2nd
FRF.8.1
FRTS [See also FRTS]
management 2nd
configuring
monitoring 2nd
queuing [See also queuing]
RSVP 2nd
switched PVCs
managing
map-class
notification
RED
Tail Drop
traffic shaping 2nd
WRED 2nd
configuring 2nd
troubleshooting 2nd
congestive-discard-threshold option
conifguration
virtual template interfaces
connections [See also networks]
ATM 2nd
DLCI
local significance 2nd
ELMI Address Registration
deleting
End-to-End Keepalive
monitoring
frame mode setup
ping utility
SVCs
point-to-point subinterfaces
configuring
PPP
requirements 2nd
RFC 1973 implmentation 2nd
queuing 2nd
hierarchical architecture 2nd
remore sites
any-to-any connectivity
RSVP [See RSVP]
SVCs
verifying
troubleshooting 2nd
verifying 2nd
X.25 [See also X.25]
control messages
convergence
CPCS User-to-User notification (CPCS-UU)
CPCS-UU (CPCS User-to-User notification)
CPE (customer premised equipment)
CPI (Common Part Indicator)
CPU
compression
CQ (custom queuing) 2nd
CRC (cyclic redundancy check)
credit
CRTP (Compressed RTP)
CSA (Compression Service Adaptor)
CSA (Compression Service Adaptors)
custom queuing (CQ) 2nd
customer premises equipment (CPE)
customization
LAPF parameters
topologies 2nd
cyclic redundancy check (CRC)


D

Previous Page
Next Page

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [X] [Z]

data circuit-terminating equipment (DCE)
Data Compression Protocol (DCP)
Data Network Identification Codes (DNICs)
data payload compression schemes
data rates
mismatch
troubleshooting
data terminal equipment (DTE)
data traffic, RSVP 2nd
data-stream compression [See also compression]
DCCs (International Data Country Codes)
DCE
ELMI QoS Autosense
DCE (date circuit-terminating equipment)
DCP (Data Compression Protocol)
DDN (Defense Data Network)
DE
ATM 2nd
configuring 2nd
DE (discard eligibility)
debug commands
connections
troubleshooting 2nd
debug frame-relay end-to-end keepalive event command
debug frame-relay events command
debug frame-relay lmi command
debug frame-relay packet command
debug priority command
debugging
Annex G
End-to-End Keepalive 2nd
Defense Data Network (DDN)
Defense Information Systems Agency (DISA)
delay
LFI [See LFI]
MLP
configuring
deleting
connections
ELMI Address Registration
FRTS
deployment
ELMI QoS Autosense
design
compression 2nd
destination service-assess point (DSAP)
devices
End-to-End Keepalive 2nd
configuring 2nd
monitoring 2nd
troubleshooting 2nd
differentiated services [See DiffServ]
DiffServ
DISA (Defense Information Systems Agency)
discard eligibility (DE)
distributed class-based WFQ
Distributed Traffic Shaping (DTS)
distributed WFQ
DLCI
assignment 2nd
Foresight adaptive shaping
priority levels
configuring
DNICs (Data Network Identification Codes)
DSAP (destination service-assess point)
DTE
ELMI QoS Autosense
DTE (date terminal equipment)
DTS (Distributed Traffic Shaping)
dual-FIFO
dual-FIFO queuing
dynamic mapping
conifguring 2nd
dynamic throttling, output
dynamic-queues option


E

Previous Page
Next Page

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [X] [Z]

E.164 addressing schemes
edge routers
EFCI (Explicit Forward Congestion Indication)
egress interfaces
FRTS
ELMI
Address Registration 2nd
configuring 2nd
MIB 2nd
configuring 2nd
QoS
Autosense 2nd
configuring Autosense 2nd
inablitlity to obtain
ELMI (Cisco Frame Relay Enhanced LMI)
enabling [See also configuration]
ELMI 2nd
encapsulation 2nd
LFI
FRF.12 Fragmentation
switched PVCs 2nd
FRTS 2nd 3rd
interleaving
MLP
PIPQ 2nd
SVCs
switching
WRED
interfaces
traffic policies
X.25 2nd
encapasulation
Annex G 2nd
implementing 2nd
encapsulation
configuring 2nd
LFI
enabling
matching
MFR interfaces
PIPQ 2nd
configuring 2nd
troubleshooting 2nd
PPP
frame formats 2nd
queuing [See also hierachical queuing architecture]
SVCs
TCP/IP header compression
verifying
X.25
configuring 2nd
encapsulation frame-relay command
encapsulation x25 command
end systems, RSVP 2nd
End-to-End Fragmentation
hardware compression
End-to-End FRF.12 Fragmentation 2nd 3rd
End-to-End Keepalive 2nd
conifguring 2nd
monitoring 2nd
troubleshooting 2nd
end-to-end mapping
inability to obtain
Enterprise Resource Planning (ERP)
ERP (Enterprise Resource Planning)
establishing
establishment
of bundle links
of link 2nd
Ethernets
interfaces
Layer 3 queues
events
windows
excess burst (Be)
existing CIR, reducing
existing networks
compression
design
Explicit Forward Congestion Indication (EFCI)
Express Header Compression configuration


F

Previous Page
Next Page

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [X] [Z]

Fast Ethernet interfaces, Layer 3 queues
fast switching
Express Header Compression
FECN (Forward Explicit Congestion Notification)
FIFO
dual-FIFO queuing
FIFO (First-In-First-Out)
First-In-First-Out (FIFO)
flow-based WFQ
flow-based WRED [See also WRED]
flowcharts
leaky buckets/token buckets
Foresight
FRTS
adaptive shaping 2nd
formats
frames
PP 2nd
formatting
proprietary fragementation
Forward Explicit Congestion Notification (FECN)
FR-SSCS (Frame Relay Service Specific Convergence Sublayer)
fragementation
configuring
fragements
sizing
fragmentation
case studies 2nd
implementing
FRF.11 Annex C 2nd
FRF.12 2nd
LFI [See LFI]
proprietary formats
switched PVCs
configuring FRF.12 Fragmentation
FRF.12 support 2nd
troubleshooting 2nd
Fragmentation at the Interface feature 2nd
configuring 2nd
troubleshooting 2nd
fragmentaton
hardware compression 2nd
Frame Relay CIR subscription
planning 2nd
Frame Relay Forum Implementation Agreement Document NumberFRF.5
Frame Relay IP RTP Priority, configuring
Frame Relay PIPQ
Frame Relay Service Specific Convergence Sublayer (FR-SSCS)
Frame Relay Traffic Shaping [See FRTS]
frame-relay adaptive-shaping foresight command
frame-relay address registration ip command
frame-relay broadcast-queue command
frame-relay cir command
frame-relay class interface command
frame-relay congestion threshold de command
frame-relay congestion threshold ecn command
frame-relay congestion-management command
frame-relay de-group command
frame-relay fragment command
frame-relay holdq command
frame-relay idle-timer command
frame-relay interface-dlci command
frame-relay intf-type dce interface configuration command
frame-relay map command 2nd
frame-relay mincir command
frame-relay policing command
frame-relay qos-autosense command
frame-relay route command
frame-relay svc command
frame-relay switching command 2nd
frame-relay traffic-shaping command 2nd
frame-relay traffic-shaping interface configuration command
frames
Annex G 2nd
implmenting 2nd
compression
formats
PPP 2nd
modes
connection setup
transmission
interleaving
FRF.11 Annex C Fragementation 2nd
FRF.12
fragementation 2nd
FRF.12 Fragmentation
hardware compression 2nd
FRF.5 (Frame Relay Forum Implemetation Agreement Document NumberFRF.5 2nd
FRF.5 (Frame Relay Forum Implemetation Agreement Document NumberFRF.5)
configuring 2nd
FRF.8.1 (Frame Relay Forum Implemetation Agreement Document NumberFRF.8.1) 2nd
configuring 2nd
FRF.9
payload compression configuration 2nd
FRF.9 payload compression
verifying
FRTS
deleting
FRTS (Frame Relay Traffic Shaping)
BECN
adaptive shaping 2nd
broadcast queues 2nd
conifguring 2nd
associating map classes 2nd
mapping classes 2nd
monitoring 2nd
data rate mismatch
DE 2nd
DLCI priority levels
enabling 2nd
Foresight
adaptive shaping 2nd
generic traffic shaping 2nd
oversubscription 2nd
overview of 2nd
fully meshed topologies 2nd
functionality
fragmentation
functions
Annex G 2nd
implementing 2nd


G

Previous Page
Next Page

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [X] [Z]

generic traffic shaping
FRTS 2nd
Generic Traffic Shaping (GTS)
global significance addressing
GTA (Generic Traffic Shaping)


H

Previous Page
Next Page

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [X] [Z]

hardware
compression 2nd
compatibility
FRF.12 Fragmentation 2nd
FRF.9 payloads
configuring
Header Error Control (HEC)
headers
compression
Express Compression configuration
packets
compression schemes
RTP
compression configuration 2nd
verifying compression
TCP/IP
compression configuration 2nd
verifying compression
UDP
HEC (Header Error Control)
HELLO messages
hierarchical queuing architecture 2nd
High Speed Serial Interface (HSSI)
hold-queue interface configuration command
HSSI (High Speed Serial Interface)
hub-and-spoke networks
compression
design
hub-and-spoke topologies
broadcast queues
configuring 2nd


I

Previous Page
Next Page

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [X] [Z]

IDNs (International Data Numbers)
IDSL
Cisco 90i IDSL Channel Unit
IDSL (ISDN Digital Subscriber Line)
IfINdex (interface indexes)
IMA (Inverse Multiplexing over ATM)
implementation
Annex G 2nd
fragmentation
FRF.11 Annex C 2nd
FRF.12 2nd
FRF.5 2nd
configuring 2nd
FRF.8.1 2nd
configuring 2nd
Multilink Frame Relay
implementing 2nd
SVCs
implmentation
PPP
RFC 1973 2nd
incoming switched interfaces
policing
conifguring
increasing
bandwidth
troubleshooting
indexes
IfIndex
ingress interfaces
policing
monitoring 2nd
initialization
Multilink Frame Relay 2nd
Integrated Services Digital Network (ISDN)
backing up
interface indexes (IfIndex)
interface-level queuing
interfaces
configuring
congestion 2nd
traffic shaping 2nd
congestion management
monitoring
encapsulation
configuring 2nd
Fast Ethernet
Layer 3 queues
Fragmentation at the Interface feature 2nd
configuring 2nd
troubleshooting 2nd
FRTS [See also FRTS]
HSSI
incoming switched
configuring policing
ingress
monitoring policing 2nd
ISDN B channels
switching on
LMI
configuring 2nd
map classes
associating
mapping
MQC
configuringf 2nd
customizing class-map commands 2nd
Multilink Frame Relay
NI
fragmentation
NNI
PIPQ 2nd
configuring 2nd
troubleshooting 2nd
PP 2nd
queuing strategies
split horizons
subinterfaces
configuring 2nd
point-to-point 2nd
troubleshooting 2nd
subrate shaping
UNI
fragmentation
UNI DCE
policing
VIP2
virtual templates
creating
WFQ
configuring
WRED
enabling
x.25
enabling 2nd
interleaving
enabling
LFI [See LFI]
interleaving frames for transmission
internal timers
End-to-End Keepalive
International Data Country Codes (DCCs)
International Data Numbers (IDNs)
internetworking
ATM 2nd
Inverse Multiplexing over ATM (IMA)
IP RTP Priority feature, configuring
ISDN
B channels
switching on
ISDN (Integrated Services Digital Network)
backing up
ISDN Digital Subscriber Line (IDSL)


J

Previous Page
Next Page

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [X] [Z]

jitters
LFI [See LFI]
Joint Photographic Experts Group (JPEG)
JPEG (Joint Photographic Experts Group)


K

Previous Page
Next Page

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [X] [Z]

keepalives [See also End-to-End Keepalive]
configuring


L

Previous Page
Next Page

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [X] [Z]

LAPF
parameters
configuring
LAPF (Link Access Procedures to Frame)
latency
compression
Layer 3
queuing
SVC user call states
LCI (logical channel identifier)
LCP (Link Control Protocol)
leaky bucket algorithm
legacy Frame Relay Traffic Shaping feature, fragmentation
Lempel-Ziv compression algorithm
levels
priority
configuring DLCI
LFI
routers
case studies 2nd
configuring 2nd 3rd 4th
troubleshooting 2nd
LFI (Link Fragmentation and Interleaving)
line cards
VIP2
Link Access Procedures to Frame (LAPF)
Link Control Protocol (LCP)
Link Fragmentation and Interleaving [See LFI]
link-layer efficiency mechanisms
LFI [See LFI]
links 2nd
bundles
LFI [See LFI]
load balancing 2nd
lists
DE
conifguring 2nd
LLC (logical link control)
LLQ
CBWFQ 2nd
configuring
Fragmentation at the Interface feature 2nd
configuring 2nd
troubleshooting 2nd
troubleshooting 2nd
LLQ (Low Latency Queuing)
LMI
configuring 2nd
load balancing
Multilink Frame Relay 2nd
local significance
DLCI assignment 2nd
logical channel identifier (LCI)
logical link control (LLC)
lookups
process switching
loss-less compression algorithm schemes
Low Latency Queuing (LLQ)
LSZ algorithm


M

Previous Page
Next Page

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [X] [Z]

MAC
process switching
maintenance
links 2nd
management
broadcast traffic 2nd
bundles 2nd
congestion
configuring
monitoring 2nd
queuing [See also queuing]
RSVP 2nd
switched PVCs
ELMI Address Registration
links 2nd
networks
planning 2nd
performance 2nd
SNMP
MID agents
managgement
congestion 2nd
managing 2nd
map classes
FRTS 2nd
associating 2nd
SVCs 2nd
map-class
congestion
mapping
dynamic
configuring 2nd
end-to-end
inability to obtain
static
configuring 2nd
matching
encapsulation
max-reserved-bandwidth command
maximum CIR
maximum transmission unit (MTU)
LFI
measurement intervals
memory
compresssion
messages
ADD_LINK_ACK
ADD_LINK_REJ
control
HELLO
Multilink Frame Relay Link Integrity Protocols 2nd
REMOVE_LINK_ACK
MIB
ELMI Address Registration 2nd
MINCIR (Minimum CIR)
MINCIR (minimum CIR)
MINCIR (Minimum CIR) values
Minimum CIR (MINCIR)
minimum CIR (MINCIR)
Minimum CIR (MINCIR) values
mission-critical traffic, classifying
mixes, protocols
MLP
enabling
MLP (Multilink Point-to-Point Protocol)
LFI [See LFI]
models
Frame Relay/X.25 interworking
moderated CIR
modes
End-to-End Keepalive
frames
connection setup
Modular Quality of Service Command Line Interface [See MQC]
modules
CSA
hardware/software compression
monitoring
Annex G
CBWFQ 2nd
Cisco Frame Relay Switching Enhancements feature 2nd
compression 2nd
congestion management 2nd
End-to-End Keepalive 2nd
Fragementation at the Interface feature 2nd
fragmentation 2nd
FRTS 2nd
LFI 2nd 3rd 4th
LLQ 2nd
Multilink Frame Relay 2nd
PIPQ 2nd
PPP 2nd
RSVP 2nd
SVCs 2nd
switched PVCs 2nd
WRED 2nd
MQC
CBWFQ
configuring 2nd
configuring 2nd
customizing class-map commands 2nd
MQC (Modular Quality of Service Command Line Interface)
MTU (maximum transmission unit)
LFI
Multilink Frame Relay
configuring
implementing 2nd
initializing 2nd
interfaces
load balacncing 2nd
Multilink Frame Relay Link Integrity Protocol 2nd
parameters 2nd 3rd 4th
routers
configuring 2nd
troubleshooting 2nd
Multilink Rrame Relay
implmenting 2nd
initializing 2nd
load balancing 2nd
Multilink Frame Relay Link Integirty Protocol 2nd
parameters 2nd 3rd 4th
troubleshooting 2nd
multimedia
ATM 2nd
multiplexing
IMA
TDM
multipoint subintefaces
multipoint subinterfaces 2nd 3rd 4th [See also subinterfaces]


N

Previous Page
Next Page

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [X] [Z]

N-ISDN (Narrowband Integrated Services Digital Networks)
Narrowband Integrated Services Digital Networks (N-ISDN)
NCP (Network Control Protocol)
Network Control Protocol (NCP)
Network Layer Protocol ID (NLPID)
Network-to-Network Interface (NNI)
fragmentation
networks
broadcast traffic
managing 2nd
CIR
planning subscription 2nd
compression
design
EMI QoS Autosense 2nd
configuring 2nd
performance
managing 2nd
planning 2nd
queuing 2nd
configuring PIPQ 2nd
hierarchical architecture 2nd
PIPQ 2nd
troubleshooting PIPQ 2nd
RSVP [See RSVP]
split horizons
troubleshooting 2nd
static mapping
subinterfaces
troubleshooting 2nd
SVCs 2nd
any-to-any connectivity
bandwidth-on-demand 2nd
case study 2nd
configuring 2nd 3rd 4th
implementing
monitoring 2nd
topologies
customizing 2nd
VCs
backing up 2nd
NLPID (Network Layer Protocol ID)
NNI (Network-to-Network Interface)
fragmentation
no shutdown command
nonreversible data compression schemes
notification
congestion
ELMI Address Registration 2nd
configuring 2nd
MIB 2nd


O

Previous Page
Next Page

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [X] [Z]

operations 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th 13th 14th 15th
optimization
bandwidth 2nd
Cisco Frame Relay Switching Enhancements feature 2nd
performance 2nd
options
CBWFQ 2nd
LAPF parameters
topologies 2nd
outgoing switched PVCs
configuring
output
compression
viewing
show interface
throttling
oversubscription
troubleshooting 2nd


P

Previous Page
Next Page

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [X] [Z]

packet header compression schemes
packet-by-packet payload compression configuration
packets
compression
congestion 2nd
traffic shaping 2nd
dropping 2nd 3rd
conifguring WRED 2nd
troubleshooting WRED 2nd
End-to-End Keepalive
FRTS [See also FRTS]
real-time
enabling interleaving
SAP
Tail Drop
PAP (Password Authentication Protocol)
parameters
FRTS 2nd
LAPF
configuring
Multilink Frame Relay 2nd 3rd 4th
policing
QoS
inability to obtain
X.25 SVC connections
partially meshed networks
static mapping
partially meshed topologies
subinterfaces
passive TCP/IP header compression [See also TCP/IP]
passive-reply mode
End-to-End Keepalive
Password Authentication Protocol (PAP)
patterns
traffic
compression [See also compression]
payload type (PT)
payloads
compression
viewing
data payload compression schemes
FRF.9 compression 2nd
FRF.9 payloads
verifying
packet-by-packet compression
peers
End-to-End FRF.12 Fragmentation
per-PVC level queues
performance [See also troubleshooting]
compression
permanent virtual circuit (PVC)
physical interfaces
point-to-point subinterfaces
ping utility
SVCs
PIPQ 2nd
configuring 2nd
troubleshooting 2nd
planning
bandwidth
provisioning
CIR subscription 2nd
ERP
networks 2nd
backing up VCs 2nd
customizing topologies 2nd
managing broadcast traffic 2nd
performance management 2nd
split horizons 2nd
subinterfaces 2nd
platforms
Cisco MC3810
support
Point-to-Point Protocol [See PPP]
point-to-point subinterfaces 2nd [See also subinterfaces]
configuring 2nd
poison reverse
policies
traffic
enabling WRED
policing
incoming switched interfaces
configuring
ingress interfaces
monitoring 2nd
parameters
policy-map global configuration command
ports
UFM
PPP
case study 2nd
frame formats 2nd
monitoring 2nd
requirements 2nd
RFC 1973 implmentation 2nd
virtual access interfaces 2nd
virtual template interfaces 2nd
PPP (Poijnt-to-Point Protocol)
PQ
CBWFQ 2nd
PIPQ 2nd
configuring 2nd
troubleshooting 2nd
PQ (priority queuing) 2nd
Predictor compression algorithm
preferences
CBWFQ 2nd
LAPF parameters
premium traffic class
priority
DLCI levels
configuring
priority queuing (PQ) 2nd
process switching
processing
X.25
enabling 2nd
proprietary fragmentation formats
protocols
broadcast traffic
CHAP
DCP
End-to-End Keepalive 2nd
configuring 2nd
monitoring 2nd
troubleshooting 2nd
Frame Relay
comparing to ATM 2nd
LCP
mixes
MLP
enabling
LFI [See LFI]
Multilink Frame Relay Link Integrity 2nd
NCP
PAP
PPP
RIP
RSVP
SNAP
SNMP
ELMI Address Registration
MIB agents
UDP
headers
provisioning
bandwidth
PT (payload type)
PVC (permanent virtual circuit)
PVC-level queuing
PVCs
bandwidth-on-demand 2nd
compression
configuring
monitoring 2nd
SVCs
comparing 2nd
comparing to
switched
configuring FRF.12 Fragmentation
FRF.12 Fragmentation support 2nd
traffic shaping


Q

Previous Page
Next Page

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [X] [Z]

Q.933 operations
Q933-A LMI type
Q933-A LMI type, configuring
QoS
ELMI
Autosense 2nd
configuring Autosense 2nd
QoS (Quality of Service) [See also performance]
Quality of Service [See QoS]
questions, answers to review 2nd
queue depth
queueing
LLQ
troubleshooting 2nd
queuing 2nd 3rd 4th
broadcasts
configuring 2nd
CBWFQ 2nd
configuring 2nd
LLQ/PQ 2nd
troubleshooting 2nd
CQ
Fragmentation at the Interface feature 2nd
configuring 2nd
troubleshooting 2nd
hierarchical architecture 2nd
Layer 3
map classes
PIPQ 2nd
configuring 2nd
troubleshooting 2nd
PQ
Tail Drop
WFQ
overview of
queung
congestion 2nd
traffic shaping 2nd


R

Previous Page
Next Page

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [X] [Z]

Random Early Detection [See RED]
Random Early Detection (RED)
rates
output
throttling
traffic
verifying output
ratios
compression 2nd
real-time applications
bandwidth
provisioning
LFI [See LFI]
real-time interactive traffic, RSVP 2nd
real-time packets
interleaving
enabling
real-time traffic
LFI [See LFI]
RED
congestion avoidance mechanisms
RED (Random Early Detection) 2nd
reduction
of CIR
redundancy services
registration
ELMI addresses 2nd
configuring 2nd
MIB 2nd
regulation
of output traffic rates
remote sites
any-to-any connectivity
REMOVE_LINK
REMOVE_LINK message
REMOVE_LINK_ACK message
reply mode
End-to-End Keepalive
request mode
End-to-End Keepalive
requests
End-to-End Keepalive
requirements
bandwidth
PPP 2nd
reservable-queues option
reservation services, bandwidth
resiliency
bundles
verifying
Resource Reservation Protocol [See RSVP]
restrictions
FRF.12 Fragmentation
Multilink Frame Relay
PIPQ
review questions, answers to 2nd
RFC 1973 implementation, PPP 2nd
RIP (Routing Information Protocol)
Route Switch Processor (RSP)
routers
Annex G [See also Annex G]
CBWFQ
configuring
Cisco 2600 series
ATM
Cisco 3600 series
ATM 2nd
Cisco 7200 series
ATM
Cisco Frame Relay Switching Enhancements feature
configuring
monitoring 2nd
compression [See compression]
configuring
congestion 2nd
edge
ELMI QoS Autosense 2nd 3rd 4th
End-to-End Keepalive
configuring 2nd
flow-based WRED [See also WRED]
Fragmentation at the Interface feature
FRF.9 payload compression
LFI
case studies 2nd
configuring 2nd 3rd 4th
troubleshooting 2nd
LLQ
Mulitlink Frame Relay
conifguring 2nd
subinterfaces
troubleshooting 2nd
switches
configuring 2nd
Routing Information Protocol (RIP)
RSP (Route Switch Processor)
RSVP 2nd
configuring 2nd
troubleshooting 2nd
RSVP (Resource Reservation Protocol)
RTP
headers
compression configuration 2nd
RTP header compression
verifying


S

Previous Page
Next Page

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [X] [Z]

SAP (Service Advertising Packets)
SAR (segmentation and reassembly)
saving
bandwidth 2nd
schemes
compression 2nd
data payload
packet header
packet-by-packet payload configuration
fragmentation 2nd 3rd
FRF.11 nnex C 2nd
FRF.12 2nd
segmentation and reassembly (SAR)
serial interfaces
encapsulation
configuring 2nd
ISDN B channels
switching on
X.25
enabling 2nd
serialization
LFI [See LFI]
Service Advertising Packets (SAP)
service-policy command
services
bandwidth reservation
SVCs
configuring 2nd 3rd 4th
implementing
monitoring 2nd
user-on-demand 2nd
shape command
shaping
adaptive
BECN 2nd
Firesight 2nd
generic traffic 2nd
subrate
adding
traffic [See FRTS]
shaping traffic
Adaptive Frame Relay Traffic Shaping for Interface Congestion
congestion 2nd
ELMI QoS Autosense
show commands
connections
verifying 2nd
LFI 2nd
MFR 2nd
show compress command 2nd
show frame-relay end-to-end keepalive command
show frame-relay fragment command
show frame-relay lmi command
show frame-relay lmi priveleged EXEC mode
show frame-relay lmi privileged EXEC mode command
show frame-relay map command 2nd 3rd
show frame-relay pvc command 2nd 3rd 4th 5th 6th
show frame-relay qos-autosense command
show frame-relay route commands
show frame-relay vofr global EXEC command
show interface command 2nd
show interface global EXEC command
show interface serial command
show interface serial privileged EXEC mode command
show interface serial type/number global EXEC command
show interface type slot/port privileged EXEC mode command
show ip tcp header-compression command
show policy-map privileged EXEC command
show traffic-shape command
show x25 map command
siganling
SVC opreations
signaling
RSVP [See RSVP]
sizing
fragments
sizing frames, compression
SMDS (Switched Multimegabit Data Service)
SNAP (Subnetwork Access Protocol)
SNMP
ELMI Address Registraton
manager
MIB
MIB agent
snmp-server community command
software
compression 2nd
compatibility
FRF.9 payload compression
verifying
source service-assess point (SSAP)
speed
compression
split horizons
interfaces
subinterfaces
configuring 2nd
troubleshooting 2nd
SSAP (source service assess-point)
Stacker compression algorithm 2nd
star topology
static compression ratios
static mapping
conifguring 2nd
status
End-to-End Keepalive
monitoring
keepalives
subintefaces
conifguring 2nd
subinterfaces
map classes
associating
point-to-point 2nd
troubleshooting 2nd
Subnetwork Access Protocol (SNAP)
subrate shaping
adding
subrate shaping, interfaces
subscription
Frame Relay
planning 2nd
support
platforms
RSVP 2nd 3rd 4th
SVCs 2nd
any-to-any connectivity
bandwidth-on-demand 2nd
case study 2nd
configuring 2nd 3rd 4th
implementing
monitoring 2nd
PVCs
comparing 2nd
X.25 [See also X.25]
configuring
SVCs (switched virtual circuits)
compression
Switched Multimegabit Data Service (SMDS)
switched PVCs
configuring
congestion management
FRF.12 Fragmentation
configuring
FRF.12 Fragmentation support 2nd
monitoring 2nd
traffic shaping on
switched virtual circuits (SVCs)
compression
switches
Cisco Frame Relay Switching Enhancements feature 2nd
configuring 2nd
ELMI QoS Autosense 2nd
configuring 2nd
QoS
inability to obtain
switching
enabling
Express Header Compression
fast
process
synchronization
compression


T

Previous Page
Next Page

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [X] [Z]

T_HELLO timers
Tail Drop
troubleshooting 2nd
WRED
comparing
TCP (Transmission Control Protocol)
congestion avoidance
TCP/IP
headers
compression configuration 2nd
verifying compression
TDM (time division multiplexing)
tearing down bundles 2nd
tearing down links 2nd
templates
virtual interfaces 2nd
creating
thresholds
queue depth
throttling output
time-division multiplexing (TDM)
timers
End-to-End Keepalive
token bucket algorithm
tools
ping
SVCs
topologies
fully meshed 2nd
options 2nd
partially meshed
subinterfaces
star
traffic
Adaptive Frame Relay Traffic Shaping for Interface Congestion [See also congestion]
Annex G 2nd
implementing 2nd
ATM 2nd
broadcast
managing 2nd
class-map commands
configuring 2nd
classes
configuring 2nd
compresson [See also compression]
FRTS [See FRTS]
LFI [See LFI]
LLQ
troubleshooting 2nd
mission-critical
classifying
patterns
policies
enabling WRED
policing
protocol mixes
RSVP 2nd
shaping
congestion 2nd
ELMI QoS Autosense
generic 2nd
traffic shaping
configuring
on switched PVCs
translation mode, FRF.8.1
transmission
frames
interleaving
Transmission Control Protocol (TCP)
congestion avoidance
transparent mode, FRF.8.1
troublehsooting
Multilink Frame Relay
troubleshooting 2nd
troubleshooting
Annex G
bandwith
CBWFQ 2nd
compression
congestion 2nd 3rd 4th
ATM 2nd
compression
FRF.8.1
FRTS [See also FRTS]
managing
queuing [See also queuing]
RED
traffic shaping 2nd
WRED 2nd
connections 2nd
End-to-End Keepalive
data rate mismatch
End-to-End Keepalive 2nd
fragmentation 2nd 3rd 4th 5th
FRF.11 Annex C 2nd
FRF.12 2nd
Fragmentation at the Interface feature 2nd
LLQ 2nd
oversubscription 2nd
PIPQ 2nd
PPP
case study 2nd
monitoring 2nd
routers
LFI 2nd
RSVP 2nd
split horizons 2nd
configuring subinterfaces 2nd
subinterfaces 2nd
SVCs
ping utility
VCs
backing up 2nd
WRED 2nd
troubleshooting connections 2nd
tunneling
Annex G
types
of LMI
configuring 2nd


U

Previous Page
Next Page

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [X] [Z]

UDP (User Datagram Protocol)
headers
UFM (Universal Frame-Relay Module)
UNI (User-to-Network interface)
UNI (User-to-Network Interface)
fragmentation
UNI DCE interface
policing
Universal Frame-Relay Module (UFM)
user call states, SVC
User Datagram Protocol [See protocols;UDP]
user requirements, planning networks
user-on-demand services 2nd
User-to-Network interface (UNI)
User-to-Network Interface (UNI)
fragementation
utilities
ping
SVCs


V

Previous Page
Next Page

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [X] [Z]

values
MINCIR
Van Jacobson's algorithm
VCI (virtual circuit identifier)
VCs
LFI
case studies 2nd
configuring 2nd 3rd 4th
troubleshooting 2nd
point-to-point subinterfaces
configuring 2nd
VCs (virtual circuits)
backing up 2nd
verification [See also configuration]
Adaptive Frame Relay Traffic Shaping for Interface Congestion 2nd
bundle resiliency
connections 2nd
ELMI Address Registration
ELMI QoS Autosense
encapsulation
FRF.9 payload compression
PIPQ
regulation of output traffic rates
RSVP support 2nd 3rd 4th
RTP header compression
SVC connections
TCP/IP header compression
verififcation
compression 2nd
verifying [See also monitoring]
congestion management 2nd
End-to-End Keepalive 2nd
Frame Relay Switching Enhancements feature 2nd
FRF.5 configuration
policing
ingress interfaces 2nd
switched PVCs 2nd
Versatile interface Processor (VIP2)
version negotiation, ELMI Address Registration
viewing
compression
VIP2 (Versatile interface Processor)
virtual acces interfaces 2nd
virtual circuit identifier (VCI)
virtual path identifier (VPI)
virtual template interfaces 2nd
virtual template interfaces, creating
VoFR
fragmentation
VoIP (Voice over IP)
LFI [See LFI]
VPI (virtual path identifier)


W

Previous Page
Next Page

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [X] [Z]

Weighted Fair Queuing (WFQ)
Weighted Random Early Detection [See WRED]
Weighted Random Early Detection (WRED)
WFQ
CBWFQ
comparing
overview of
WFQ (Weighted Fair Queuing)
windows
events
WRED
configuring 2nd
congestion avoidance mechanisms 2nd
fragmentation
Tail Drop
WRED:comparing
troubleshooting 2nd
WRED (Weighted Random Early Detection)


X

Previous Page
Next Page

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [X] [Z]

X.121 addressing
X.121 addressing schemes
X.25
Anex G
case study 2nd
Annex G 2nd 3rd 4th
conifguring 2nd


Z

Previous Page

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [X] [Z]

zero CIR (0 CIR)