In this short blog post, we are going to give condensed overview of the four main flavors of Frame-Relay Traffic Shaping (FRTS). Historically, as IOS evolved with time, different methods have been introduced, having various level of feature support. Two main features, specific to Frame-Relay Traffic-Shaping are per-VC shaping and queueing and adaptive shaping in response to Frame-Rleay congestion notifications (e.g. BECNs). You’ll see that not every flavor supports these two features. We begin with the «fossil» known as Generic Traffic Shaping.

Generic Traffic Shaping

This feature was initially designed to shape packet traffic sent over any media, be it Ethernet, Frame-Relay, PPP etc. The command syntax is traffic-shape {rate|group} and allows specifying traffic scope using an access-list (notice that different ACL types are supported). You may tune the Bc/Be values as well as the shaping queue depth (amount of buffers). If the shaper delays traffic, the queue service strategy would be fixed to WFQ with the queue size equal to the buffer space allocated. Additional WFQ parameters such as number of flows and congestive discard threshold could not be tuned and set based on the shaper rate automatically.

An unique feature of GTS is the ability to apply multiple shapers to a single interface. However, shapers are not cascaded, but rather a packet is assigned to the first matching shaper rule. In the example below, there are three rules, with the last one being “fallback”, matching all packets that didn’t match access-lists 100 and 101. Unlike using the legacy CAR feature (rate-limit command) you cannot «cascade» multiple traffic-shape statements on the same interface, i.e. there is no “continue” action.

traffic-shape group 100 128000
traffic-shape group 101 64000
traffic-shape group 199 256000
access-list 199 permit ip any any

You cannot apply GTS per-VC unless you have created a subinterface for this particular PVC. You may, however, enable shaping that adapts to FR BECNs, using the syntax traffic-shape adaptive {rate} along with traffic-shape rate. Notice that if multiple PVCs map to interface, reception of a BECN on any of the VCs will trigger speed throttling.

Legacy Frame-Relay Traffic-Shaping

This feature uses the map-class frame-relay syntax and was initially designed to implement specifically Frame-Relay Traffic Shaping and Policing (FRTS and FRTP) in Cisco IOS routers. This is still probably the most widely used form of FRTS. You specify all parameters under a map-class and then apply this map-class to a specific PVC or interface using the syntax similar to the following:

map-class frame-relay DLCI_101
 frame-relay cir 256000
 frame-relay bc 2560
 frame-relay be 0
 frame-relay mincir 192000
 frame-relay adaptive-shaping becn
interface Serial 0/0
 frame-relay traffic-shaping
interface Serial 0/0.1
 frame-relay interface-dlci 101
  class DLCI_101

A mandatory command that goes with Legacy FRTS is frame-relay traffic-shaping applied to an interface (there is also frame-relay policing command to implement traffic policing). With this command applied, all PVC CIRs are set to default 56Kbps unless you change that value in a map-class that you apply. Additionally, interface software queue is turned into FIFO, and every PVC gets its own, second-level, logical queue realized as shaper’s queue. Therefore, FRTS enables “true” FRTS by allowing for two-level queueing hierarchy.

Legacy FRTS allows for various queueing methods on per-VC level. You may use any of legacy techniques such as Custom Queueing, Priority Queueing, FIFO and WFQ/IP RTP Priority. More importantly, you may enable CBWFQ on per-VC level, by using the map-class command service-policy output along with the policy-map implementing CBWFQ logic. Note that if you apply CBWFQ per-VC, the maximum avaiable bandwidth is based on minCIR settings for a VC, not the CIR.

All the above QoS mechanisms could be combined with Per-VC fragmentation enabled solely by using the map-class command frame-relay fragment. Normally, you need to enable fragmentation on every PVC terminated on the interface, so make sure you configure all map-classes properly. As soon as fragmentation is enabled, the interface-level FIFO queue is turned into special «truncated» Priority Queue used for interleaving fragments and voice packets. Only High and Normal queues out of the PQ are used to implement interleaving and you can inspect queue utilization using the command show queueing.

