Cisco Frame Relay Solutions Guide

By Jonathan Chin

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

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

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

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

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
File downloaded from http://www.Demonoid.com
Ebook Created & Uploaded By Sabby
 Page 1 of 3

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.
 Page 2 of 3

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)
 Page 3 of 3

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.

File downloaded from http://www.Demonoid.com

Ebook Created & Uploaded By Sabby
 Page 1 of 17

Appendix A. Answers to Review Questions

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.
 Page 2 of 17

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.
 Page 3 of 17

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
 Page 4 of 17

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.
 Page 5 of 17

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
 Page 6 of 17

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
 Page 7 of 17

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.
 Page 8 of 17

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.
 Page 9 of 17

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.
 Page 10 of 17

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.
 Page 11 of 17

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.
 Page 12 of 17

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
 Page 13 of 17

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.
 Page 14 of 17

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).
 Page 15 of 17

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.

 Page 16 of 17

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.

 Page 17 of 17

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.

File downloaded from http://www.Demonoid.com

Ebook Created & Uploaded By Sabby
Part I: Frame Relay Technology

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 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
 Page 4 of 73

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 Tc is computed as Tc = Bc/CIR.
Interval
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 DCE devices provide a clocking signal
Equipment 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?

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

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 High

IGRP High

OSPF Low

IS-IS Low

EIGRP Low

BGP None

EGP None
IPX RIP High

EIGRP Low

SAP High
AppleTalk RTMP High

EIGRP Low
Bridging Transparent High

Remote SRB High

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

10/3/2010
 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

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

Configurable on
Must Match Per-Interface Configurable on Per-
Between Basis? DLCI Basis?
Frame Relay End-to-end Frame Yes Yes
Encapsulation Relay devices
Type
Frame Relay LMI Frame Relay device Yes No
Type and connected
Frame Relay switch

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
 Page 52 of 73

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
 Page 53 of 73

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.
 Page 54 of 73

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

 Page 55 of 73

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#
 Page 56 of 73

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
 Page 57 of 73

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...
 Page 58 of 73

!
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
 Page 59 of 73

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.
 Page 60 of 73

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:
 Page 61 of 73

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

 Page 62 of 73

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.
 Page 63 of 73

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
 Page 64 of 73

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

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

 Page 65 of 73

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
 Page 66 of 73

! 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

10/3/2010
 Page 67 of 73

!
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
 Page 68 of 73

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
 Page 69 of 73

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
 Page 70 of 73

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
 Page 71 of 73

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
Ebook by KBR Page 72 of 73

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.
 Page 73 of 73

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

File downloaded from http://www.Demonoid.com

Ebook By Sabby
 Ebook
Ebook By By Sabby
Sabby Page 1 of 70

Part IV: Cisco Frame Relay Solutions for

Congestion Management

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.
 Page 2 of 70

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]

 Page 3 of 70

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.
Ebook By Sabby Page 4 of 70

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
 Page 5 of 70

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

 Page 6 of 70

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

 Page 7 of 70

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
 Page 8 of 70

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
 Page 9 of 70

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.
 Page 10 of 70

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
Frame Relay encapsulation without any
features
Frame Relay Traffic Shaping
Frame Relay FRF.12 with FRTS
Interface Queuing Strategy
If the interface speed is lower than
E1, default is WFQ queuing. If the
interface speed is greater than E1,
default is FIFO queuing.
FIFO queuing.
Dual-FIFO queuing.
 Page 11 of 70

Frame Relay PIPQ (with or without FRTS or Interface PQ.

FRF.12)

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
 Page 12 of 70

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
 Page 13 of 70

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
 Page 14 of 70

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
 Page 15 of 70

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
 Page 16 of 70

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
 Page 17 of 70

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.
 Page 18 of 70

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
 Page 19 of 70

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
 Page 20 of 70

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
 Page 21 of 70

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

 Page 22 of 70

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

 Page 23 of 70

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.
 Page 24 of 70

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.
 Page 25 of 70

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.
 Page 26 of 70

Table 18-1. Available Options for Setting Up the Traffic Class

(class-map)
Command (config-cmap)
match access-group {access-group |
name access-group-name}
match input-interface interface-name
match protocol protocol
match mpls experimental number
Purpose
The content of the packets is checked
against the access list or named access
list to determine if they belong to the
class.
This checks the input interface of the
packets to determine if they belong to
the class.
This checks the packets to determine if
they belong to a given protocol and
hence, to the class.
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 This specifies the amount of bandwidth
bandwidth kbps 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 This specifies the number of dynamic
only) 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,
 Page 27 of 70

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
 Page 28 of 70

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.
 Page 29 of 70

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)

 Page 30 of 70

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
 Page 31 of 70

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
 Page 32 of 70

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

 Page 33 of 70

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.
 Page 34 of 70

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

 Page 35 of 70

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 SNagg_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 SNagg_DATA
bandwidth 32
queue-limit 100
class SALES_DATA
bandwidth 16
class class-default
fair-queue
 Page 36 of 70

