348 Chapter 5: Traffic Policing and Shaping

NOTE Some explanations describe CAR as using only a single token bucket. For the purposes of the exam, if you understand how the process works, as described in this section, you will know more than enough to answer the exam questions. Regardless of whether the actual software uses one or two buckets, the process works as generally described in this chapter.

CB Policing Internals

CB policing internals worked just like CAR internals before IOS 12.1(5)T, but with IOS 12.1(5)T, the underlying logic was changed. This section explains how CB policing works as of 12.1(5)T and beyond. As with the CAR discussion, this section first describes CB policing without Be, and then with Be.

Traffic-Policing and Traffic-Shaping Concepts 349

number of packets in Bucket1. (Remember, Be = 0 right now, meaning Bucket2 is not used.) CB policing’s decision is simple, as noted here:

•If the number of bytes in the packet is less than or equal to (<=) the number of tokens in Bucket1, the packet conforms. CB policing removes tokens from Bucket1 equal to the number of bytes in the packet, and performs the action for packets that conform to the contract.

•If the number of bytes in the packet is greater than (>) the number of tokens in Bucket1, the packet exceeds the contract. CB policing does not remove tokens from Bucket1, and performs the action for packets that exceed the contract.

Therefore, the logic with no Be in use is simple. Bucket1 gets replenished with tokens. If the packet conforms, CB policing either forwards, discards, or re-marks the packet, and some tokens are then removed from Bucket1. If the packet exceeds, CB policing either forwards, discards, or re-marks the packet, but no tokens are removed from Bucket1.

CB Policing with Be

CB policing uses a simpler algorithm than CAR when a Be value has been configured. CB policing categorizes packets into three groups: conform, exceed, and violate. By using three categories, a very simple and very useful algorithm can be used.

Just like with CAR, to understand how CB policing works is to understand how the buckets are filled and drained. CB policing continues to replenish Bucket1 when a packet arrives. If Bucket1 is full, the extra, or spilled tokens, replenish Bucket2. If Bucket2 fills, the excess tokens spill onto the ground and are wasted. Figure 5-16 shows the basic process:

Figure 5-16 Refilling Dual Token Buckets with CB Policing

Refill Bytes Upon Arrival of Packet, per Formula:

(New_packet_arrival_time - previous_packet_arrival_time) * Policed_rate / 8

$.25 Token

Spillage Falls

$.25 $.25 into Bucket2

Token Token

$.25 $.25 Bucket1 Token Token

Size:Bc

$.25

Token

$.25 Token

Spillage

$.25 $.25 Wasted

Token Token

$.25 Token

350 Chapter 5: Traffic Policing and Shaping

With Bc and Be configured, CB policing uses dual token buckets, and the algorithm is simple:

1If the number of bytes in the packet is less than or equal to (<=) the number of tokens in Bucket1, the packet conforms. CB policing removes tokens from Bucket1 equal to the number of bytes in the packet, and performs the action for packets that conform to the contract.

2If the packet does not conform, and the number of bytes in the packet is less than or equal to (<=) the number of tokens in Bucket2, the packet exceeds. CB policing removes tokens from Bucket2 equal to the number of bytes in the packet, and performs the action for packets that exceed the contract.

3If the packet neither conforms nor exceeds, it violates the traffic contract. CB policing does not remove tokens from either bucket, and performs the action for packets that violate the contract.

Essentially, packets that fit within Bc conform, those that require the extra bytes allowed by Be exceed, and those that go beyond even Be are considered to violate the traffic contract.

Policing, but Not Discarding

Shapers queue excess packets, and policers discard excess packets. However, policers allow a sort of compromise, where the packets are not discarded, but they are marked so that if congestion occurs later, this particular packet is more likely to be discarded. Consider Figure 5-17, for instance, and the policing function on R1.

Figure 5-17 Marking Down Packets with Policing

Policing, Marking Down

Excess Traffic

Packet1, AF11

R3

Packet2, Marked

Down to AF13 by

R1’s Policer

