• Author / Uploaded
• Mario Ramirez Mendez

Citation preview

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

2: A2:

3: A3:

4: A4:

What is Frame Relay? 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. What is a virtual circuit? 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). What are the differences between a PVC and an SVC? 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. What is the CIR? 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: A1:

2:

A2:

3: A3:

4: A4: 5: A5:

What are the main differences between DTE and DCE devices in a Frame Relay network? 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. List the most common industry cabling standards used for connecting serial interfaces to a Frame Relay network. 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. What is global addressing? 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. Name the Frame Relay encapsulations supported by the Cisco IOS. Cisco proprietary encapsulation and IETF (RFC 1490). The default encapsulation type used is Cisco. What are the main functionalities of Frame Relay multicasting and Inverse ARP? 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: A1:

2:

A2:

3:

A3:

4: A4:

5:

A5:

What are the three key factors that affect network planning? 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. What are the different network topologies, and which is the most commonly seen for Frame Relay networks? 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. What are the types of traffic that are usually given the highest preference for handling and transmission? 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. What are the available options for backing up a Frame Relay virtual circuit? 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. What is split horizon? How can split horizon be overcome on a partially meshed Frame Relay NBMA network? 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 linkstate 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: A1:

2: A2:

What is the Cisco IOS command required for enabling Frame Relay encapsulation on an interface? 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. What are the differences between static and dynamic address mapping? 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:

A3:

4: A4: 5:

A5:

What is the global configuration command required to configure a Cisco router as a Frame Relay switch? 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 framerelay intf-type dce command. The final frame-relay route command sets up the Frame Relay PVC switch connections. What is the command used for monitoring the contents of the address-to-DLCI mapping table? The command is show frame-relay map. What is the debug command used for analyzing the details of the packets sent out of an interface on a specific DLCI? 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: A2:

3: A3:

4: A4:

Identify the queuing components supported by Frame Relay Traffic Shaping. 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. Explain the method to set up different traffic shaping parameters for different Frame Relay PVCs. 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. Explain the main differences between adaptive shaping to BECN and adaptive shaping to ForeSight. 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:

A1:

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

A3:

4: A4:

5: A5:

What are the levels of congestion management supported by the Frame Relay Switching Enhancements feature? Frame Relay congestion management can be set up at the individual switched PVC level or at the interface level. What are the steps required to set up congestion management on the Frame Relay switch? 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. Identify the configuration mode and command required to enable Frame Relay traffic policing. 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: A2:

3: A3:

4:

A4:

What is the use of the event window parameter? 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. What are the common applications of the Frame Relay End-to-End Keepalive feature? Common uses include Frame Relay network management and backup applications. Frame Relay Endto-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. What are the likely consequences when the time intervals for the send and receive timers are misconfigured? 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: A1:

How do ATM and Frame Relay technologies compare? 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: A2:

3: A3:

4: A4:

5:

A5:

What is the purpose of Frame Relay to ATM Interworking? 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. How do FRF.5 network interworking and FRF.8.1 service interworking compare? 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. How do FRF.8.1 translation and transparent modes compare? 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. What happens when FRF.8.1 service interworking in the transparent mode is deployed between two pieces of terminal equipment with dissimilar encapsulation types? 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: A6:

7: A7:

What is the FRF.8.1 bidirectional congestion indication support? 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-toFrame 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. What is ATM equivalent to Frame Relay's DE bit? The ATM equivalent to Frame Relay's DE bit is the CLP bit.

Chapter 9 1: A1:

What is the main use of the Adaptive Frame Relay Traffic Shaping for Interface Congestion feature? 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: A3:

4:

A4:

5:

A5: 6:

A6:

What is the default queue depth for Frame Relay Adaptive Shaping for Interface Congestion? 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. What is the default queuing strategy at the interface level when Frame Relay Traffic Shaping is configured? The queuing strategy is FIFO. To configure FIFO queuing on an interface, use the no fair-queue interface configuration command. 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. The router throttles the VC egress rate from CIR to MINCIR. 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. The router increases the VC egress rate from MINCIR back to CIR.

Page 8 of 17

Chapter 10 1: A1:

2:

A2:

How do Frame Relay encapsulations using RFC 1490/RFC 2427 and RFC 1973 compare? 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. How do a Frame Relay DLCI configured to use RFC 1490/RFC 2427 and a Frame Relay DLCI configured with RFC 1973 compare? 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: A4:

5: A5:

6: A6:

What are the virtual template interface configurations used for in setting up PPP over Frame Relay? 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. What protocol in PPP negotiates the authentication process between two peer routers? 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. What protocol in PPP negotiates the network layer protocol transported by the PPP session? 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: A1:

What are the main differences between Frame Relay SVC and PVC implementations? 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: A2:

What are the common considerations for network designers when implementing Frame Relay SVCs? 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:

A3:

4:

A4:

5:

A5:

6:

A6:

How is call setup for Frame Relay SVC negotiated between Frame Relay DTE and the Frame Relay switch? 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. 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? 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. What are the types of addressing schemes for SVC supported by Cisco routers, and what are their differences? 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.. 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? 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: A1:

2: A2:

3: A3:

What are the main reasons for users to migrate their existing X.25 networks to Frame Relay? 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. What are the protocol differences between Frame Relay and X.25? 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. Name the main advantages and disadvantages of Frame Relay over X.25. 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: A4:

5:

A5:

What must the user check when configuring distance vector routing protocols over an X.25 interface? X.25 is a packet-switched protocol similar to Frame Relay, so it is likewise susceptible to the NonBroadcast 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. 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. 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:

A1:

2:

Describe the benefits of using Frame Relay QoS Autosense in setting up the Frame Relay Traffic Shaping feature on a group of Cisco routers. 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. 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:

4:

