Frame Relay Traffic Shaping

In one form, traffic shaping is just a fancy term for adjusting the speed on the link. If you have a T1 talking to a 56Kbps link, sometimes the T1 is able to send at full speed. If it does, it overwhelms the 56Kbps device. When it happens, the Frame Relay switches notify the T1 device to stop sending so many packets. Traffic shaping can involve more than just adjusting the apparent link speed, such as the prioritization of the frames on a DLCI-by-DLCI basis. Finally, traffic shaping can also involve tweaking transmission times to allow for time-sensitive frames such as Voice over Frame Relay.

BECNs and FECNs

BECN and FECN packets are how Frame Relay devices tell other Frame Relay devices, "Hey! You're sending me too many packets. Slow down." Frame Relay switches in the service provider cloud normally generate them, which is why they go both directions.

When a Frame Relay device becomes congested and BECNs and FECNs get generated, this situation creates problems for you. If the router does not throttle back how many packets it is sending out per second, packets over the CIR value are dropped.

Suppose a router is connected to a Frame Relay cloud with a T1 connection with a CIR of 256Kbps. If devices within the cloud become congested, they tell the router to slow down. The router slows down its data throughput to 256Kbps. If it does not slow down, then devices within the cloud begin dropping packets over the 256Kbps mark.

A second example leads to major problems. Suppose you have two devices, router A connected to the Frame Relay cloud via a T1 with a 256Kbps CIR, and router B connected to the cloud via a 56Kbps line with a 32Kbps CIR. Router A starts sending data and overwhelms the 56Kbps router. Router A receives BECNs and slows down to 256Kbps. It continues to overwhelm Router B. Packets constantly get dropped and have to be resent.

Traffic can be prioritized inside the router based on the DLCI that is being used. If a company has a physical cable that has two Frame Relay circuits attached, one to its ISP and the other to a remote office, which circuit carries the most important traffic? Is Web browsing traffic more important than the database replies going to the remote office? Only you know for sure, but rather than treat traffic in a weighted fair queuing (WFQ) fashion, you can tell the router that one DLCI is more important than another. If the interface gets congested, the router forwards the traffic for the important DLCI before forwarding traffic for the less important DLCI.

Configuring Traffic Shaping

To determine what traffic is more important that other types, you can use queuing to prioritize certain types of traffic. When the router starts to throttle back the amount of data it sends, the more important types of traffic have a better chance of not being delayed.

Figure 9.5 shows a sample circuit with data flowing down it. At various times, the amount of data is either below the CIR or above it.

Figure 9.5. Circuit usage.

graphics/09fig05.gif

It's important to remember the following equation: excessive burst + committed burst = maximum circuit speed. The amount of data above the CIR is called excessive burst (Be), and the maximum amount of data in a given time period offered to the network for which the provider has guaranteed delivery is the committed burst (Bc). If a circuit has a maximum burst of 1.5Mbps and a CIR of 128Kbps, then the first 128Kbps of data can be marked as nondiscard eligible, and everything else over 128Kbps gets the discard eligible (DE) bit set. 128Kbps would be the Bc, and 1.5Mbps would be the Be. If congestion is later encountered, the frame with the DE bit set is more likely to be discarded than a frame without it. Bc, DE, and CIR are the three primary values that you need to configure with traffic shaping.

You measure CIR in bits per second, and you average it over a period of time, referred to as the committed time interval or Tc. Bc and Be are displayed in bits and compared against a time shown in Tc. A lot of confusion results because Bc is usually the same as the CIR, but over the operation of the circuit, the values might not be the same. If an interface is configured to respond to congestion frames, the primary CIR can be lowered, which results in bursting to the point of the old CIR, with DE bits being set. You can set a mincir value to limit how far responding to BECNs reduces the CIR.

Traffic Shaping Commands

The first thing that you need to define when determining traffic shaping is a map class. A map class is the go-between for the interface and the queuing configuration. You need to type the following command:

 Router(config)#map-class frame-relay map-class-name 

It puts the router into map class configuration mode.

Next, you specify the average rate the interface or subinterface should send at, as well as the maximum:

 Router(config-map-class)#frame-relay traffic-rate average maximum 