!
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 SNagg_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 SNagg_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
 Page 37 of 70

!
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 64 kbps 85 kbps
(UDP port
12000)
Stream 2 32 kbps 34 kbps
(TCP port
2065)
Stream 3 16 kbps 18 kbps
(IP source
address
10.0.0.2)
 Page 38 of 70

Stream 4 16 kbps if Stream 1 and Stream 2 16 kbps

(IP traffic are sticking to their assigned
with bandwidth
source
10.0.0.3)
Total 128 kbps Approximately 153 kbps
Bandwidth

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
 Page 39 of 70

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.
 Page 40 of 70

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.
 Page 41 of 70

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
 Page 42 of 70

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
 Page 43 of 70

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
 Page 44 of 70

(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
 Page 45 of 70

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
 Page 46 of 70

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
 Page 47 of 70

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

 Page 48 of 70

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
 Page 49 of 70

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

 Page 50 of 70

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
 Page 51 of 70

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.
 Page 52 of 70

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

 Page 53 of 70

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)

 Page 54 of 70

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
 Page 55 of 70

!
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
 Page 56 of 70

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
 Page 57 of 70

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.
 Page 58 of 70

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.
 Page 59 of 70

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
 Page 60 of 70

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
 Page 61 of 70

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)
 Page 62 of 70

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

 Page 63 of 70

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
 Page 64 of 70

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
 Page 65 of 70

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
 Page 66 of 70

!
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
 Page 67 of 70

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
 Page 68 of 70

________________________________________________________________
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
 Page 69 of 70

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
 Page 70 of 70

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

File downloaded from http://www.Demonoid.com

Ebook By Sabby
 Page 1 of 18
Ebook By Sabby

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.
 Page 2 of 18

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
 Page 3 of 18

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.
 Page 4 of 18

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
 Page 5 of 18

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.
 Page 6 of 18

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
 Page 7 of 18

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
 Page 8 of 18

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
 Page 9 of 18

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
 Page 10 of 18

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
 Page 11 of 18

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
 Page 12 of 18

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
 Page 13 of 18

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
 Page 14 of 18

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
 Page 15 of 18

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
 Page 16 of 18

!
!
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.
 Page 17 of 18

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.
 Page 18 of 18

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

Torrent downloaded from http://www.Demonoid.com

Ebook By Sabby
 Page 1 of 87

Part II: Cisco Frame Relay Solutions for Policing

and Shaping

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.
 Page 2 of 87

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.
 Page 3 of 87

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
 Page 4 of 87

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
 Page 5 of 87

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
 Page 6 of 87

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.
 Page 7 of 87

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.
 Page 8 of 87

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.
 Page 9 of 87

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

 Page 10 of 87

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.
 Page 11 of 87

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.
 Page 12 of 87

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.
 Page 13 of 87

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
 Page 14 of 87

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

 Page 15 of 87

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

 Page 16 of 87

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
 Page 17 of 87