A4: 5:

A5:

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. Which IP address on the router is selected as the management IP address if autoaddress registration is used? By default, autoaddress registration selects the IP address of Ethernet interfaces on the router. 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? 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:

A1:

2: A2:

Compare the use of Multilink Frame Relay with that of separate physical interfaces to aggregate bandwidth. 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. Name the protocol that Multilink Frame Relay uses to establish a bundle. 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:

5:

A5:

6:

A6:

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. What is the Cisco IOS configuration command to configure a physical interface as a bundle link or a member of the bundle? The encapsulation frame-relay mfr mfr-number interface configuration command is used to configure a physical interface as a bundle link. 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? 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 outputthreshold 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:

2: A2:

3: A3:

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. How do header compression and payload compression compare? 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. How do Stacker and Predictor compression algorithms compare? 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:

A4:

What are the Cisco IOS configuration commands for Frame Relay required to enable payload compression on multipoint interfaces and point-to-point subinterfaces? 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:

A6:

What is the Cisco IOS show command that allows users to monitor the payload compression configurations on Cisco routers? 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: A1:

2: A2:

3:

A3:

4: A4:

5: A5:

What is fragmentation? 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. What is the primary purpose of fragmentation in Frame Relay? 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. How do Frame Relay FRF.12 Fragmentation, Frame Relay Fragmentation using FRF.11 Annex C, and Cisco proprietary fragmentation compare? 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. Describe the benefits of using Frame Relay Fragmentation with hardware compression support. 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. What is the purpose of the sequence number field in the Frame Relay header for fragmentation? 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: A1:

2: A2:

Define the role of queuing in Frame Relay. 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. Name the current queuing mechanisms for Frame Relay supported on Cisco routers. 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: A3:

4: A4:

5: A5:

6: A6:

What is Frame Relay PIPQ? 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. How do PVC-level queues and interface-level queues compare? 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. Describe the use of a Dual-FIFO queue in Frame Relay. 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. Describe the use of the Frame Relay broadcast queue. 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: A1:

2: A2:

3: A3:

4: A4:

5: A5:

Describe the use of Cisco's MQC configuration. 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. How do CBWFQ and WFQ compare? 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. How do LLQ and CBWFQ compare? LLQ is an extended version of CBWFQ, whereby a strict priority queue is supported for voice or other real-time delay-sensitive traffic. Describe the role of the priority queue in LLQ. 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). Describe the mechanism of LLQ for Frame Relay. 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 delaysensitive 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: A1:

2: A2:

3:

A3:

4: A4:

5:

A5:

Describe the benefits of the Frame Relay Queuing and Fragmentation at the Interface feature. 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. What is interleaving? Describe its main advantage. 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. What are the legacy Frame Relay functionalities that are mutually exclusive with the Frame Relay Queuing and Fragmentation at the Interface feature? 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. What is the purpose of the subrate shaper? 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. When subrate shaping is enabled, what component of Frame Relay Queuing and Fragmentation at the Interface is automatically disabled? Interleaving is automatically turned off.

Chapter 20 1: A1:

2: A2:

3: A3:

What are the main benefits of MLP LFI for Frame Relay? 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. What are the main applications of LFI? 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. What are the supported directions for load threshold calculation? The supported directions are inbound, outbound, or both.

Page 16 of 17

4: A4: 5: A5:

How is the fragment size for MLP LFI derived? The fragment size is typically based on the required delay of the delay-sensitive voice packet. How many links can an MLP bundle have on a Cisco router? An MPL bundle can have only one link.

Chapter 21 1: A1:

2: A2:

3: A3:

4: A4:

5: A5:

How do RED and WRED compare? 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. Explain why WRED is most useful with TCP protocol traffic. 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. What is the default queuing method used on an interface with speed greater than E1 (2.048 Mbps)? 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. What Cisco IOS show command can be used to verify the queuing method used on an interface? The show interface command can be used to verify the queuing method used on the specified interface. What is the Cisco IOS configuration command to enable FIFO queuing? To enable FIFO queuing on an interface, the no fair-queue command is used.

Page 17 of 17

Chapter 22 1: A1:

2: A2: 3:

A3:

4: A4:

What is the main purpose of using RSVP with real-time interactive traffic? 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. How much bandwidth is available for RSVP by default? By default, 75 percent of the bandwidth on an interface can be reserved by RSVP. What is the Cisco IOS command that allows users to change the default amount of bandwidth available for RSVP? The max-reserved-bandwidth percentage command allows users to change the default amount of bandwidth available for RSVP. What is the Cisco IOS command to verify the bandwidth available in the bandwidth pool? 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 StrataCom—developed 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 autodiscovery, 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(n–1)/2. Figure 1-8 considers an example of this scenario.

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

In the small organization in Figure 1-8, the end users at Remote Site A need to access the file server located at Remote Site B daily, but only during a certain period of the day. During the busiest time of the day, the average

size of the files transferred to and from the file server at Site B is only between 512 KB and 1 MB. At that time, the traffic between the central office and the users at remote sites consists mostly of e-mail and frequent database access and queries. In this scenario, the bandwidth of the dedicated connections between all three sites is mostly unused during part of the day, or the lines are underutilized. A Frame Relay solution is more suited for this topological requirement, the type of traffic, and the traffic pattern. Figure 1-9 illustrates the alternative solution using Frame Relay with a star topology. All three sites are now connected to a shared Frame Relay network. Instead of building dedicated and expensive physical leased-line circuits, the organization can lease logical PVCs from the Frame Relay provider to connect all three locations. Using Frame Relay, each location has to maintain only a Frame Relay access device and a single physical access line connected to the Frame Relay network (the single physical access line can be a T1 or an E1 circuit). Logical PVCs are provisioned between all three sites, and each site has a direct logical connection to every other location. Furthermore, depending on each location's traffic usage, the minimum required bandwidth for each logical PVC can be subscribed. The CIR can be increased later in small increments if business needs arise.

