Skip to main content
  1. Posts/

FRTS Fun?. (Frame Relay Traffic Shaping)

·6 mins

Over the past week or so I have been going over FRTS for my CCIE studies.

It’s something that I have covered before when studying for my QoS exam and skimmed over when studying for my ROUTE exam but up until now it has never actually stuck.

As others on Twitter have suggested maybe it’s because FRTS is an old technology and not really used anymore, that may be the case but I still remember all the intricacies of frame-relay and those have no problem staying in.

In this post I just thought I would go over the basics of FRTS, how to implement it and the various show commands to help you along the way.

There are several methods of applying FRTS, there is:

  • FRTS in map-class using the traffic-rate command
  • FRTS in map-class using the frame-relay shaping commands
  • FRTS in the MQC

When you apply FRTS there are several points to consider, a few of the most important ones are below:

  • You can only use it on frame relay interfaces (this really goes without saying)
  • FRTS is applied to each PVC on an interface individually
  • You cannot use any other queueing methods on the physical interface alongside FRTS

General FRTS notes #

When you apply FRTS it is applied in a hierarchical manner and if it is not applied at a specific level it inherits the settings of the next option (if that makes sense).

The order of this hierachy is:

  1. If the class map-class-name is applied to the interface-dlci command then this governs the FRTS on that VC
  2. If the class map-class-name is applied to the subinterface then this governs the FRTS on any VC’s on that subinterface that don’t match #1
  3. If the class map-class-name is applied to the interface this this governs the FRTS on any subinterfaces/VC’s on that interface that don’t match #1 or #2
  4. If none of the above are applied but the frame-relay traffic-shaping is still applied then all VC’s will default to shaping to 56kbps

To enable FRTS you first need to use the frame-relay traffic -shaping command, this will enable FRTS on that particular interface (it has to be applied at interface level).

The below snippet shows an interface that has the above command applied but no class applied, therefore it defaults to point #4 and shapes all VC’s to 56kbps.

R1#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
R1(config)#interface Se1/0
R1(config-if)#frame-relay traffic-shaping
R1(config-if)#end
R1#show traffic-shape

Interface   Se1/0
       Access Target    Byte   Sustain   Excess    Interval  Increment Adapt
VC     List   Rate      Limit  bits/int  bits/int  (ms)      (bytes)   Active
103           56000     875    7000      0         125       875       -
102           56000     875    7000      0         125       875       -

FRTS with the traffic-rate command #

To apply simple shaping you can give the map-class a required shaping rate and let it work out the rest, whilst this is the quick and dirty method it does mean that you can’t manually tweak all the parameters that we have come use to being able to tweak (Bc, Be, Tc etc.).

After you have enabled frame-relay traffic-shaping (as shown above) you need to define and apply the map-class to an interface/subinterface/DLCI:

R1(config)#int Serial1/0
R1(config-if)#frame-relay class shape_to_128
R1(config)#map-class frame-relay shape_to_128
R1(config-map-class)#frame-relay traffic-rate ?
  <600-45000000>  Committed Information Rate (CIR)

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

As you can see the command is simple and is applied in bps. By using the show traffic-shape command you can see that this has set the FRTS to 128kbps for all VC’s under Serial1/0

R1#show traffic-shape

Interface   Se1/0
       Access Target    Byte   Sustain   Excess    Interval  Increment Adapt
VC     List   Rate      Limit  bits/int  bits/int  (ms)      (bytes)   Active
103           128000    2000   128000    0         125       2000      -
102           128000    2000   128000    0         125       2000      -

You can also use the below command to show you some more details on a per-VC level

R1#show frame-relay pvc 102

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

DLCI = 102, DLCI USAGE = UNUSED, PVC STATUS = ACTIVE, INTERFACE = Serial1/0

input pkts 466           output pkts 0            in bytes 5126
  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:22:40, last time pvc status changed 00:22:40
  cir 128000    bc 128000    be 0         byte limit 2000   interval 125
  mincir 64000     byte increment 2000  Adaptive Shaping none
  pkts 0         bytes 0         pkts delayed 0         bytes delayed 0
  shaping inactive
  traffic shaping drops 0
  Queueing strategy: fifo
  Output queue 0/40, 0 drop, 0 dequeued

Whilst the above is a little more ‘in-your-face’ it does break down the shaping into the Bc, Be and interval settings that we are used to seeing in regular CB-shaping.

FRTS using the explicit commands #

Using the explicit commands under the map-class is very similar to the above however it allows us to set the variables individually.

R1#conf t
R1(config)#map-class frame-relay shape_to_128
R1(config-map-class)#frame-relay ?
  adaptive-shaping   Adaptive traffic rate adjustment, Default = none
  bc                 Committed burst size (Bc), Default = 7000 bits
  be                 Excess burst size (Be), Default = 0 bits
  cir                Committed Information Rate (CIR), Default = 56000 bps
  congestion         Congestion management parameters
  custom-queue-list  VC custom queueing
  end-to-end         Configure frame-relay end-to-end VC parameters
  fair-queue         VC fair queueing
  fecn-adapt         Enable Traffic Shaping reflection of FECN as BECN
  fragment           fragmentation - Requires Frame Relay traffic-shaping to be
                     configured at the interface level
  holdq              Hold queue size for VC
  idle-timer         Idle timeout for a SVC, Default = 120 sec
  interface-queue    PVC interface queue parameters
  ip                 Assign a priority queue for RTP streams
  iphc-profile       Configure IPHC profile
  mincir             Minimum acceptable CIR, Default = CIR/2 bps
  priority-group     VC priority queueing
  tc                 Policing Measurement Interval (Tc)
  traffic-rate       VC traffic rate
  voice              voice options

R1(config-map-class)#frame-relay cir 128000
R1(config-map-class)#frame-relay bc 1280
R1(config-map-class)#end

R1#sh traffic-shape 

Interface   Se1/0
       Access Target    Byte   Sustain   Excess    Interval  Increment Adapt
VC     List   Rate      Limit  bits/int  bits/int  (ms)      (bytes)   Active
103           128000    160    1280      0         10        160       -
102           128000    160    1280      0         10        160       -

The above configures the same 128kbps rate that was configured in the first part of this post however it manually set the Bc value to 100th of the CIR in order to make the Tc to be 10ms (using the Tc = CIR / Bc formula).

Conclusion… #

Although Cisco are striding to get rid of the old QoS tools for the more favorable MQC method there are still some of the old methods around, one of these is FRTS as described above.

You can now ( as of?12.2(13)T ) also do shaping on frame-relay interfaces in the regular way of creating a policy-map and applying it to the interface.

As FRTS is still something quite vague to myself I would appreciate any tips, comments and feedback on this post.