!
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
 Page 18 of 87

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
 Page 19 of 87

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.
 Page 20 of 87

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
Ebook By Sabby Page 21 of 87

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
 Page 22 of 87

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
 Page 23 of 87

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

 Page 24 of 87

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
 Page 25 of 87

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
 Page 26 of 87

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
 Page 27 of 87

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
 Page 28 of 87

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

 Page 29 of 87

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
 Page 30 of 87

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
 Page 31 of 87

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 Frame Relay Traffic Shaping
Shaping
CLI Applies parameters on Classes of parameters configured in map class
a per-interface basis
Applies parameters to all VCs on an interface
traffic group through inheritance
command used
No traffic group command supported
Queues Weighted Fair Queuing Weighted Fair Queuing (WFQ), Priority
supported (WFQ) per subinterface Queuing, Custom Queuing, First-In-First-Out
(FIFO) per VC supported
 Page 32 of 87

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
 Page 33 of 87

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
!
 Page 34 of 87

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

 Page 35 of 87

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

 Page 36 of 87

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
 Page 37 of 87

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
 Page 38 of 87

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.
 Page 39 of 87

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

 Page 40 of 87

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

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
 Page 41 of 87

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.
 Page 42 of 87

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
 Page 43 of 87

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
 Page 44 of 87

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:
 Page 45 of 87

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
 Page 46 of 87

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
 Page 47 of 87

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
 Page 48 of 87

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
 Page 49 of 87

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
 Page 50 of 87

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
 Page 51 of 87

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
 Page 52 of 87

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

 Page 53 of 87

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
 Page 54 of 87

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
 Page 55 of 87

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
 Page 56 of 87

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
 Page 57 of 87

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.
 Page 58 of 87

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
 Page 59 of 87

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

 Page 60 of 87

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
 Page 61 of 87

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?
 Page 62 of 87

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
!
 Page 63 of 87

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
 Page 64 of 87

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
 Page 65 of 87

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

 Page 66 of 87

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

 Page 67 of 87

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.
 Page 68 of 87

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 Keepalive Send Overall VC
Status Side Status LMI Status 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.
 Page 69 of 87

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
 Page 70 of 87

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.
 Page 71 of 87

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
 Page 72 of 87

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

 Page 73 of 87

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
 Page 74 of 87

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
 Page 75 of 87

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
 Page 76 of 87

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
 Page 77 of 87

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
 Page 78 of 87

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)
 Page 79 of 87

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
LMI
Advantages Disadvantages
LMI is an open Does not reflect true end-to-
standard supported end status of a PVC.
by many vendors.
All intermediate nodes in the
Frame Relay network have to
implement NNI LMI and
synchronize to exchange
status messages.
 Page 80 of 87

Not easy to implement a

Frame Relay End-to-End
Keepalive
backup mechanism to respond
to VC status changes reported
via LMI.
Reflects true end-to- Cisco proprietary and
end status of the supported only on Cisco
PVC, ensuring devices.
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.

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?
 Page 81 of 87

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
 Page 82 of 87

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
 Page 83 of 87

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
 Page 84 of 87

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
 Page 85 of 87

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
 Page 86 of 87

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

Ebook By Sabby Page 87 of 87

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.

File downloaded from http://www.Demonoid.com

Ebook By Sabby
Ebook By Sabby Page 1 of 141

Part III: Cisco Frame Relay Solutions for Traffic

Management

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

 Page 2 of 141

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.
 Page 3 of 141

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

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

 Page 4 of 141

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
 Page 5 of 141

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
 Page 6 of 141

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
 Page 7 of 141

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
 Page 8 of 141

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.
 Page 9 of 141

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
 Page 10 of 141

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
 Page 11 of 141

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
 Page 12 of 141

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]

 Page 13 of 141

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
 Page 14 of 141

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
 Page 15 of 141

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 The EFCI field in the ATM cell header is set to a constant 0.
configurable
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 The EFCI field in the ATM cell header is set to a constant 0.
configurable

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.
 Page 16 of 141

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

 Page 17 of 141

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

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
 Page 18 of 141

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
 Page 19 of 141

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
 Page 20 of 141

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
 Page 21 of 141

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.
 Page 22 of 141

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
 Page 23 of 141

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.
 Page 24 of 141

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
 Page 25 of 141

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

 Page 26 of 141

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
 Page 27 of 141

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
 Page 28 of 141

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

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

 Page 29 of 141

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
 Page 30 of 141

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
 Page 31 of 141

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.
 Page 32 of 141

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.
 Page 33 of 141

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
 Page 34 of 141

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.
 Page 35 of 141

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
 Page 36 of 141

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
 Page 37 of 141

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
 Page 38 of 141

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
 Page 39 of 141

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]

 Page 40 of 141

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
 Page 41 of 141

!
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.
 Page 42 of 141

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

 Page 43 of 141

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
 Page 44 of 141

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.
 Page 45 of 141

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)
 Page 46 of 141

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.
 Page 47 of 141

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
 Page 48 of 141

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.
 Page 49 of 141

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.
 Page 50 of 141

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
 Page 51 of 141

but has not responded yet.

Incoming Call Proceeding
Active
Disconnect Request
Disconnect Indication
Release Request
An incoming call when the user has sent
acknowledgement that the user has received all
call information necessary to effect call
establishment.
Called side: Network indicates that the calling
user has been awarded the call. Calling Side:
When the remote user answers the call.
User has requested the network to clear the end-
to-end call and is waiting for response.
The user has received an invitation to disconnect
because the network has disconnected the
connection.
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.

 Page 52 of 141

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.
 Page 53 of 141

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
frame-relay custom-
queue-list list-number
frame-relay priority-
group list-number
Purpose
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.
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- Enables adaptive traffic shaping on the SVC using

shaping [becn | either BECN or ForeSight mode.
foresight]