In the figure, two packets travel over a route marked with dotted lines. Each is marked with DSCP AF11 as they enter R1. R1’s policer decides that Packet1 conforms, but that Packet2 exceeds the policing rate. R1’s policer re-marks Packet2 as AF13. DiffServ suggests that AF13 should be in the same queuing class as AF11, but with a higher drop preference than AF11. If no congestion occurs, both packets get through the network. If some congestion occurs, however, Packet2 has a higher chance of being discarded, because it has a DSCP that implies a higher preference to be dropped than does Packet1.

Traffic-Shaping Tools 351

Policing by marking down the packet provides a compromise option. The ISP can protect the network from being overrun by aggressively discarding marked-down packets at the onset of congestion. Customer satisfaction can be improved by letting the customers take advantage of the capacity when it is available.

The same concept, on a limited basis, can be applied in Frame Relay and ATM networks. Frame Relay headers include the discard eligibility (DE) bit, and ATM headers include the cell loss priority (CLP) bit. Each of these single bits can be used to imply that the frame or cell is a better frame or cell to discard when congestion occurs.

Traffic-Shaping Tools

In Chapter 4, you read about how each different queuing tool has significant differences with how their schedulers work. Conversely, the four shaping tools covered next all basically work the same way. In fact, the four shaping tools share much of the underlying shaping code in IOS. Although some features differ, and the configurations certainly differ, most of the core functions behave the same.

Because the shaping tools behave the same for the most part, to prepare for the QoS exams, pay particular attention when the tools do differ. For instance, Frame Relay traffic shaping (FRTS) allows FRF.12 fragmentation at the same time as shaping, but the other shaping tools do not.

Distributed traffic shaping (DTS) distributes processing to Versatile Interface Processor (VIP) cards in 7500 routers. Generic traffic shaping (GTS) and class-based shaping (CB shaping) both support a wide variety of interfaces on all Cisco router platforms. The similarities and differences are outlined in each shaping section in the chapter; make sure to review the tables comparing the tools as you prepare for the exams.

The following sections cover GTS first, CB shaping, DTS, and then FRTS.

Generic Traffic-Shaping Configuration

GTS performs traffic shaping using the same logic and features discussed in the introductory section of this chapter. It can be enabled on a large variety of interfaces. It can also adapt the rate based on BECN signals, and reflect BECNs on a VC after receiving a FECN. It supports a single queuing tool for the shaping queues: Weighted Fair Queuing (WFQ). It can also classify traffic, performing shaping on a subset of the traffic on an interface by classifying packets based on access-control lists (ACLs).

The only feature of GTS not already covered to some depth, other than configuration, is the concept of shaping a subset of the traffic on an interface or subinterface. GTS can classify traffic with an ACL; traffic permitted by the ACL is shaped based on the parameters specified on the same command. For instance, you could shape all FTP traffic to 32 kbps, and web traffic to 64 kbps.

Other than the material already covered, the only other thing really left to think about with GTS is how to configure it. Tables 5-7 and 5-8 list the configuration and show commands pertinent to GTS.

354 Chapter 5: Traffic Policing and Shaping

Example 5-1 CB Shaping on R3, 64-kbps Shape Rate (Continued)

Output queue: 0/1000/64/0 (size/max total/threshold/drops)

Conversations 0/7/256 (active/max active/max total)

Reserved Conversations 0/0 (allocated/max allocated)

Available Bandwidth 1158 kilobits/sec

R3#show traffic-shape queue serial 0/0.1

Traffic queued in shaping queue on Serial0/0.1

Queueing strategy: weighted fair

Queueing Stats: 64/1000/64/768 (size/max total/threshold/drops)

Conversations 3/4/16 (active/max active/max total)

Reserved Conversations 0/0 (allocated/max allocated)

Available Bandwidth 64 kilobits/sec

!Next one is a web connection

(depth/weight/total drops/no-buffer drops/interleaves) 61/32384/734/0/0 Conversation 14, linktype: ip, length: 1404

source: 192.168.3.100, destination: 192.168.1.100, id: 0xAA21, ttl: 127, TOS: 0 prot: 6, source port 80, destination port 3041