Although the maximum value is optional, the average field normally matches the CIR of the circuit, and the maximum value is equal to the Be. If you want the router to respond to BECNs and modify the amount of data it sends based on that information, use the following command:

 Router(config-map-class)#frame-relay adaptive-shaping becn 

Once you decide what type of queuing to use (see Chapter 12, "Traffic Management," for more information), you need to link the queue configuration to the map class. Use the following command:

 Router(config-map-class)#frame-relay {custom-queue-list | priority-group } list-number 

Once you build the queuing policy, you need to enable traffic shaping on the appropriate interface:

 Router(config-if)frame-relay traffic-shaping 

To link the map class to all the virtual circuits on a physical interface, use the following command:

 Router(config-if)frame-relay class map-class-name 

It forces all subinterfaces on the physical interface to use the same map class configuration.

A sample configuration, assuming Frame Relay is already configured, and minus the queuing configuration, appears in Table 9.4.

Table 9.4. Traffic-Shaping Example

Traffic-Shaping Commands

Explanations

Router(config)#map-class frame-relay map-class-name

This line puts the router into map class configuration mode, allowing you to configure the map class.

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

This command tells the router that the average traffic rate is 128,000 bits per second with a maximum value of 384,000.

Router(config-map-class)#frame-relay custom-queue-list queue-list-number

This command tells the router to use a certain queue configuration in determining what traffic is more important than other types of traffic.

Router(config-map-class)#frame-relay priority-group <list_number>

This line links an access list to a map class configuration. The list number must match the access list number used to define the important traffic.

Router(config-map-class)#frame-relay [ cir | be | bc ] <direction> <bytes>

This command establishes the different rates for the circuit. Optionally, you can also use the direction.

Router(config-if)#frame-relay traffic-shaping

This line tells the router to be prepared to throttle back sending data if necessary.

Router(config-if)#frame-relay class map-class-name

This command tells the router for a specific interface to use the traffic-shaping configuration found within the map-class-name configuration.

The following sample configuration shows how you can configure a map class for an interface that has 1.5Mbps coming in with a 56Kbps CIR outgoing:

 map-class frame-relay phoenix  frame-relay cir in 1500000  frame-relay cir out 56000 

graphics/note_icon.gif

If traffic shaping is configured on a physical interface but the CIR on a subinterface is not set via a map class, the CIR is automatically set to 56000.


Frame Relay Fragmentation

Fragmentation is the process of breaking a packet or frame into two or more pieces. It creates smaller pieces for the purpose of allowing the traffic across a link that doesn't allow large frames or to allow more important packets to be interleaved in the stream.

When a full-sized Ethernet frame hits a router and wants to continue across an ATM interface, there's a problem. The Ethernet frame is a bit more than 1500 bytes long, and ATM can handle 48 bytes of payload per cell. The solution is for the router to break part of the Ethernet frame into pieces small enough to be transported by the ATM cells.

Frame Relay doesn't have the same size limits that ATM does (although the same thing would need to happen with Token Ring traffic), but Frame Relay gives the ability to manually fragment frames. A fragment size is configured on the Frame Relay interface, and frames are broken down to that size on exiting the interface.

Suppose that time-sensitive traffic is crossing the circuit along with slow data traffic, and as each data frame hits the router interface, the time-sensitive traffic gets delayed due to the time needed to forward the larger frames. Sports cars can get on and off the freeway fairly quickly, but if a truck hauling three flatbeds of goods is on the entrance ramp as the sportscar gets to it, the car will be delayed. Fragmentation is where the truck's payload is broken up; each flatbed is hauled by a different truck and cars can maneuver in between the trucks. Although there is still some delay, it isn't as significant as it otherwise would have been.

The delay experienced is a factor of both the frame size and the bandwidth of the interface. Table 9.5 shows some frame sizes and bandwidth values. Each number is in milliseconds (ms) except where the value is in microseconds.

Table 9.5. Frame Relay Transmission Delay

Frame Size in Bytes

Link Speed

1

64

128

256

512

1024

1500

56Kbps

143 micro

9

18

36

72

144

214

256Kpbs

31 micro

2

4

8

16

32

46

768Kbps

