You want to separately control the amount of traffic sent along each of the PVCs in a Frame Relay network.
This first example shows how to configure Frame Relay traffic shaping 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)#end Router#
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:
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)#end Router#
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 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.
Recipe 11.10; Recipe 11.12; Chapter 10
|
|
|
| Top |