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.

Table 5-7 Command Reference for Generic Traffic Shaping

Command

Mode and Function

traffic-shape rate bit-rate [burst-size [excess-burst-size]]

Interface configuration mode; enables GTS for a shaped rate, with optional Bc and Be settings, in bits

traffic-shape group access-list bit-rate [burst-size [excess-burst-size]]

Interface configuration mode; enables GTS for a shaped rate, only for traffic permitted by the referenced ACL, with optional Bc and Be settings, in bits

traffic-shape adaptive bit-rate

Interface configuration mode; enables adaptive shaping, and sets the minimum shaped rate

traffic-shape fecn-adapt

Interface configuration mode; enables the reflection of BECN signals upon receipt of an FECN

Table 5-8 Exec Command Reference for Generic Traffic Shaping

Command

Function

show traffic-shape [interface-type interface-number]

Lists information about the configuration details

show traffic-shape queue [interface-number [dlci dlci-number]]

Lists statistics about the queuing tool used on the shaping queue

show traffic-shape statistics [interfacetype interface-number]

Lists statistics about shaping operation

The examples in this section use a familiar network diagram, as shown in Figure 5-18. The configuration shows R3, with a 128-kbps access rate, and a 64-kbps Frame Relay VC connecting to R1. Traffic from R3 to R1 is Shaped using the following criteria:

• Shape all traffic at a 64 kbps rate.

• Use the default setting for Tc.

• Enable the configuration per VC.

• Use WFQ on the physical interface output queues.

• Use WFQ on the shaping queues (only choice available).

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 that are shown in each of the two frames inside the browser window. The client also downloads a file using FTP. Additionally, a VoIP call is placed between extension 302 and 102. Example 51 shows the configuration and some sample show commands.

Figure 5-18 Sample Network Used for GTS Configuration Examples

Note: All IP Addresses Begin 192.168. Clientl

1.100

101 102

Note: All IP Addresses Begin 192.168. Clientl

1.100

101 102

GTS:

Shape All Traffic to 64 kbps

301 302

Server1

Server1

3.100

3.100

Example 5-1 CB Shaping on R3, 64-kbps Shape Rate interface serial0/0 bandwidth 64 load-interval 30 fair-queue interface serial0/0.1 traffic-shape 64000

R3#show traffic-shape

Interface Se0/0.1

Access Target VC List Rate - 64000

2000 8000 R3#show traffic-shape statistics

Byte Sustain Excess Limit bits/int bits/int (ms)

Interval Increment Adapt (bytes) Active 1000 -

2000 8000 R3#show traffic-shape statistics

Access Queue

Packets

Bytes

Packets

Bytes

Shaping

I/F

List Depth

Delayed

Delayed

Active

Se0/0.1

65

4285

687360

4248

680272

yes

R3#show traffic-shape statistics serial 0/0.1

Access Queue Packets Bytes I/F List Depth

Se0/0.1 41 4720 752636

Packets Bytes Shaping Delayed Delayed Active 4683 745548 yes

R3#show queue serial 0/0

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

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.

Finally, the show traffic-shape statistics command lists basic statistics about GTS. The last column of output is particularly interesting, because it tells you whether shaping is currently active. IOS does not need to shape all the time, so this column just lists the current state when the command was issued. Shaping activates for three reasons:

• If adaptive shaping is currently reacting to BECNs by lowering the shaped rate

• If Bc and Be have been exceeded, causing packets to be delayed

• If Frame Relay fragmentation is enabled

Queuing occurs on the physical interface when the traffic load exceeds the interface clock rate, and shaping queues form when the traffic load exceeds the shaping rate. In this case, with a single VC, shaped at 64 kbps, and a 128-kbps clock rate on the physical interface, no queues should form on the physical interface. The offered load on the physical link should not exceed 64 kbps, because that is how much traffic the GTS will allow to pass through the only subinterface in the example. The output of the show queue and show traffic-shape queue commands in the example support these facts. The show queue command lists information about WFQ on the physical interface; it does not list any flows, because no congestion is occurring there. However, the show traffic-shape queue command lists information about WFQ's performance with the shaping queues. In this case, it lists information about a VoIP call, and one FTP download.

This particular example reminds us of the importance of the queuing methods supported by the shaping tool. Because GTS only supports WFQ in conjunction with shaping, there is no low-latency option, such as LLQ. The VoIP call in this particular example had a completely unusable quality level.

A second GTS configuration example is shown next. 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.

• Use WFQ on the physical interface output queues.

• Use WFQ on the shaping queues (the only choice available).

The traffic generated for this second example is the same type of traffic generated for the first— a single VoIP call, one web page downloaded with two frames inside the page (causing two

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

Interface Se0/0.1

Access Target

Byte

Sustain

Excess

Interval

Increment Adapt

VC

List Rate

Limit

bits/int

bits/int

(ms)

(bytes) Active

101 64000

800

3200

3200

50

400 -

R3#show traffic-shape statistics

Access Queue Packets Bytes Packets Bytes Shaping

I/F List Depth Delayed Delayed Active

Se0/0.1 101 0 94 120156 59 77376 no

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 show traffic-shape command confirms the calculated Tc value, listing it as 50 ms. Also note that the Be value was set to 3200, because GTS defaults Be to be equal to Bc.

NOTE All IOS shapers use bits as the unit when setting Bc and Be; both policers use bytes as the unit.

The show access-lists command lists the number of packets permitted and denied by ACL 101. Because ACL 101 is used for matching by GTS, this also tells us how many packets were shaped by GTS, and how many were not.

GTS supports several useful traffic-shaping features. It can be used on many types of interfaces, and it can shape a subset of the traffic by referencing ACLs. It can also adapt to BECNs, and reflect FECNs. However, GTS does have several drawbacks. It only supports WFQ in the shaping queues, and it cannot support FRF. 12 fragmentation on Frame Relay subinterfaces. Table 5-9 summaries the key points for comparison between the various traffic-shaping tools, and lists whether GTS supports each.

Table 5-9 Comparison of Traffic-Shaping Tools: GTS

Feature

GTS

Supports ATM, FR, HDLC, PPP, and LAN interfaces

Yes

Can be enabled on interfaces and subinterfaces

Yes

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

No

Supports adaptive shaping

Yes

Supports concurrent FRF. 12 Frame Relay fragmentation

No

Queuing methods allowed in shaping queue

WFQ

Concurrent queuing methods on physical interface

All

Can be configured using MQC commands

No

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

Yes

Default Tc

Variable

Distributes shaping processing to VIPs in 7500 series routers

No

The Google LSI Handbook

The Google LSI Handbook

Here's your chance to learn the secret formula that only the top webmaster's know about, that helps them easily dominate any keyword term. Discover How To Unravel The Mysteries Of Googles Search Engine Rankings, and Stay One Step Ahead Of The Rest In The keywords War!

Get My Free Ebook


Post a comment