!Next one is VoIP

(depth/weight/total drops/no-buffer drops/interleaves) 1/32384/0/0/0 Conversation 0, linktype: ip, length: 188

source: 192.168.3.254, destination: 192.168.2.251, id: 0x0060, ttl: 254, TOS: 0 prot: 17, source port 19273, destination port 17641

!Next one is Passive FTP, not requiring port 20 on either side (depth/weight/total drops/no-buffer drops/interleaves) 2/32384/35/0/0 Conversation 11, linktype: ip, length: 1404

source: 192.168.3.100, destination: 192.168.1.100, id: 0xAA24, ttl: 127, TOS: 0 prot: 6, source port 4904, destination port 3043

The configuration itself is rather simple. You can configure GTS on the subinterface, or on the main interface in this case, because only one VC runs out of the interface. Because most installations tend to enable GTS on subinterfaces, the traffic-shape rate 64000 command was added to interface s0/0.1 to enable GTS for a shaping rate of 64 kbps. GTS only allows WFQ on the shaping queues, so no other configuration command is needed to enable WFQ. The fairqueue command on the physical interface enables WFQ just for the interface output queues.

Three show commands list information about GTS. First, immediately after the configuration, the show traffic-shape command lists basic configuration information, and the derived values for Bc and Be of 8000 bits each. Bc was derived by IOS using the formula Bc = Tc * CIR, which is just a variation on the Tc = Bc/CIR formula. The Tc value defaults to 125 ms, but interestingly, GTS can use different default Tc values, based on the configuration settings you use.

GTS uses WFQ for the shaping queues; the next command in the example, show traffic-shape queue, supplies the same output that the show queue command does for WFQ on an interface.

356 Chapter 5: Traffic Policing and Shaping

TCP connections), and an FTP get. Example 5-2 shows the configuration and some sample show commands.

Example 5-2 GTS on R3, 64 kbps for Non-Voice Traffic, Tc = 50 ms

interface serial0/0 bandwidth 64 load-interval 30 fair-queue

interface serial0/0.1

traffic-shape group 101 64000 3200

!

access-list 101 deny udp any range 16384 32767 any range 16384 32767 access-list 101 permit ip any any

R3#show traffic-shape queue

Traffic queued in shaping queue on Serial0/0.1

Traffic shape group: 101

Queueing strategy: weighted fair

Queueing Stats: 3/1000/64/0 (size/max total/threshold/drops)

Conversations 1/2/16 (active/max active/max total)

Reserved Conversations 0/0 (allocated/max allocated)

Available Bandwidth 64 kilobits/sec

(depth/weight/total drops/no-buffer drops/interleaves) 3/32384/0/0/0 Conversation 11, linktype: ip, length: 1404

source: 192.168.3.100, destination: 192.168.1.100, id: 0xB077, ttl: 127, TOS: 0 prot: 6, source port 4904, destination port 3043

R3#show access-lists

Extended IP access list 101

deny udp any range 16384 32767 any range 16384 32767 (18638 matches) permit ip any any (1257 matches)

The configuration enables GTS by using the traffic-shape group 101 64000 3200 command. This command refers to ACL 101, which permits all traffic except VoIP traffic, implying that shaping occurs for all traffic except VoIP. The shaped rate of 64 kbps implies that the traffic permitted by the ACL will be shaped to 64 kbps. Also note that, according to the traffic-shape command, the Bc value was set to 3200, which should give a Tc of 3200/64,000, or 50 ms. The

358 Chapter 5: Traffic Policing and Shaping

subset of the traffic on an interface. Finally, the configuration is simple, because like all other QoS features starting with the words “class based,” CB shaping uses the Modular QoS command-line interface (MQC) for configuration.

However, CB shaping provides some significant functional improvements over GTS. First, CB shaping supports several queuing methods for the shaping queues, namely FIFO, WFQ, CBWFQ, and LLQ. With these additional queuing tools, multiservice traffic can be better supported. For instance, LLQ can be applied to the shaping queues, providing a low-latency service for voice and video traffic.

