Using Frame-Relay Traffic Shaping

Problem

You want to separately control the amount of traffic sent along each of the PVCs in a Frame Relay network.

Solution

This first example shows how to configure frame relay traffic shaping by using point-to-point frame relay subinterfaces:

Router#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)#interface HSSI0/0
Router(config-if)#encapsulation frame-relay
Router(config-if)#exit
Router(config)#interface HSSI0/0.1 point-to-point
Router(config-subif)#traffic-shape rate 150000
Router(config-subif)#frame-relay interface-dlci 31
Router(config-subif)#exit
Router(config)#end
Router#

Most Frame Relay carrier networks are sufficiently over-provisioned that you can actually use much more capacity than your contractual Committed Information Rate (CIR). So you might want to apply traffic shaping only when you encounter Frame-Relay congestion problems, and then only to reduce the data rate until the congestion goes away:

Router#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)#interface HSSI0/0
Router(config-if)#encapsulation frame-relay
Router(config-if)#exit
Router(config)#interface HSSI0/0.1 point-to-point
Router(config-subif)#traffic-shape adaptive 10000
Router(config-subif)#frame-relay interface-dlci 31
Router(config-subif)#exit
Router(config)#end
Router#

 

Discussion

Thes examples are different from the one that we showed in Recipe 11.13. In this recipe, we don't want to control the entire aggregate traffic flow, and we don't care about the traffic based on application. Here we want to ensure that every Frame Relay PVC using this interface is shaped separately so that they don't overrun the amount of bandwidth purchased from the WAN carrier. If you have 20 PVCs on an interface, it is fine to send the maximum per-PVC bandwidth to all of them simultaneously, but you will suffer from terrible performance problems if you try to send all of that bandwidth through a single PVC.

Usually you will purchase a particular amount of Frame Relay bandwidth, or CIR, from the WAN carrier for each PVC. So the first example shows how you can force the router to only send 150 Kbps through the PVC with DLCI 31. It is important to remember that you can have different CIR values for some PVC's than others. So you may need to have a different Frame-Relay traffic-shaping rate on every PVC.

The second example assumes that a lot of the time there will actually be very little congestion in the carrier's network, so you should be able to safely use some of the excess capacity. The Frame Relay protocol includes the ability to tell devices when there is congestion in the network. There are two types of congestion notifications, which are just noted as flags in the header portion of regular user frames. If a router receives a frame with the Forward Explicit Congestion Notification (FECN) flag set, it knows that the frame encountered congestion on its way from the remote device to the router. If the router receives a frame with the Backward Explicit Congestion Notification (BECN) flag set, this means that a frame encountered congestion on its way from this router to the remote device. Please refer to Chapter 10 for a more detailed discussion of these Frame Relay protocol features.

The traffic-shape adaptive command tells the router that when it sees frames with a BECN flag, it should reduce the sending rate on this PVC. By default, this command will back off the sending rate all the way to zero. So in the example, we have specified a minimum rate of 10,000 bps, which would correspond to the CIR for this PVC:

Router(config-subif)#traffic-shape adaptive 10000

In general, this adaptive traffic shaping method is preferred over the static method because it will give you significantly better network performance when the carrier's network is not congested. However, it is important to remember that the precise implementation of FECN and BECN markings is up to the carrier. Some carriers disable these features altogether, while others use them inconsistently. Since most customers ignore these markings, there is often very little reason to ensure that they are accurate.

You should check with your network vendor before implementing adaptive frame-relay traffic shaping. And, in fact, we recommend monitoring your FECN and BECN statistics for a reasonable period of time before implementing, to verify that they are reliable.

See Also

Recipe 11.13; Recipe 11.15; Chapter 10