Figure 1-9. A Scalable Solution Using Frame Relay

In another example, a company with 10 remote sites would require a total of 45 physical leased-line connections to provide a fully meshed network. On the other hand, the same fully meshed requirement can be met by deploying a Frame Relay network with 45 logical PVC connections over 10 physical access lines. Dedicated leased-line circuits between remote sites are not only expensive to build and maintain but also take a longer period of time to order and implement. For example, if a sudden business need to connect two remote sites arises, building new leased lines can become a roadblock. However, if the two remote sites are already connected to an existing Frame Relay network, logical PVCs can be provisioned between them rapidly and easily. In this way, Frame Relay is much more flexible to meet a customer's requirements compared with the traditional leased-line circuits.

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

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

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

The Future of Frame Relay The phenomenal success of the Internet has made users' demand for more bandwidth ever increasing. Today's data networks support a variety of traffic with different characteristics and requirements for bandwidth. Among these are voice and video. Voice over IP and video on demand are now common applications on the Internet. Voice and video traffic are highly susceptible to latency and jitters. Applications that are more tolerant to time delay, such as FTP and e-mail, are still commonly used. Organizations face the challenge of obtaining more bandwidth to suit their business needs while preventing operating costs from rocketing sky high. Companies have to perform some form of queuing and prioritization of their traffic so that one category of traffic does not overwhelm the network and starve the others of necessary bandwidth. Cisco has contributed toward the advancement of Frame Relay by enabling routers to perform intelligent congestion control and management of traffic. In the same vein, fragmentation, compression, and quality of service features are other major enhancements to Frame Relay.

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

Table 1-1. Common Frame Relay Terminology Term

Definition

Description

CIR

Committed Information Rate

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

EIR

Excess Information Rate

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

Bc

Committed Burst

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

Be

Excess Burst

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

Tc

Committed Rate Measurement Interval

Tc is computed as Tc = Bc/CIR.

DLCI

Data Link Connection Identifier

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

LMI

Local Management Interface

A suite of maintenance protocols for Frame Relay.

PVC

Permanent Virtual Circuit

A logical connection that is permanently established.

SVC

Switched Virtual Circuit

A logical connection that is established only on demand.

VC

Virtual Circuit

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

DCE

Data Circuit-Terminating Equipment

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

DTE

Data Terminal Equipment

DTE devices use clocking provided by DCE devices.

Summary This chapter presented an overview of Frame Relay technology. Frame Relay is a popular Layer 2 packet-switched protocol designed to carry user traffic efficiently on high-speed digital circuits. Compared with Frame Relay, the legacy X.25 protocol has higher overheads and many drawbacks. Many vendors are developing new features to add to the benefits of Frame Relay. This chapter showed that the standard Frame Relay header is uncomplicated, although essential functionalities, such as addressing, congestion control, and notification, as well as FCS, are supported. This chapter discussed how the standardization of Frame Relay by major industry players resulted in the development of the LMI management features. The LMI features help to simplify the management of Frame Relay virtual circuit connections. The cost-effectiveness of Frame Relay was also illustrated in this chapter. The benefits of building a fully meshed network with logical Frame Relay PVCs, versus the traditional leased-line circuits, were highlighted. This chapter introduced the Frame Relay Forum, a worldwide association of Frame Relay vendors, carriers, manufacturers, and users. New Frame Relay implementations agreements and standards are developed by the Frame Relay Forum to ensure maximum operability and cooperation between vendors. The last part of the chapter defined and explained the most commonly used Frame Relay terminologies. The next chapter presents an overview of the Cisco implementation of Frame Relay and Cisco Frame Relay devices.

Review Questions 1:

What is Frame Relay?

2:

What is a virtual circuit?

3:

What are the differences between a PVC and an SVC?

4:

What is the CIR?

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/EIA–232— 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.




TIA–530— 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 costeffectively deliver Frame Relay, voice/video, or Asynchronous Transfer Mode (ATM) broadband services with endto-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 types—ANSI, Q.933-A, and Cisco, in that order—on 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 212 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. Wellplanned 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 Bandwidth—Capacity 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 36 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 missioncritical 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 missioncritical 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 lowspeed 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

RIP

High

EIGRP

Low

SAP

High

RTMP

High

EIGRP

Low

Transparent

High

Remote SRB

High

DLSW

Low (DLSW peer-ondemand)

IPX

AppleTalk

Bridging

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. R1(config)#interface serial4/2 R1(config-if)#no encapsulation frame-relay

End with CNTL/Z.

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. R1(config)#interface Ethernet1/0 R1(config-if)#encapsulation frame-relay ^ _% Invalid input detected at '^' marker.

End with CNTL/Z.

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

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 types—ANSI, Q933-A, and Cisco—in 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 framerelay 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 lmitype lmi-type interface configuration command. Disabling LMI autosense permits the user to specifically configure either the ANSI Annex D, the ITU Q933-A, or the Cisco LMI type to be used on an interface.

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

When manually configuring the LMI type on the Frame Relay interface, the selected LMI type on the router must match the LMI type supported by the connected Frame Relay switch. If there is a mismatch of the LMI type running on the Cisco router and its connected Frame Relay switch, the router will not be able to discover any assigned Frame Relay PVCs or maintain LMI status with the switch. Furthermore, individual Frame Relay PVCs configured under the same physical interface or subinterfaces cannot be set up to use a different LMI type. LMI type is configured only at the interface level. However, it is possible to allow individual Frame Relay PVCs under the same physical interface to use different Frame Relay encapsulations. The frame-relay map command allows the selected DLCI to use either Cisco or IETF Frame Relay encapsulation. The Frame Relay encapsulation type configured on the near-end Frame Relay device must match the Frame Relay encapsulation type configured on the far-end Frame Relay device. Table 4-1 summarizes the key points on the consistency of LMI and Frame Relay encapsulation types.

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

