Cooking with Cisco, Part 1

Author's note: Cisco includes many subtle but useful features in its IOS that you can use to improve your network's efficiency and reliability. This recipe from Cisco Cookbook shows how to use a feature called "Frame-Relay Traffic Shaping" to ensure that the router doesn't overrun the capacity of the individual PVCs in a Frame Relay WAN. This is different from the more common Generic Traffic Shaping, which controls the packet rate for the entire interface. The recipe also shows how to use adaptive Frame-Relay
Traffic Shaping, allowing the router to adjust how fast it sends packets to avoid intermittent network congestion problems.

Recipe 11.11: 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 using
point-to-point frame relay subinterfaces:

Most Frame Relay carrier networks are sufficiently overprovisioned, meaning
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:

Discussion

These examples are different from the one that we showed in Recipe 11.10. 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 150Kbps through the PVC with DLCI 31. It is important to remember that you can have different
CIR values for different PVCs. 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 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, a frame encountered congestion on its way from this router to the remote
device. Please refer to Chapter 10 of Cisco Cookbook 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,000bps, 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. We also recommend monitoring your FECN and BECN
statistics for a reasonable period of time before implementing them, to verify
that they are reliable.