CB shaping can be configured to work just like GTS, but it has an option with which you can tell it to send even more traffic during each interval. To work just like GTS, you would configure CB shaping using the shape average command, with which you configure the shaping rate, and optionally the Bc and Be values, in bits. CB shaping sends Bc bits per Tc, or Bc + Be bits after periods of low activity, just like GTS.

Alternatively, you can tell CB shaping to send Bc + Be bits in every interval. To do so, just use the shape peak command rather than shape average.

The biggest difference between GTS and CB shaping lies in the MQC configuration. Tables 5-10 and 5-11 list the configuration and show commands pertinent to CB shaping.

Table 5-10 Command Reference for Class-Based Shaping

Traffic-Shaping Tools 359

Table 5-10 Command Reference for Class-Based Shaping (Continued)

Traffic-Shaping Tools 361

Example 5-3 CB Shaping on R3, 64-kbps Shape Rat (Continued)

Traffic Shaping

Average Rate Traffic Shaping

CIR 64000 (bps) Max. Buffers Limit 1000 (Packets)

R3#show policy-map interface s0/0.1

The CB shaping configuration uses the default class (class-default), and a policy-map (shapeall), which is enabled on serial 0/0.1 using the service-policy output shape-all command. The command class-map class-default matches all packets. The command policy-map shape-all only refers to the class-default class—essentially, classification is configured, but it matches all traffic. Inside class class-default, the shape average 64000 command shapes the traffic to

64 kbps.

Just like with other MQC-based tools, the show policy-map and show policy-map interface serial0/0.1 commands provide all the interesting information about this example. In fact, the highlighted output from these commands in Example 5-3 looks strikingly similar to the output from the show traffic-shape commands used with GTS; remember, much of the underlying code is the same code. Note that show policy-map just lists the same information in the configuration, whereas show policy-map interface lists statistics, tells you whether shaping is currently active, and lists the computed values, such as Bc and Be in this case. Bc = Tc * CIR, or .125 seconds * 64,000 bps, or 8000 bits. Be defaults to the same size as Bc.

In this example, packets are enqueued on the subinterface due to shaping, but few packets are enqueued on the physical interface. With a 128-kbps clock rate, and a shaping rate for all traffic on the interface of 64 kbps, no congestion should occur on the physical interface.

By default, CB shaping uses simple FIFO Queuing for the shaping queue. A common misconception about CB shaping is that because the MQC commands are used, CBWFQ is automatically used—but that is not true! In this example, FIFO Queuing is used for the shaping queue.

Traffic-Shaping Tools 363

Example 5-4 CB Shaping on R3, 64-kbps for Non-Voice Traffic, Tc = 50 ms (Continued)

Serial0/0.1

Service-policy output: shape-non-voip

Class-map: voip-rtp (match-all) 50379 packets, 3224256 bytes

30 second offered rate 25000 bps Match: ip rtp 16384 16383

R3#show queue serial 0/0

Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 6083

Queueing strategy: weighted fair

Output queue: 0/1000/64/0 (size/max total/threshold/drops)

Conversations 0/7/256 (active/max active/max total)

Reserved Conversations 0/0 (allocated/max allocated)

Available Bandwidth 1158 kilobits/sec

The configuration in the example is relatively simple, but detailed. It begins with some familiar MQC commands configuring LLQ. The class-map match-all voip-rtp command creates a new class map, with parameters to match all VoIP payload traffic. The policy-map shape-non-voip command refers to class voip-rtp, with no parameters. With no parameters, no actions are taken for packets in the class, which includes no shaping action. Class class-default refers to the class that matches all traffic, with the shape average 64000 3200 command shaping to 64 kbps, with a Bc of 3200 bits. (CB shaping then calculates Tc as 3200/64000, or 50 ms.) Note that because class voip-rtp occurs first in the policy map, all VOIP traffic matches that class, and is not shaped.