Configurable on Per-Interface Basis?

Configurable on PerDLCI Basis?

Frame Relay Encapsulation Type

End-to-end Frame Relay devices

Yes

Yes

Frame Relay LMI Type

Frame Relay device and connected Frame Relay switch

Yes

No

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

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

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

Example 4-10. Router Begins LMI Status Exchanges Directly with the Explicitly

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

When manually setting up the LMI type, it is necessary to configure the keepalive interval on the Frame Relay interface to prevent LMI status exchanges between the router and the Frame Relay switch from timing out. The LMI status exchange messages are used for the purpose of communication between the router and the switch to determine the status of the PVC connection. For example, a large mismatch in the keepalive interval on the router and the switch can cause the switch to declare the router dead. By default, the keepalive time interval is 10 seconds on Cisco serial interfaces. The keepalive interval can be changed with the keepalive interface configuration command. Refer to Example 4-11 for an example of configuring the keepalive on the interface.

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

End with CNTL/Z.

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 framerelay 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 Serial1/0 102 Serial1/1 201

Output Intf Serial1/1 Serial1/0

Output Dlci 201 102

Status active 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-toDLCI 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-toDLCI 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 ?

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

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

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

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

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 !

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

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

R3#show running-config Building configuration... ! hostname R3 !

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

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

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

! hostname SW !

! 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 Serial4/1 304 Serial4/3 403 SW#

Output Intf Serial4/3 Serial4/1

Output Dlci 403 304

Status active active

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

! hostname SW !

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

! hostname SW2 !

! 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

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 ! 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 ! 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 ! 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 ! interface Serial4/3

Serial4/3 102

Serial4/3 103

Serial4/3 105

Serial4/3 104

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 frame-relay route 103 interface frame-relay route 104 interface frame-relay route 105 interface SW#show frame-relay route Input Intf Input Dlci Serial1/0 201 Serial1/1 301 Serial1/7 501 Serial4/1 401 Serial4/3 102 Serial4/3 103 Serial4/3 104 Serial4/3 105 SW#

Serial1/0 Serial1/1 Serial4/1 Serial1/7

Output Intf Serial4/3 Serial4/3 Serial4/3 Serial4/3 Serial1/0 Serial1/1 Serial4/1 Serial1/7

201 301 401 501 Output Dlci 102 103 105 104 201 301 401 501

Status active active active active active active active active

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

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 ! 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 ! 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 ! 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 ! 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 frame-relay route 301 interface frame-relay route 401 interface frame-relay route 501 interface

Serial4/3 201

Serial4/3 301

Serial4/3 501

Serial4/3 401

Serial1/0 Serial1/1 Serial4/1 Serial1/7

101 101 101 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) Local Switched Unused

Active 1 0 0

Inactive 0 0 0

Deleted 0 0 0

Static 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 Serial1/0 101 Serial1/1 101 Serial1/7 101 Serial4/1 101 Serial4/3 201 Serial4/3 301 Serial4/3 401 Serial4/3 501

Output Intf Serial4/3 Serial4/3 Serial4/3 Serial4/3 Serial1/0 Serial1/1 Serial4/1 Serial1/7

Output Dlci 201 301 501 401 101 101 101 101

Status active active active active active active active 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, *Mar 1 01:16:39.235: FR encap = 0x64110300 *Mar 1 01:16:39.235: 80 00 00 00 08 06 00 0F 08 *Mar 1 01:16:39.239: AC 10 01 04 18 51 00 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, *Mar 1 01:16:44.899: FR encap = 0x30910300 *Mar 1 01:16:44.899: 80 00 00 00 08 06 00 0F 08 *Mar 1 01:16:44.899: AC 10 01 02 30 91 AC 10 01 *Mar 1 01:17:44.911: Serial1/2: FR ARP input *Mar 1 01:17:44.911: datagramstart = 0x7D0CCEE, *Mar 1 01:17:44.911: FR encap = 0x48D10300 *Mar 1 01:17:44.911: 80 00 00 00 08 06 00 0F 08 *Mar 1 01:17:44.911: AC 10 01 02 48 D1 AC 10 01

datagramsize = 34 00 02 04 00 08 00 00 00 01 02 00 00 datagramsize = 34 00 02 04 00 09 00 00 01 01 02 00 00 datagramsize = 34 00 02 04 00 09 00 00 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 framerelay 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): *Mar 1 01:37:28.195: Serial1/2(i): *Mar 1 01:37:31.203: Serial1/2(i): *Mar 1 01:37:34.203: Serial1/2(i):

dlci dlci dlci dlci

501(0x7C51), 501(0x7C51), 501(0x7C51), 501(0x7C51),

pkt pkt pkt pkt

type type type type

0x800, 0x800, 0x800, 0x800,

datagramsize datagramsize datagramsize datagramsize

53 53 53 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, delaysensitive 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 lowvolume 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 lowvolume 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.

Page 4 of 70

Ebook By Sabby

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 DualFIFO 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 DualFIFO 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 broadcastqueue 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 interfacelevel 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 delaysensitive 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 highpriority 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 highpriority and the low-priority interface queues, respectively. When assigning priority, in contrast with FRF.12, Frame Relay PIPQ does not take into consideration whether packets are fragmented or not. When FRF.12 is configured together with Frame Relay PIPQ, both voice packets and fragmented data packets carried by the same Frame Relay PVC go into an interface-level priority queue preassigned to that PVC by Frame Relay PIPQ. Although the Frame Relay PIPQ feature is independent of Frame Relay FRF.12 Fragmentation, it is always useful to enable FRF.12 on the Frame Relay PVC carrying voice traffic to prevent an unexpected large packet from causing latency or jitters for the mainstream voice packets. Table 17-1 summarizes the various interface-level queuing mechanisms that result from enabling certain Frame Relay features.