10 micro

640 micro

1.3

2.6

5.1

10.2

15

As you can see, sending a large data frame out a slow interface can cause significant delay. It might not be too noticible if someone is just surfing the Web, but if a Voice over IP call is trying to access a 56Kbps circuit at the same time that 1500-byte data frames are using it, there will be quality issues. Total one-way delay for a voice call should be in the 150 to 200ms range; that's being used up before the voice traffic even exits the building!

You can use fragmentation to break up those large data frames by setting a maximum size for frame transmission on the appropriate interface. To do so, you need to create a map class:

 Frame(config)# map-class frame-relay fragment Frame(config-map-class)# frame-relay fragment 512 Frame(config-map-class)# interface s0/0.40 Frame(config-subif)# frame-relay interface-dlci 40 Frame(config-fr-dlci)# class fragment 

Each subinterface could receive the same configuration information if you enter the class fragment command while in the correct configuration mode. You can use the command on different DLCIs to apply the configuration multiple times.

graphics/note_icon.gif

Specifying the DLCI is important because a multipoint configuration contains multiple DLCIs on the same subinterface.


Per-Interface Priority Queuing

Because Frame Relay uses logical circuit IDs, it becomes possible to prioritize traffic based on the circuit it wants to access. This process is called per-interface priority queuing (PIPQ).

PIPQ is beneficial when certain types of traffic only use particular PVCs. If all voice traffic from Phoenix to Wichita uses the PVC marked with DLCI 105, and all data traffic from Phoenix to Wichita uses the PVC marked with DLCI 110, prioritization becomes a simple manner of giving all DLCI 105 traffic a higher preference.

You can divide frames based on the prioritization they receive. The following levels are available:

  • High

  • Medium

  • Normal

  • Low

As you can see, these are the same types of queues used by priority queuing. The only difference is that rather than sort by address or protocol, prioritization is based on the outgoing DLCI. Although PIPQ is a nice tool for use on DLCIs that don't carry mixed voice and data, it isn't very effective on DLCIs that do carry mixed voice and data. For those circuits, you want a different type of queuing.

Configuring PIPQ

Configuring PIPQ is a simple extension of the map classes that you have used for fragmentation and traffic shaping. There is a single command with four options:

 Router(config-map-class)#frame-relay interface-queue priority <priority> 

The priority value can be either high, medium, normal or low. As traffic exits the router on two different DLCIs, the router looks to see which should be sent out first. It sees that traffic on DLCI 34 has a higher priority than traffic on DLCI 56, sending the DLCI 34 traffic first.

It's important to remember that PIPQ only makes decisions based on the DLCI the traffic wants access to. Other types of queuing detertmine traffic importance based on the type of traffic, as you'll see in Chapter 12. PIPQ's strength is quick decision-making as opposed to protocol and application flexibility.

EIGRP over Frame Relay

Enhanced Interior Gateway Routing Protocol (EIGRP) is a routing protocol developed by Cisco. They call it a hybrid because it is a distance-vector protocol that has some properties of a link-state protocol. EIGRP is proprietary to Cisco equipment. An in-depth discussion of EIGRP appears in CCNP BSCI Exam Cram 2, but a feature of EIGRP interests us here.

A poorly designed network, and occasionally a well designed network, can suffer from routing protocol updates taking up most or all of a slow WAN link, leaving little room for data. If you are using EIGRP, you can tell it not to use more than a certain percentage of the total bandwidth for routing protocol traffic. This ability makes it very important to set the interface bandwidth to a correct value:

 Router(config-if)#ip bandwidth-percentage eigrp autonomous-system-number   bandwidth-percentage 

The autonomous-system-number is the one that EIGRP is using on that interface, and the bandwidth-percentage is the percentage of bandwidth you want to allow EIGRP to consume in a worst-case scenario. This command is also available for Internetwork Packet Exchange (IPX) and AppleTalk.



CCNP BCRAN Remote Access Exam Cram 2 (Exam Cram 640 - XXX)
CCNP BCRAN Remote Access Exam Cram 2 (Exam Cram 640 - XXX)
ISBN: N/A
EAN: N/A
Year: 2003
Pages: 183

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net