frame-relay cir {in|out} Specifies the inbound or outbound CIR in bits per
bps second.
frame-relay mincir Specifies the inbound or outbound minimum CIR in
{in|out} bps bits per second. By default, the mincir is half of the
configured CIR value.
frame-relay bc {in|out} Specifies the inbound or outbound committed burst
bits in bits.
frame-relay be {in|out} Specifies the inbound or outbound excess burst (Be)
bits 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
 Page 54 of 141

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,
 Page 55 of 141

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.

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?
 Page 56 of 141

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.
 Page 57 of 141

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

 Page 58 of 141

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

 Page 59 of 141

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.
 Page 60 of 141

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
 Page 61 of 141

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-
 Page 62 of 141

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

 Page 63 of 141

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.
 Page 64 of 141

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
 Page 65 of 141

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
 Page 66 of 141

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
 Page 67 of 141

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
 Page 68 of 141

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

 Page 69 of 141

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.
 Page 70 of 141

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.
 Page 71 of 141

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.
 Page 72 of 141

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

 Page 73 of 141

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
cfrElmiIpAddr
CfrElmiLinkStatus
cfrElmiArStatus
cfrElmiRemoteStatus
cfrElmiNeighborArStatus
cfrElmiNeighborIpAddress
Syntax/Values Description
IpAddress/Read This represents the management
only address of the device used for address
registration.
Integer/ Read This indicates whether ELMI is enabled
only on a Frame Relay interface: enabled(1),
disabled(2).
Integer/ Read This variable indicates whether ELMI AR
only 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.
Integer/ Read This variable states the ELMI status on
only the other end of the interface. If
cfrElmiLinkStatus is enabled on the
other end, a value of 1 is returned,
otherwise 2 is returned.
Integer/ Read This variable indicates the status of
only 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.
IpAddress/Read The management IP address of the
only 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
 Page 74 of 141

discovery of the network.

CfrElmiNeighborIfIndex Integer/ Read The interface index of the neighboring
only 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 Vendor name of the neighboring device
Only to which the other end of this interface
is connected.
cfrElmiNeighborPlatformName String/Read Platform name of the neighboring device
Only to which the other end of this interface
is connected.
cfrElmiNeighborDeviceName String/Read Device name of the neighboring device
Only 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
 Page 75 of 141

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 ]

 Page 76 of 141

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

 Page 77 of 141

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

 Page 78 of 141

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
 Page 79 of 141

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.
 Page 80 of 141

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.
 Page 81 of 141

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
!
 Page 82 of 141

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
 Page 83 of 141

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

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?
 Page 84 of 141

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.
 Page 85 of 141

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.
 Page 86 of 141

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.
 Page 87 of 141

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.
 Page 88 of 141

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
 Page 89 of 141

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

 Page 90 of 141

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.
 Page 91 of 141

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
 Page 92 of 141

! 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:
 Page 93 of 141

!!!!!!!!!!
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
 Page 94 of 141

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
 Page 95 of 141

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,
 Page 96 of 141

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,
 Page 97 of 141

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
 Page 98 of 141

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:
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
 Page 99 of 141

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

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
 Page 100 of 141

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?
 Page 101 of 141

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.
 Page 102 of 141

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.
 Page 103 of 141

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
 Page 104 of 141

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

 Page 105 of 141

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

 Page 106 of 141

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

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
 Page 107 of 141

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.
 Page 108 of 141

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
 Page 109 of 141

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
 Page 110 of 141

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]

 Page 111 of 141

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
Released in Cisco Frame Relay
IOS Software Encapsulation
Compression Algorithm Version 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 12.1(5)T Cisco or IETF only
 Page 112 of 141

compression (discussed in Chapter 16)

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
 Page 113 of 141

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

 Page 114 of 141

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
 Page 115 of 141

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
 Page 116 of 141

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,
 Page 117 of 141

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
 Page 118 of 141

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.
 Page 119 of 141

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
 Page 120 of 141

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.

 Page 121 of 141

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,
 Page 122 of 141

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.
 Page 123 of 141

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
 Page 124 of 141

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.
 Page 125 of 141

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

 Page 126 of 141

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

 Page 127 of 141

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

 Page 128 of 141

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
 Page 129 of 141

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

 Page 130 of 141

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
 Page 131 of 141

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
 Page 132 of 141

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
 Page 133 of 141

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
 Page 134 of 141

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.
 Page 135 of 141

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
 Page 136 of 141

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 formats
End-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
 Page 137 of 141

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
 Page 138 of 141

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
 Page 139 of 141

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
 Page 140 of 141

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
 Page 141 of 141

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.

File downloaded from http://www.Demonoid.com

Ebook From Sabby