Table 17-1. Interface Queuing Strategy for Frame Relay Frame Relay Features

Interface Queuing Strategy

Frame Relay encapsulation without any features

If the interface speed is lower than E1, default is WFQ queuing. If the interface speed is greater than E1, default is FIFO queuing.

Frame Relay Traffic Shaping

FIFO queuing.

Frame Relay FRF.12 with FRTS

Dual-FIFO queuing.

Page 11 of 70

Frame Relay PIPQ (with or without FRTS or FRF.12)

Interface PQ.

To configure the Frame Relay PIPQ feature on a Cisco router, perform the following configuration steps, beginning from the global configuration mode: Step 1.

In the global configuration mode, first set up the PVC priority within a Frame Relay map class. Specify the map-class name with the map-class frame-relay map-class-name command. This enters you into the map-class configuration mode.

Step 2.

In the map-class configuration mode, assign a PVC priority level to a Frame Relay map class with the frame-relay interface-queue priority {high | medium | normal | low} map-class configuration command. When the map class is subsequently assigned to a Frame Relay DLCI, the configured priority level in the map class determines the PVC priority level for the traffic transported on that DLCI.

Step 3.

Enable Frame Relay PIPQ at the interface level with the frame-relay interface-queue priority [highlimit 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 interfacequeue 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:

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:

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:

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-andspoke 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 Serial2/0 Serial2/1 Serial2/2 Serial2/3 Serial4/1 Serial4/2 Serial4/3

Discard threshold 64 64 64 64 64 64 64

Dynamic queue count 256 256 256 256 256 256 256

Reserved queue count 0 0 0 0 0 0 0

Page 16 of 70

Current DLCI priority queue configuration: Interface Serial4/0

High limit 20

Medium limit 40

Normal limit 60

Low limit 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 higherpriority 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 02:07:47: PQ: Serial3/0 02:07:47: PQ: Serial3/0 02:07:47: PQ: Serial3/0 02:07:47: PQ: Serial3/0 02:07:47: PQ: Serial3/0 02:07:47: PQ: Serial3/0 02:07:47: PQ: Serial3/0 02:07:47: PQ: Serial3/0 02:07:47: PQ: Serial3/0 02:07:47: PQ: Serial3/0 02:07:47: PQ: Serial3/0 02:07:47: PQ: Serial3/0 02:07:47: PQ: Serial3/0 02:07:47: PQ: Serial3/0 02:07:47: PQ: Serial3/0 02:07:47: PQ: Serial3/0 02:07:47: PQ: Serial3/0 02:07:47: PQ: Serial3/0 02:07:47: PQ: Serial3/0 02:07:47: PQ: Serial3/0 02:07:47: PQ: Serial3/0 02:07:47: PQ: Serial3/0 02:07:47: PQ: Serial3/0 02:07:48: PQ: Serial3/0 02:07:48: PQ: Serial3/0 02:07:48: PQ: Serial3/0 02:07:48: PQ: Serial3/0 02:07:48: PQ: Serial3/0 02:07:48: PQ: Serial3/0 02:07:48: PQ: Serial3/0 02:07:48: PQ: Serial3/0 02:07:48: PQ: Serial3/0 02:07:48: PQ: Serial3/0 02:07:48: PQ: Serial3/0 02:07:48: PQ: Serial3/0 02:07:48: PQ: Serial3/0

dlci 104 -> low output (Pk size/Q 1002/3) dlci 104 -> low dlci 103 -> medium output (Pk size/Q 1002/1) dlci 104 -> low dlci 104 -> low output (Pk size/Q 1002/3) dlci 103 -> medium dlci 104 -> low output (Pk size/Q 1002/1) dlci 104 -> low dlci 103 -> medium output (Pk size/Q 1002/1) dlci 104 -> low dlci 104 -> low output (Pk size/Q 1002/3) dlci 103 -> medium dlci 104 -> low output (Pk size/Q 1002/1) dlci 104 -> low dlci 103 -> medium output (Pk size/Q 1002/1) dlci 104 -> low dlci 104 -> low output (Pk size/Q 1002/3) dlci 103 -> medium dlci 104 -> low output (Pk size/Q 1002/1) dlci 104 -> low dlci 103 -> medium output (Pk size/Q 1002/1) dlci 104 -> low output (Pk size/Q 1002/3) dlci 104 -> low dlci 103 -> medium 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 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 02:21:01: PQ: Serial3/0 dlci 102 -> high 02:21:01: PQ: Serial3/0 output (Pk size/Q 02:21:01: PQ: Serial3/0 output (Pk size/Q 02:21:01: PQ: Serial3/0 dlci 102 -> high 02:21:01: PQ: Serial3/0 output (Pk size/Q 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 02:21:01: PQ: Serial3/0 dlci 102 -> high 02:21:01: PQ: Serial3/0 output (Pk size/Q 02:21:01: PQ: Serial3/0 dlci 102 -> high 02:21:01: PQ: Serial3/0 output (Pk size/Q 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 02:21:01: PQ: Serial3/0 dlci 102 -> high 02:21:01: PQ: Serial3/0 output (Pk size/Q 02:21:01: PQ: Serial3/0 dlci 102 -> high 02:21:01: PQ: Serial3/0 output (Pk size/Q 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 02:21:01: PQ: Serial3/0 dlci 102 -> high 02:21:01: PQ: Serial3/0 output (Pk size/Q 02:21:01: PQ: Serial3/0 dlci 102 -> high 02:21:01: PQ: Serial3/0 output (Pk size/Q 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 02:21:01: PQ: Serial3/0 dlci 102 -> high 02:21:01: PQ: Serial3/0 output (Pk size/Q 02:21:01: PQ: Serial3/0 dlci 102 -> high 02:21:01: PQ: Serial3/0 output (Pk size/Q 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 02:21:02: PQ: Serial3/0 dlci 102 -> high 02:21:02: PQ: Serial3/0 output (Pk size/Q

1002/0)

72/0) 1002/0) 1002/0) 1002/0) 1002/0) 1002/0) 1002/0) 1002/0) 1002/0) 1002/0) 1002/0) 1002/0) 1002/0) 1002/0) 1002/0) 1002/0) 1002/0) 1002/0)