Obviously enough, you cannot use GTS on the same interface where FRTS has been enabled and vice-versa – IOS will reject the command. Compared to GTS, legacy FRTS provide a lot of syntactical consistency – you apply all features using the map-class commands plus you have a rich selection of QoS mechanisms along with that.

(BTW, if you’re wondering the purpose of frame-relay tc command under a map-class, it is used in zero-CIR scenarios for traffic policing. With zero-CIR policing all traffic is considered exceeding, but you may want to specify the peak rate by setting Be and Tc together).

MQC Frame-Relay Traffic-Shaping

This was Сisco’s attempt to leverage MQC syntax for the purpose of traffic-shaping. The problem was that the syntax is still combined with the “legacy” style map-class syntax. Here’s how it works:

  • You create a «first-level» policy-map implementing shaping for a VC. You can only use «class-default» at this level, and apply shaping parameters using the commands shape average, shape peak, and shape adaptive. For example:
    policy-map SHAPE
     class class-default
        shape average 512000 5120 0
        shape adaptive 256000
  • You create «nested» or «second-level» policy that implements CBWFQ. Note that CBWFQ/LLQ is the only queueing method supported with MQC-based FRTS (no CQ or PQ allowed, though you can emulate WFQ using MQC syntax).
    policy-map CBWFQ
      class VOICE
       priority 128
      class class-default
  • Combine both policy-maps and attach the parent policy to a map class. You should not enable the interface-level command frame-relay traffic-shaping with MQC FRTS.
    policy-map SHAPE
      class class-default
       service-policy CBWFQ
    map-class frame-relay DLCI_101
      service-policy output SHAPE
    interface Serial 0/0.1
      frame-relay interface-dlci 101
       class DLCI_101

From the above configuration example it is apparent that PVC shaping settings are now defined using the MQC shape average and shape adaptive commands. Similar to the use of CBWFQ with legacy FRTS, available CBWFQ bandwidth is based on the shape adaptive setting. Also, as mentioned before, you should not use the command frame-relay traffic-shaping with MQC FRTS. In fact, legacy FRTS and MQC FRTS are incompatible.

Frame-Relay Fragmentation (FRF.12) is supported with MQC FRTS, however you have to enable it at the interface level using the command frame-relay fragment X end-to-end. Interleaving queue is created automatically and cannot be seen using IOS show commands. Fragmentation is enabled on all PVCs terminated at the interface.
Compared to legacy FRTS, the MQC equivalent has some unique features, known as «Voice Adaptive Shaping» and «Voice Adaptive Fragmentation». The first feature activates adaptive shaping when packets are detected in the LLQ queue (if there is one configured) and the second feature activates fragmentation under the same condition of traffic present in the LLQ. The first feature is useful in oversubscription scenario, where you want to slow down from peak rate to committed rate when sending VoIP traffic to ensure better voice quality. The second feature is more useful, and allows you enabling traffic fragmentation only when it’s really needed, i.e. when a voice calls is active.

Class Based Generic Traffic Shaping (CB-GTS)

The last method is based purely on MQC syntax using the generic commad shape average. In many senses, it’s similar to the legacy GTS but uses newer syntax and supports more granular application. Have a look at the following example:

policy-map SHAPE_DLCI_101
  class class-default
   shape average 256000
! You can match DLCI's in class-maps
class-map DLCI_202
 match fr-dlci 202
policy-map SHAPE_DLCI_202
  class DLCI_202
   service-policy SHAPE_DLCI_202
interface Serial 0/0
  service-policy output INTERFACE_POLICY
interface Serial 0/0.1
  frame-relay interface-dlci 101
  service-policy output SHAPE_DLCI_101

The above example shows you two approaches to implementing VC-specific shaping. The first one uses a specific subinterface and the second one uses a class-map matching specific DLCI. The first method more reminds the legacy GTS, while the second allows pushing all VC policy under a single policy-map. Of course, you can always nest another MQC policy under a shaped class and implement CBWFQ and/or traffic marking/policing, just like you would do with any normal MQC configuration. FRF.12 fragmentation is also supported by means of the interface-level command frame-relay fragment, the same used with MQC FRTS.

