MQC Frame-Relay Traffic Shaping example – Network Professional Member Site

Traffic shaping on frame-relay networks can be configured using the MQC just like for any other interface, but there are a couple of different methods. You can attach a policy-map with a shaper to the serial interface or to a frame-relay map-class. In this lesson, I want to show you how to configure both and the difference between the two. We will start with the map-class!

Don’t confuse a frame-relay map-class with a class-map. Those are two different things…

MQC Traffic Shaping using Map-Class

R1(config)#policy-map SHAPER
R1(config-pmap)#class class-default
R1(config-pmap-c)#shape average 256000
R1(config-pmap-c)#shape adaptive 128000

I can only use the class-default for the shaper. If you want you can configure the average shape rate and the adaptive shape rate. CBWFQ is the only queuing strategy that is supported in combination with the shaper. If you want this, you can configure it as follows:

R1(config)#class-map VOIP
R1(config-cmap)#match protocol rtp

R1(config)#policy-map CBWFQ
R1(config-pmap)#class VOIP
R1(config-pmap-c)#priority 128
R1(config-pmap-c)#exit
R1(config-pmap)#class class-default
R1(config-pmap-c)#fair-queue

Above, I created a policy-map called CBWFQ that creates a priority queue of 128 Kbps for RTP traffic. All other traffic will be served using WFQ. We still need to combine the two policy-maps and activate them:

R1(config)#policy-map SHAPER
R1(config-pmap)#class class-default
R1(config-pmap-c)#service-policy CBWFQ

We’ll add the CBWFQ configuration under the SHAPER. Now we need to attach the shaper to a map-class:

R1(config)#map-class frame-relay DLCI102
R1(config-map-class)#service-policy output SHAPER

The shaper is attached to a frame-relay map-class called “DLCI102”, now we can attach the map-class to a DLCI:

R1(config)#interface serial 0/0
R1(config-if)#frame-relay interface-dlci 102
R1(config-fr-dlci)#class DLCI102

The frame-relay map-class is attached to the DLCI directly. Something to remember is that the available bandwidth for CBWFQ is based on shape adaptive, not shape average. If you want to use frame-relay fragmentation you’ll have to do it on the interface level like this:

R1(config)#interface serial 0/0
R1(config-if)#frame-relay fragment 100 end-to-end

The command above will set the fragment size to 100 bytes. This will also enable interleaving, but you won’t see it in any show commands. This will enable fragmentation for all PVCs. Let’s verify our work:

R1#show policy-map interface serial 0/0
 Serial0/0: DLCI 102 -

  Service-policy output: SHAPER

    Class-map: class-default (match-any)
      0 packets, 0 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: any 
      Traffic Shaping
         Target/Average   Byte   Sustain   Excess    Interval  Increment
           Rate           Limit  bits/int  bits/int  (ms)      (bytes)  
         256000/256000    1984   7936      7936      31        992      

        Adapt  Queue     Packets   Bytes     Packets   Bytes     Shaping
        Active Depth                         Delayed   Delayed   Active
        BECN   0         0         0         0         0         no

      Service-policy : CBWFQ

        Class-map: VOIP (match-all)
          0 packets, 0 bytes
          5 minute offered rate 0 bps, drop rate 0 bps
          Match: protocol rtp
          Queueing
            Strict Priority
            Output Queue: Conversation 24 
            Bandwidth 128 (kbps) Burst 3200 (Bytes)
            (pkts matched/bytes matched) 0/0
            (total drops/bytes drops) 0/0

        Class-map: class-default (match-any)
          0 packets, 0 bytes
          5 minute offered rate 0 bps, drop rate 0 bps
          Match: any 
          Queueing
            Flow Based Fair Queueing
            Maximum Number of Hashed Queues 16 
        (total queued/total drops/no-buffer drops) 0/0/0

You can use the show policy-map interface command to see the shaper configuration that we applied using the frame-relay map-class. Let’s continue and see how we can attach frame-relay traffic shaping using the interface.

MQC Traffic Shaping using Interface

If you want to attach the policy-map to the interface, you have two options:

Attach it to the physical interface.
Attach it to the sub-interface.

Physical Interface:

R1(config)#class-map DLCI102
R1(config-cmap)#match fr-dlci 102

R1(config)#policy-map SHAPER
R1(config-pmap)#class DLCI102
R1(config-pmap-c)#shape average 128000

R1(config)#interface serial 0/0
R1(config-if)#service-policy output SHAPER

Above, I’m using a class-map to match on the DLCI and then use a policy-map to shape this PVC, finally, we’ll attach it to the physical interface. Let’s verify it:

R1#show policy-map interface serial 0/0

 Serial0/0 

  Service-policy output: SHAPER

    Class-map: DLCI102 (match-all)
      0 packets, 0 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: fr-dlci 102
      Traffic Shaping
         Target/Average   Byte   Sustain   Excess    Interval  Increment
           Rate           Limit  bits/int  bits/int  (ms)      (bytes)  
         128000/128000    1984   7936      7936      62        992      

        Adapt  Queue     Packets   Bytes     Packets   Bytes     Shaping
        Active Depth                         Delayed   Delayed   Active
        -      0         0         0         0         0         no

    Class-map: class-default (match-any)
      0 packets, 0 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: any

Above, you see that the shaper is attached to the physical interface. Let’s see how to attach it to the sub-interface…

Sub-Interface:

R1(config)#policy-map SHAPER
R1(config-pmap)#class class-default
R1(config-pmap-c)#shape average 64000

R1(config)#interface serial 0/0.102      
R1(config-subif)#service-policy output SHAPER

When I attach it to the sub-interface, I don’t have to match on the DLCI unless you have multiple DLCIs on a single sub-interface. Let’s verify our work:

R1#show policy-map interface serial 0/0.102

 Serial0/0.102 

  Service-policy output: SHAPER

    Class-map: class-default (match-any)
      0 packets, 0 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: any 
      Traffic Shaping
         Target/Average   Byte   Sustain   Excess    Interval  Increment
           Rate           Limit  bits/int  bits/int  (ms)      (bytes)  
          64000/64000     2000   8000      8000      125       1000     

        Adapt  Queue     Packets   Bytes     Packets   Bytes     Shaping
        Active Depth                         Delayed   Delayed   Active
        -      0         0         0         0         0         no

Applying the policy-map to the (sub)interface enables a “normal” shaper like any other interface. The downside of doing it this way is that you don’t have any specific frame-relay traffic shaping features like adaptive shaping or voice-adaptive fragmentation shaping so it’s probably best to stick to the “map-class” type configuration.

Hopefully, this lesson has helped you to understand the difference between the different MQC methods to configure frame-relay traffic shaping. If you have any questions feel free to leave a comment!