The show policy-map command just restates the information in the configuration. Note the absence of commands under class voip-rtp—remember, no commands were added under the command class voip-rtp—effectively creating a “do nothing” class. The class class-default command matches all other traffic, shaping to 64 kbps. In the show policy-map interface s0/0.1 command, you see that shaping is enabled only for class class-default, but not for class voip-rtp.

This example has repeated the goals of the second GTS example. However, CB shaping can be used with much better effect, given the base requirements, by taking advantage of LLQ, which

364 Chapter 5: Traffic Policing and Shaping

is not available with GTS. In the preceding example, the motivation to shape was based on the Frame Relay provider’s policing of the VC at 96 kbps. If the VoIP call was not active, the data still only gets 64 kbps worth of bandwidth! Although that’s great for the single voice call, it may not be a good choice for the data. The real requirement is for high-quality voice, with good treatment of the data as a secondary goal, knowing that the service provider is policing at

96 kbps.

A better solution is to use CB shaping’s capability to include CBWFQ or LLQ as the queuing tools for the shaping queues. In the first two examples, the shaping queue was a single FIFO queue, because no queuing was configured. In the next example, CB shaping will shape all traffic, including voice, at 96 kbps, but with LLQ used on the shaping queues to ensure good voice quality. To that end, this configuration forces Tc down to 10 ms, which is the recommended value for Tc when delay-sensitive voice and video traffic is shaped. The revised requirements are as follows:

•Ensure high-quality VoIP for one G.729 call, through low loss, low delay, and low jitter.

•Achieve VoIP loss goal by not exceeding the policing rate of the service provider.

•Achieve VoIP delay and jitter goal by using LLQ.

•Choose values so Tc is 10 ms.

•Shape all traffic, including voice, because LLQ will always take the voice traffic next anyway.

Example 5-5 shows the configuration.

Example 5-5 CB Shaping on R3, 96-kbps Shape Rate, with LLQ for Shaping Queues

ip cef

!

class-map match-all voip-rtp match ip rtp 16384 16383

!

!

!The following Policy map is used for queuing (LLQ)

policy-map queue-voip class voip-rtp

priority 32

class class-default fair-queue

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!The following Policy map is used for Shaping;

!It refers to policy-map queue-voip

!

policy-map shape-all class class-default

shape average 96000 960 service-policy queue-voip

!

Traffic-Shaping Tools 367

the ensuing packets are not exceeding the traffic contract. Therefore, the shaper must be involved at this step to decide whether to try to queue the packet into the shaping queue.

If the packet exceeds the contract, the shaper needs to queue the packet. In this case, instead of a single queue, you have a queuing system for the shaping queues as defined by policy map queue-voip. This policy map defines two queues, with one being a 32-kbps low-latency queue into which all payload is placed. This queue was created with the class voip-rtp command inside policy map queue-voip. Because queue-voip defines queuing, and no other details have been configured, all the rest of the packets go into a second queue, associated with the classdefault class. (WFQ is applied to the packets inside the class-default queue, by default, but it can be disabled.)

The next step in the process really shows how integrated the queuing and shaping functions are in with this configuration. After packets have been enqueued in one of the shaping queues, CB shaping must decide when to take a packet from a queue. However, the shaper does not decide which packet to take—the queuing logic as defined in policy map queue-voip determines which packet to dequeue next. Therefore, the shape average 96000 960 command tells CB shaping the rate and Bc values to use when deciding when it can next dequeue packets from the shaping queues. When CB shaping releases the next packet from the shaping queues, the packet is placed into the interface output queue, and it finally exits the serial interface.

The interaction between CB shaping, and the queuing tool used for the shaping queues (LLQ in this case) can be a bit confusing. In particular, the shaper must make the decision about whether to put a packet into the shaping queue, and then the shaper decides when the next packet can be taken from a shaping queue, and then the queuing scheduler decides which packet to service next from the shaping queues.