!20 seconds later after aggregated traffic from the DLCIs has saturated the Frame Relay link 02:21:19: 02:21:19: 02:21:19: 02:21:19: 02:21:19: 02:21:19: 02:21:19: 02:21:19: 02:21:19: 02:21:19: 02:21:19: 02:21:19: 02:21:19: 02:21:19: 02:21:19: 02:21:19: 02:21:19: 02:21:19: 02:21:19:

PQ: PQ: PQ: PQ: PQ: PQ: PQ: PQ: PQ: PQ: PQ: PQ: PQ: PQ: PQ: PQ: PQ: PQ: PQ:

Serial3/0 Serial3/0 Serial3/0 Serial3/0 Serial3/0 Serial3/0 Serial3/0 Serial3/0 Serial3/0 Serial3/0 Serial3/0 Serial3/0 Serial3/0 Serial3/0 Serial3/0 Serial3/0 Serial3/0 Serial3/0 Serial3/0

output (Pk size/Q 1002/0) dlci 102 -> high output (Pk size/Q 1002/0) dlci 104 -> low -- congestion drop dlci 102 -> high output (Pk size/Q 1002/0) dlci 102 -> high output (Pk size/Q 1002/0) dlci 102 -> high output (Pk size/Q 1002/0) dlci 104 -> low -- congestion drop dlci 102 -> high output (Pk size/Q 1002/0) dlci 102 -> high output (Pk size/Q 1002/0) dlci 102 -> high output (Pk size/Q 1002/0) dlci 104 -> low -- congestion drop 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 Reply Reply Reply

from from from from

172.16.3.1: 172.16.3.1: 172.16.3.1: 172.16.3.1:

bytes=32 bytes=32 bytes=32 bytes=32

timeping 200.200.200.1 Pinging 200.200.200.1 with 32 bytes of data: Reply Reply Reply Reply

from from from from

200.200.200.1: 200.200.200.1: 200.200.200.1: 200.200.200.1:

bytes=32 bytes=32 bytes=32 bytes=32

time=180ms time=170ms time=170ms time=171ms

TTL=254 TTL=254 TTL=254 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 nonmission-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

An incoming call when the user has sent acknowledgement that the user has received all call information necessary to effect call establishment.

Active

Called side: Network indicates that the calling user has been awarded the call. Calling Side: When the remote user answers the call.

Disconnect Request

User has requested the network to clear the endto-end call and is waiting for response.

Disconnect Indication

The user has received an invitation to disconnect because the network has disconnected the connection.

Release Request

The user has requested the network to release and is waiting for a response.

SVC Addressing Plan—E.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 UnionTelecommunication 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. 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)#

End with CNTL/Z.

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

Purpose

frame-relay customqueue-list list-number

Specifies a custom queue list to be used with the map class associated with an SVC. A custom queue list for custom queuing has to be defined by the user.

frame-relay prioritygroup list-number

Specifies a priority queue list to be used with the map class associated with an SVC. A priority list for priority queuing has to be defined by the user.

frame-relay adaptiveshaping [becn | foresight]

Enables adaptive traffic shaping on the SVC using either BECN or ForeSight mode.

frame-relay cir {in|out} bps

Specifies the inbound or outbound CIR in bits per second.

frame-relay mincir {in|out} bps

Specifies the inbound or outbound minimum CIR in bits per second. By default, the mincir is half of the configured CIR value.

frame-relay bc {in|out} bits

Specifies the inbound or outbound committed burst in bits.

frame-relay be {in|out} bits

Specifies the inbound or outbound excess burst (Be) in bits.

To configure a Frame Relay SVC map group with either E.164 or X.121 addressing, use the map-list map-group-name sourceaddr {e164 | x121} source-address dest-addr {e164 | x121} destination-address global configuration command. The mapgroup-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 Router(config-map-list)#ip 192.168.1.1 class svc_class

e164 654321

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 t203

set LAPF T200, the retransmission time period in 1/10 seconds 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 maplist-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 maplist-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 C

172.16.0.0/24 is subnetted, 1 subnets 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

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

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

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

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) Local Switched Unused

Active 0 0 1

Inactive 0 0 0

Deleted 0 0 0

Static 0 0 0

DLCI = 100, DLCI USAGE = UNUSED, PVC STATUS = ACTIVE, INTERFACE = Serial3/2 input pkts 0 out bytes 0 out pkts dropped 0

output pkts 0 in bytes 0 dropped pkts 0 in 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) Local Switched Unused

Active 0 0 1

Inactive 0 0 0

Deleted 0 0 0

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

Set default input window (maximum unacknowledged packets) 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:

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

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

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

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

172.16.0.0/24 is subnetted, 1 subnets 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: 21:25:06: 21:25:06: 21:25:06: 21:25:06: 21:25:06: 21:25:06: 21:25:07: 21:25:07: 21:25:07:

annexg_restart_tx: annexg_restart_tx: annexg_restart_tx: annexg_restart_tx: annexg_restart_tx: annexg_restart_tx: annexg_restart_tx: annexg_restart_tx: annexg_restart_tx: annexg_restart_tx:

sending sending sending sending sending sending sending sending sending sending

pak pak pak pak pak pak pak pak pak pak

to to to to to to to to to to

Serial3/2 Serial3/2 Serial3/2 Serial3/2 Serial3/2 Serial3/2 Serial3/2 Serial3/2 Serial3/2 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 statuses—such as network congestion, creation of new switched virtual circuits (SVCs), and polling of virtual circuit (VC) connection status—can 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-toend 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

Syntax/Values Description

cfrElmiIpAddr

IpAddress/Read only

This represents the management address of the device used for address registration.

CfrElmiLinkStatus

Integer/ Read only

This indicates whether ELMI is enabled on a Frame Relay interface: enabled(1), disabled(2).

cfrElmiArStatus

Integer/ Read only

This variable indicates whether ELMI AR is enabled or not on a Frame Relay interface. A value of 1 indicates ELMI AR is supported on the interface. A value of 2 indicates ELMI AR is supported, but the user disabled the exchange of IP address and IfIndex with the neighboring device.

cfrElmiRemoteStatus

Integer/ Read only

This variable states the ELMI status on the other end of the interface. If cfrElmiLinkStatus is enabled on the other end, a value of 1 is returned, otherwise 2 is returned.

cfrElmiNeighborArStatus

Integer/ Read only

This variable indicates the status of ELMI AR on the neighboring device. A value of 1 indicates ELMI AR is not supported on the neighboring device. A value of 2 indicates ELMI AR is enabled on the interface. A value of 3 indicates AR is supported, but the user disabled the exchange of IP address and IfIndex with the neighbor.

cfrElmiNeighborIpAddress

IpAddress/Read only

The management IP address of the neighboring device to which the other end of this interface is connected. NMS can use this address to send management messages to the device. If Address Registration is not supported on the remote end, the value is 0.0.0.0. NMS uses this object in the topology

Page 74 of 141

discovery of the network. CfrElmiNeighborIfIndex

Integer/ Read only

The interface index of the neighboring device to which this interface is connected. If the value of cfrElmiNeighborArStatus is 2, this has a valid value. If the value of cfrElmiNeighborArStatus is 3 or 1, the value of this object is 0. NMS uses this object in the topology discovery of the network.

CfrElmiNeighborVendorName

String/Read Only

Vendor name of the neighboring device to which the other end of this interface is connected.

cfrElmiNeighborPlatformName String/Read Only

Platform name of the neighboring device to which the other end of this interface is connected.

cfrElmiNeighborDeviceName

Device name of the neighboring device to which the other end of this interface is connected.

String/Read Only

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

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 Clocking: Normal Neighbor IP Add: 0.0.0.0 Port ID 0 Port Queue Depth 65535 ECN Queue Threshold 65535 DE Threshold 100 % Signalling Protocol Annex A UNI -E Asynchronous Status Yes T392 Polling Verif Timer 15 N392 Error Threshold 4 N393 Monitored Events Count 4 Communicate Priority No Upper/Lower RNR Thresh 75%/ 25%

Configured Clock: 256 Measured Rx Clock: 256 Neighbor IfIndex: 7 Min Flags / Frames 1 OAM Pkt Threshold 3 T391 Link Intg Timer 25 N391 Full Status Poll 3 EFCI Mapping Enabled No CLLM Enabled/Tx Timer No/ 0 IDE to DE Mapping Yes Interface Control Template Lead CTS DSR DCD State ON ON ON Neighbor Discovery Disable

Port: 11.5 [ACTIVE Interface: V35 DCE Clocking: Normal Neighbor IP Add: 0.0.0.0 Port ID 0 Port Queue Depth 65535 ECN Queue Threshold 65535 DE Threshold 100 % Signalling Protocol Annex A UNI -E Asynchronous Status Yes T392 Polling Verif Timer 15 N392 Error Threshold 4 N393 Monitored Events Count 4 Communicate Priority No Upper/Lower RNR Thresh 75%/ 25%

] Configured Clock: 256 Measured Rx Clock: 256 Neighbor IfIndex: 9 Min Flags / Frames 1 OAM Pkt Threshold 3 T391 Link Intg Timer 25 N391 Full Status Poll 3 EFCI Mapping Enabled No CLLM Enabled/Tx Timer No/ 0 IDE to DE Mapping Yes Interface Control Template Lead CTS DSR DCD State ON ON ON Neighbor Discovery Disable

Kbps Kbps pkts sec cyl msec

Kbps Kbps pkts sec cyl msec

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 MIR CIR 16/16 64/64

wan_igx1 Bc 6000/6000

11.11.100 Be 5000/5000

Cmax 10/10

fr Status:OK ECN QThresh QIR 65535/65535 56/56

Pri: L

Test-RTD: 0 msec

Path:

Route information not applicable for local connections

IGX UFI:

UFMU:

FST: n

% Util: 100/100

OK

OK

! DLCI 200 Conn: 11.5.200 MIR CIR 16/16 64/64

wan_igx1 Bc 6000/6000

11.5.200 Be 5000/5000

Cmax 10/10

fr Status:OK ECN QThresh QIR 65535/65535 56/56

Pri: L

Test-RTD: 0 msec

Path:

Route information not applicable for local connections

IGX UFI:

UFMU:

FST: n

% Util: 100/100

OK

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

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 = cfrElmiLinkStatus.9 = cfrElmiArStatus.7 = 1 cfrElmiArStatus.9 = 1 cfrElmiRemoteStatus.7 cfrElmiRemoteStatus.9

1 1 = 1 = 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 switchside 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

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. R1(config)#interface ethernet1/0 R1(config-if)#shutdown R1(config-if)#end R1#

