Class Based Shaping Configuration

The underlying processes of class-based (CB) shaping are the same as GTS. Just like GTS, CB shaping 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 an FECN. It can also perform shaping on a 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

Command

Mode and Function

shape [average | peak] mean-rate [[burst-size] [excess-burst-size]]

Policy-map class configuration mode; enables shaping for the class, setting the shaping rate, and optionally Bc and Be. The average option causes shaping as normal; the peak option causes Bc + Be to be sent per Tc.

Shape adaptive min-rate

Policy-map class configuration mode; enables the minimum rate for adaptive shaping. The maximum rate is configured with the shape average or shape peak command.

Shape fecn-adapt

Policy-map class configuration mode; enables reflection of BECN signals upon receipt of an FECN.

service-policy {input | output} policy-map-name

Interface or subinterface configuration mode; enables CB shaping on the interface.

class-map class-map-name

Global config; names a class map, where classification options are configured.

Match . . .

class-map subcommand; defines specific classification parameters.

match access-group {access-group | name access-group-name}

class-map subcommand; references either numbered or named ACL.

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

Command

Mode and Function

match source-address mac address

class-map subcommand; references the source MAC address that forwarded the packet to this router, typically the previous-hop router.

match ip precedence ip-precedence-value [ip-precedence-value ip-precedence-value ip-precedence-value]

class-map subcommand; references one or more IP precedence values. A packet with any of the listed values matches.

match mpls experimental number

class-map subcommand; references MPLS Experimental bits.

match cos cos-value [cos-value cos-value cos-value]

class-map subcommand; references one or more class of service (CoS) values. A packet with any of the listed values matches.

match destination-address mac address

class-map subcommand; references the destination MAC address of the device to which the packet will be forwarded next.

match input-interface interface-name

class-map subcommand; matches based on the interface in which the packet was received.

match ip dscp ip-dscp-value [ip-dscp-value ip-dscp-value ip-dscp-value ip-dscp-value ip-dscp-value ip-dscp-value ip-dscp-value]

class-map subcommand; references one or more IP DSCP values. A packet with any of the listed values matches.

match ip rtp starting-port-number portrange

class-map subcommand; references a range of UDP ports, only matching the even numbered ports, which carry voice payload.

match qos-group qos-group-value

class-map subcommand; matches based on QoS group.

match protocol protocol-name

class-map subcommand; matches based on NBAR-defined protocol types.

match protocol citrix [app application-name-string].

class-map subcommand; matches based on NBAR-defined Citrix application types.

match protocol http [url url-string | host hostname-string | mime MIME-type]

class-map subcommand; matches based on NBAR-discovered details inside the host name or URL string.

match any

class-map subcommand; matches all packets.

policy-map policy-map-name

Global config; names a policy, which is a set of actions to perform.

class name

policy-map subcommand; identifies which packets on which to perform some action by referring to the classification logic in a class map.

Table 5-11 Exec Command Reference for Class-Based Shaping

Command

Function

show policy-map policy-map-name

Lists configuration information about all MQC-based QoS tools

show policy-map interface-spec [input | output] [class class-name]

Lists statistical information about the behavior of all MQC-based QoS tools

For the sake of comparison, the following two examples use requirements very similar to the two examples for GTS. The first configuration shows R3, with a 128-kbps access rate, and a 64-kbps Frame Relay VC connecting to R1. The criteria for the configuration is as follows:

• Shape all traffic at a 64-kbps rate.

• Use the default setting for Tc.

• Enable the configuration on the subinterface.

• Use WFQ on the physical interface.

• Use the default queuing method for the shaping queues.

In each example, the client downloads one web page, which has two frames inside the page. The web page uses two separate TCP connections to download two separate large JPG files. The client also downloads a file using FTP get. In addition, a VoIP call is placed between extension 302 and 102. Example 5-3 shows the configuration and some sample show commands.

Example 5-3 CB Shaping on R3, 64-kbps Shape Rat policy-map shape-all class class-default shape average 64000

interface serial0/0 bandwidth 64 load-interval 30 fair-queue interface serial0/0.1 service-policy output shape-all

R3#show queue serial 0/0

Input queue: 0/75/1/0 (size/max/drops/flushes); Total output drops: 5965 Queueing strategy: weighted fair