Now taking a closer look at the configuration. The policy-map shape-all command creates the shaping configuration, with the shape average 96000 960 command enabling shaping and defining a Bc so that Tc = 960/96,000, or 10 ms. Although a Bc of 960 bits may seem smaller than a typical packet, you would typically also use a fragmentation tool on this interface when VoIP is in the network. Fragmentation would happen to cause the largest frame size to be shorter than 960 bits. In addition, the service-policy queue-voip command enables LLQ inside the class-default class inside policy map shape-all—thereby enabling LLQ for the shaping queues.

A closer look at policy map queue-voip reveals two classes. The class voip-rtp command matches all VoIP payload, and is assigned 32 kbps with the priority 32 command, making it the low-latency queue. Remember, LLQ actually polices the traffic in the low-latency queue at this rate, so this queue can send only 32 kbps. Because all traffic is shaped at 96 kbps, 64 kbps remains, which is guaranteed for queuing; the class class-default command matches all other traffic, guaranteeing the remaining 64 kbps to the class.

Finally, the service-policy output shape-all subcommand on interface s 0/0.1 enables the policy on the subinterface, which enables CB shaping. Therefore, the CB shaping logic, and related LLQ logic, is applied to all packets exiting subinterface serial 0/0.1.

368 Chapter 5: Traffic Policing and Shaping

Table 5-12 summaries the key points for comparison between GTS and CB shaping.

Table 5-12 Comparison of Traffic Shaping Tools: GTS and CB Shaping

370 Chapter 5: Traffic Policing and Shaping

Table 5-13 Comparison of Traffic Shaping Tools: GTS, CB Shaping, and DTS (Continued)

Frame Relay Traffic Shaping (FRTS) Configuration

Frame Relay traffic shaping (FRTS) differs from the other three shaping tools in several significant ways. The most obvious difference is the most important—FRTS applies to Frame Relay only. But the basic shaping function is the same, with the same parameters—a shaped rate, which is often set to CIR; a Tc interval, which defaults to 125 ms; and the Bc value is either set, or calculated based on the Tc = Bc/CIR formula.

The first big difference between FRTS and the other shapers has to do with queuing tool support. FRTS does not allow any IOS queuing tool to be used on the physical interface when FRTS is configured for VCs on the interface. Even if a queuing tool has already been configured, IOS removes the configuration from the physical interface when FRTS is enabled. FRTS does supply the largest list of options for queuing tools for the shaping queue: FIFO, PQ, CQ, CBWFQ, LLQ, and WFQ are all available.

NOTE For you exam takers, be aware that at the time this book went to press the Cisco QoS course book incorrectly claims that FRTS supports WFQ on the physical interface; the DQOS course book does not say anything about queuing on the physical interface with FRTS.

Traffic-Shaping Tools 371

The next important difference is that FRTS supports concurrent Frame Relay fragmentation (FRF) using Frame Relay Forum Implementation Agreement 12, also known as FRF.12. With FRF.12, large packets are fragmented, with “large” being defined with configuration commands. Small packets are interleaved, so that a small packet does not have to wait on the long serialization delay associated with the longer original packets. Interestingly, to perform the interleaving feature, FRF uses two queues on the physical interface, with one of the queues holding small, unfragmented packets, and the other holding the fragments of large packets. The queue holding the unfragmented packets is treated like a low-latency queue, always being serviced first. Therefore, although FRTS does not allow any queuing tools on the physical interface, FRF.12 supplies the added benefit of at least a two-queue system, called dual-FIFO, to the physical interface.

FRTS, unlike the other shaping tools, cannot shape a subset of the traffic on an interface. Each of the other three shapers can be configured on one subinterface, and not the other, essentially enabling shaping on only some of the traffic leaving an interface. The other three shapers can also configure classification parameters, and shape only part of the traffic on a subinterface.

Unlike the other shapers, when FRTS is enabled on the physical interface, all traffic on the interface is shaped in some way. In fact, with FRTS enabled, each VC is shaped separately. However, you cannot enable FRTS for only a subset of the VCs on an interface, nor for a subset of the traffic exiting a single VC.