Now for the CB-GTS limitation. There is a bunch, unfortunately. first of all, adaptive shaping does not work with CB-GTS i.e. the command shape average does not have any effect. Secondly, you may enable fragmentation at the interface level, but you cannot use any of MQC-based FRTS features, such as voice-adaptive fragmentation and shaping. Therefore, CB-GTS is not exactly a Frame-Relay Traffic Shaping solution, though it allows for generic shaping on per-VC basis.


As IOS software was evolving, multiple approaches to FRTS have been developed. Possibly the most commonly used one nowaday is Legacy FRTS, which supports practically all features with except to adaptive shaping/fragmentation availabled with MQC FRTS only. Even though from today’s perspective MQC CB-GTS seems to be the most reasonable method, it does yet lack support of such important feature as adaptive shaping. It’s up to you to select the best method, but be aware of their limitations.

About Petr Lapukhov, 4xCCIE/CCDE:

Petr Lapukhov's career in IT begain in 1988 with a focus on computer programming, and progressed into networking with his first exposure to Novell NetWare in 1991. Initially involved with Kazan State University's campus network support and UNIX system administration, he went through the path of becoming a networking consultant, taking part in many network deployment projects. Petr currently has over 12 years of experience working in the Cisco networking field, and is the only person in the world to have obtained four CCIEs in under two years, passing each on his first attempt. Petr is an exceptional case in that he has been working with all of the technologies covered in his four CCIE tracks (R&S, Security, SP, and Voice) on a daily basis for many years. When not actively teaching classes, developing self-paced products, studying for the CCDE Practical & the CCIE Storage Lab Exam, and completing his PhD in Applied Mathematics.

Find all posts by Petr Lapukhov, 4xCCIE/CCDE | Visit Website

You can leave a response, or trackback from your own site.

10 Responses to “The Four Flavors of Frame-Relay Traffic Shaping”

  1. Mike says:

    Would there be a reason to use MQC GTS over CB GTS for frame relay? It appears MQC does it all.

  2. ErickB says:

    Very nice blog entry. It was very helpful.

    Are all 4 flavors of FRTS you described compatible with PIPQ?

    • @ErickB

      It works with Legacy FRTS for sure, replacing the interface FIFO with four priority queues. I guess no one tried using that with other flavors, as PIPQ is one very specific feature that is not really required in production now. It should be working with all these, as GTS and MQC FRTS do not affect interface-level queueing.

  3. Eric says:

    Hi Petr,

    Thanks for another great blog entry.

    I just need a quick clarification. When you describe the limitations of CB-GTS for FR, you said :

    “Now for the CB-GTS limitation. There is a bunch, unfortunately. first of all, adaptive shaping does not work with CB-GTS i.e. the command shape average does not have any effect.”

    Did you mean that the command “shape adaptive” does not have any effect instead of “shape average”? Is this a simple typo?



  4. Kevin says:

    Hi Petr, great post. Can you advise what would the config look like when using MLPPP and a Multilink interface?

  5. Justin says:

    I was playing around with this today and was unable to apply multiple shapers the way you did. I could either apply multiple traffic-shaping group commands or a single traffic-shaping rate command.

    Am I missing something or is this a typo?

  6. K says:

    Now for the CB-GTS limitation. There is a bunch, unfortunately. first of all, adaptive shaping does not work with CB-GTS i.e. the command shape average does not have any effect.
    what does it mean? as follows does not work ?
    class-map DLCI
    match fr-dlci 101
    policy-map TS
    class DLCI
    shape average 128000
    shape ataptive 64000
    int s0/0
    encap frame-relay
    service-policy output TS

  7. Jorge Nolla says:

    frame-relay adaptive-shaping interface-congestion

    In there an equivalent MQC configuration for shaping based on interface congestion?

  8. Adam says:

    Hi Peter ,

    I have been going through Qos SRND .I have been reading your blog on FRTS and my doubt is that in SRND it has been mentioned that you enable FRF.12 under map-class command and in your blog it has been specified that FRF.12 should be given on main interface .
    (Qos SRND Page 205-206)

    Is there any problem in applying these to map-class rather than on main interface ?


Leave a Reply


CCIE Bloggers