Output queue: 0/1000/64/90 (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 policy-map

Policy Map shape-all Class class-default

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

Serial0/0.1

Service-policy output: shape-all

Class-map: class-default (match-any) 7718 packets, 837830 bytes

30 second offered rate 69000 bps, drop rate 5000 bps Match: any

Class-map: class-default (match-any) 7718 packets, 837830 bytes

30 second offered rate 69000 bps, drop rate 5000 bps Match: any

Traffic Shaping

Target/Average Rate 64000/64000

125

Increment (bytes) 1000

Adapt Queue Active Depth - 56

Packets 6393

Bytes 692696

Delayed

Active yes

The CB shaping configuration uses the default class (class-default), and a policy-map (shape-all), 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.

A second CB shaping configuration example is shown next; the criteria and motivation are the same as the second GTS example. For the second configuration, imagine that the Frame Relay provider actually polices the VC from R3 to R1 at 96 kbps. You engineer the network to support a single G.729 VoIP call, which takes about 28 kbps. You decide that you want to be very careful about packet drops, latency, and jitter for this voice traffic, so you decide to shape all traffic except voice. To avoid drops inside the cloud, you shape the rest of the traffic to a rate of 64 kbps (so that the combined single VoIP call, and the Shaped rate of 64 kbps, do not exceed the policing rate in the Frame Relay network). The next example shows the configuration, and the criteria for the configuration is as follows:

• Shape non-VoIP traffic at 64 kbps.

• Enable the configuration on the subinterface.

In this case, a single VoIP call and one web page connection with two frames inside the page are used, plus an FTP get. Example 5-4 shows the configuration and some sample show commands.

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

In this case, a single VoIP call and one web page connection with two frames inside the page are used, plus an FTP get. Example 5-4 shows the configuration and some sample show commands.

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

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

Class-map: class-default (match-any) 5402 packets, 6634217 bytes

30 second offered rate 66000 bps, drop rate 0 bps Match: any Traffic Shaping

Target/Average Byte Sustain Excess Interval Increment

Rate Limit bits/int bits/int (ms) (bytes)

64000/64000

800

3200

3200

50

400

Adapt Queue

Packets

Bytes

Packets

Bytes

Shaping

Active Depth

Delayed

Delayed

Active

- 8

31

40168

30

38764

yes

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

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 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.

• 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

• 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

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

interface serial0/0 bandwidth 64 load-interval 30 fair-queue interface serial0/0.1 service-policy output shape-all

R3#show policy-map

Policy Map shape-all Class class-default Traffic Shaping

Average Rate Traffic Shaping

CIR 96000 (bps) Max. Buffers Limit 1000 (Packets) Bc 960

service-policy queue-voip

Policy Map queue-voip Class voip-rtp

Weighted Fair Queueing Strict Priority

Bandwidth 32 (kbps) Burst 800 (Bytes) Class class-default Weighted Fair Queueing

Flow based Fair Queueing Max Threshold 64 (packets)

R3#show policy-map interface serial 0/0.1

Serial0/0.1

Service-policy output: shape-all

Class-map: class-default (match-any) 5189 packets, 927835 bytes

30 second offered rate 91000 bps, drop rate 0 bps Match: any Traffic Shaping

Target/Average Byte Sustain Excess Interval Increment

Rate Limit bits/int bits/int (ms) (bytes)

96000/96000

1200

960

960 1

0

120

Adapt Queue

Packets

Bytes

Packets

Bytes

Shaping

Active Depth

Delayed

Delayed

Active

- 17

5172

910975

4002

831630

yes

Service-policy :

queue-voip

Class-map: voip-rtp (match-all) 4623 packets, 295872 bytes

30 second offered rate 25000 bps, drop rate 0 bps Match: ip rtp 16384 16383 Weighted Fair Queueing Strict Priority

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

Output Queue: Conversation 24 Bandwidth 32 (kbps) Burst 800 (Bytes) (pkts matched/bytes matched) 3528/225792 (total drops/bytes drops) 0/0

Class-map: class-default (match-any) 566 packets, 631963 bytes

30 second offered rate 65000 bps,

drop rate 0 bps

Match: any

Weighted Fair Queueing

Flow Based Fair Queueing

Maximum Number of Hashed Queues

16

(total queued/total drops/no-buffer

drops) 17/0/0

Example 5-5 contains a lot of interesting command output. It begins with the configuration, which is followed by several show commands. The configuration contains two policy maps; one configures shaping, and the other configures LLQ, which is applied to the packets held because of shaping.

Because the interaction between the two policy maps can be confusing, Figure 5-19 shows the general idea behind what is happening in the configuration.

Figure 5-19 Interaction Between Shaping Policy Map shape-all and Queuing Policy Map queue-voip

Toggles Based on

Rules Shown in Defined by policy-

the Text Defined by policy-map queue-voip map shape-a|1

Toggles Based on

Rules Shown in Defined by policy-

the Text Defined by policy-map queue-voip map shape-a|1

Scanning the figure from left to right, packets are first routed out the subinterface. Then the IOS checks to see whether shaping is active. Shaping becomes active when a single packet exceeds the traffic contract; shaping only becomes inactive when all the shaping queues are drained, and 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 class-default 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.

The show policy-map commands reflect the details in the configuration. The command lists policy-map shape-all as performing traffic shaping, and policy-map queue-voip as performing LLQ. The show policy-map interface s0/0.1 command lists the shaping parameters and statistics, just like it did in the earlier examples. However, halfway through the command output, a new section has appeared, with details about policy-map shape-all's use of the LLQ policy-map queue-voip. The same information seen in CBWFQ and LLQ show policy-map interface commands in Chapter 4 appears in this area, including packet rates and byte rates.

This example allows the G.729 call to work well, because LLQ will always service the voip-rtp class when a packet is waiting. If no VoIP calls are up, however, the rest of the traffic can send at 96 kbps, the maximum sending rate for shaping. In other words, the rest of the traffic is guaranteed 64 kbps, with a maximum limit of the shaping rate. With LLQ, the VoIP always receives good treatment when the call is up, unless the VoIP traffic exceeds the LLQ policed rate of 32 kbps.

CB shaping supports all the features that GTS supports, plus a few others. It can support CBWFQ and LLQ for the shaping queues, and of course MQC commands are used to configure it. However, neither CB shaping nor GTS support FRF.12 fragmentation on Frame Relay subinterfaces, and neither can be enabled per-VC on multipoint Frame Relay subinterfaces.

NOTE Fragmentation is very important on slower-speed links when supporting voice and video as well as data over a link. The lack of support for Frame Relay fragmentation by GTS, CB shaping, and DTS seemingly makes FRTS the only reasonable option for shaping in networks with multiservice traffic. However, GTS, CB shaping, and DTS can support another form of fragmentation over Frame Relay, called "LFI using Multilink Point-to-Point Protocol over Frame Relay." This feature is not covered on either of the QoS exams, but it is a reasonable alternative in real life, which also makes GTS, DTS, and CB shaping reasonable alternatives to FRTS on Frame Relay interfaces.

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

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

Feature

GTS

CB Shaping

Supports ATM, FR, HDLC, PPP, LAN interfaces

Yes

Yes

Can be enabled on interfaces and subinterfaces

Yes

Yes

Can be enabled per FR DLCI to support per-VC shaping on multipoint interfaces

No

No

Supports adaptive shaping

Yes

Yes

Supports concurrent FRF.12 Frame Relay fragmentation

No

No

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

Feature

GTS

CB Shaping

Queuing methods allowed in shaping queue

WFQ

FIFO, WFQ, CBWFQ, LLQ

Concurrent queuing methods on physical interface

All

All

Can be configured using MQC commands

No

Yes

Can classify traffic to shape a subset of the traffic on an interface/VC

Yes

Yes

Default Tc

Variable

125 ms

Distributes shaping processing to VIPs in 7500 series routers

No

No

Advance SEO Techniques

Advance SEO Techniques

Turbocharge Your Traffic And Profits On Auto-Pilot. Would you like to watch visitors flood into your websites by the 1,000s, without expensive advertising or promotions? The fact is, there ARE people with websites doing exactly that right now. How is that possible, you ask? The answer is Advanced SEO Techniques.

Get My Free Ebook


Post a comment