FRTS shapes all VCs on an interface after it has been enabled on that interface. To enable FRTS, add the frame-relay traffic-shape command under the physical interface. If you add no other configuration commands, FRTS uses default settings and shapes each individual VC. If you include additional configuration per VC, FRTS uses those parameters rather than the defaults. In any case, FRTS always shapes each VC separately after it has been enabled on the physical interface.

Unlike the other three shapers, FRTS can dynamically learn the CIR, Bc, and Be values configured per VC at the Frame Relay switch and use those settings for shaping. Cisco’s WAN switching products (from the Stratacom acquisition in the mid-1990s) use an Enhanced LMI (ELMI) feature, which IOS understands. Using ELMI, the switch just announces the CIR, Bc, and Be for each VC to the router. So, if you want to use FRTS only to shape to CIR, and the Frame Relay network uses Cisco switches, you can just enable FRTS and ELMI on the interface, and the rest (Bc, CIR, and so on) will be learned dynamically for each VC.

Finally, the biggest difference relates to FRTS configuration. The commands used differ totally from the other three tools. Tables 5-14 and 5-15 list the configuration and show commands pertinent to FRTS, respectively.

372 Chapter 5: Traffic Policing and Shaping

Table 5-14 Command Reference for Frame Relay Traffic Shaping

374 Chapter 5: Traffic Policing and Shaping

Example 5-6 FRTS Configuration, 64 kbps, with Mostly Defaults

!

! Portions of Configuration omitted for Brevity

!

interface Serial0/0

description connected to FRS port S0. Single PVC to R1. no ip address

encapsulation frame-relay no fair-queue

clockrate 128000 frame-relay traffic-shaping

!

interface Serial0/0.1 point-to-point

description point-point subint global DLCI 103, connected via PVC to DLCI 101 ( R1)

ip address 192.168.2.253 255.255.255.0 frame-relay class shape-all-64 frame-relay interface-dlci 101

!

map-class frame-relay shape-all-64 frame-relay traffic-rate 64000 64000

R3#show frame-relay pvc

PVC Statistics for interface Serial0/0 (Frame Relay DTE)

DLCI = 101, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/0.1

pvc create time 01:45:46, last time pvc status changed 01:30:01

R3#show frame-relay pvc 101

PVC Statistics for interface Serial0/0 (Frame Relay DTE)

DLCI = 101, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/0.1

378 Chapter 5: Traffic Policing and Shaping

Example 5-7 FRTS Configuration by Setting CIR, Bc to Manipulate Tc (Continued)

R3(config)#interface serial 0/0.1

R3(config-subif)#frame class shape-all-64-long

R3(config-subif)#^Z

R3#show traffic-shape

R3#configure terminal

Enter configuration commands, one per line. End with CNTL/Z.

!

R3(config)#map-class frame-relay shape-all-64-shortTC

R3(config-map-class)#frame-relay cir 64000 R3(config-map-class)#frame-relay bc 640 R3(config-map-class)#int s 0/0.1

R3(config-subif)#frame-relay class shape-all-64-shortTC

R3(config-subif)#^Z

R3#show traffic-shape

Example 5-7 lists two configurations, with show command output listed after each configuration. In each case, the configuration commands enable you to explicitly set CIR, Bc, and Be, with Tc being calculated with the familiar Tc = Bc/CIR. In map-class frame-relay shape-all- 64-long, CIR and Bc are set to the same values as in the first FRTS configuration shown in Example 5-6. After the configuration section at the beginning of Example 5-7, this map class is enabled on interface S0/0.1; the show traffic-shape command now accurately lists the Bc value of 8000, and the shaping rate (as set by the frame-relay cir command) of 64,000 bps.

The second configuration in Example 5-7 uses the map-class frame-relay shape-all-64- shortTC command to set Bc to 1/100 of the CIR value, which yields a Tc = 640/64,000, or 10 ms. This map class shows how you would set values to lower Tc, which is particularly useful to reduce the delay waiting for the next Tc if you have multiservice traffic. The example shows the configuration being changed to use map-class shape-all-64-shortTC by adding the framerelay class shape-all-64-shortTC command. The show traffic-shape command follows, listing a Tc value of 10 ms.