End with CNTL/Z.

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 *Sep 25 07:42:33.235: 20 20 20 20 20 20 20 37 32 30 36 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 *Sep 25 07:42:33.235: 20 20 20 20 20 01 00 00 00 07 AC 10 01 01 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

20 20 20 00

Page 83 of 141

*Sep *Sep *Sep *Sep *Sep *Sep *Sep *Sep *Sep

25 25 25 25 25 25 25 25 25

07:42:33.243: 07:42:33.243: 07:42:33.243: 07:42:33.243: 07:42:33.247: 07:42:33.247: 07:42:33.247: 07:42:33.247: 07:42:33.247:

FR 00 20 20 20 00

encap 7D 51 20 20 20 20 20 20 00 00

= 0x00010308 01 08 09 3D 09 20 20 20 20 49 20 20 20 53 57 20 20 02 00 00 80

43 47 49 00

49 58 54 00

53 20 43 00

43 20 48 00

4F 20 20 00

20 20 20 00

20 20 20 00

20 20 20 00

ELMI: received version status, version type = Enhanced 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" 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 huband-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

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

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

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 C

172.16.0.0/24 is subnetted, 1 subnets 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. R1(config)#interface mfr0 R1(config-if)#encapsulation ? frame-relay Frame Relay networks

End with CNTL/Z

R1(config-if)#encapsulation frame-relay ? ietf Use RFC1490/RFC2427 encapsulation

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 lmi-type local-dlci map multicast-dlci payload-compression policing priority-dlci-group qos-autosense route svc traffic-shaping traps-maximum

set DCE polling verification timer Use CISCO-ANSI-CCITT type LMI Set source DLCI when LMI is not supported Map a protocol address to a DLCI address Set DLCI of a multicast group Use payload compression Enable Frame Relay policing Define a priority group of DLCIs enable QOS autosense frame relay route for pvc switching Enable frame relay SVCs Enable Frame Relay Traffic Shaping 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

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

! 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. R1(config)#interface mfr0 R1(config-if)#shutdown R1(config-if)#no shutdown R1(config-if)#end

End with CNTL/Z

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. R2(config)#interface s3/3

End with CNTL/Z

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. R2(config)#interface s3/3 R2(config-if)#shutdown R2(config-if)#end R2#

End with CNTL/Z

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 clientserver 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 hardwarebased 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 packetby-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

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

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

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 framerelay 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 protocoladdress 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 framerelay 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 headercompression [active | passive] interface configuration command can also be used to explicitly remove the configured RTP header compression for the specified DLCI.

Step 5.

(optional) To specify the maximum number of RTP header compression connections that can exist on a Frame Relay interface, the frame-relay ip rtp compression-connections interface configuration command is used. There is no default value associated with the maximum number of allowed RTP header compression connections over Frame Relay. The ip rtp compression-connections number configuration command for PPP or HDLC interfaces, however, has a default value of 32 (16 calls) allowed RTP connections.

Example 15-6 shows a configuration example for RTP header compression on a Cisco router.

Example 15-6. Configuration Example of RTP Header Compression on a Cisco Router interface Serial2/3 ip address 172.16.1.1 255.255.255.0 encapsulation frame-relay frame-relay map ip 172.16.1.2 100 broadcast frame-relay ip rtp header-compression ! interface Serial2/3.200 multipoint ip address 192.168.1.1 255.255.255.0 frame-relay map ip 192.168.1.2 300 CISCO rtp header-compression passive

It is possible to configure both TCP/IP and RTP header compression on a Frame Relay interface with a single command. The frame-relay map ip protocol-address dlci [broadcast] compress [active | passive] interface configuration command can be used to enable both TCP/IP and RTP header compression for the specified link. Table 15-2 shows the supported Cisco IOS software releases for the various Frame Relay compression algorithms discussed.

Table 15-2. Summary of Cisco IOS Software Release Support for Compression Algorithms

Compression Algorithm

Released in Cisco IOS Software Version

Frame Relay Encapsulation Type Supported

TCP/IP header compression

10.0

Cisco only

Cisco proprietary payload compression

11.2

Cisco or IETF

FRF.9 payload compression

11.3

Cisco or IETF

RTP header compression

11.3

Cisco only

Cisco data-stream hardware

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

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

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

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

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 mapclass 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 similarsized 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 framerelay 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 CPUintensive 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 datastream stac configuration command is used. For a multipoint interface or subinterface, the frame-relay map protocol protocoladdress 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 protocoladdress 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, 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

RELEASE SOFTWARE (fc2)

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

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

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: Compressed bytes recv: 10160 bytes 1 Kbits/sec ratio: 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: Compressed bytes recv: 10700 bytes 0 Kbits/sec ratio: 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

0.884 0.000

0.883 0.000

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:

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:

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:

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:

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 Serial3/3 200 end-to-end

frag-size 100

in-frag 0

out-frag 0

dropped-frag 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 fragmentation—are 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:

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:

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 mapclass-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 Serial2/1.104 Serial2/1.104 Serial2/1.103 Serial2/1.103

vofr-type VoFR cisco VoFR cisco VoFR VoFR

dlci 104 104 103 103

cid 4 5 4 5

cid-type data voice call-control data 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 Serial2/1.102 102 end-to-end 100 68 68 Serial2/1.103 103 VoFR 100 68 68 Serial2/1.104 104 VoFR-cisco 100 68 68 ________________________________________________________________ R2#show frame-relay fragment interface dlci frag-type frag-size in-frag out-frag Serial3/1.201 201 end-to-end 100 68 68 Serial3/1.301 301 VoFR 100 68 68 Serial3/1.401 401 VoFR-cisco 100 68 68

dropped-frag 0 0 0 dropped-frag 0 0 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 128kbps 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 1610 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:

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:

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