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.

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.

Table 5-14 Command Reference for Frame Relay Traffic Shaping

Command

Mode and Function

frame-relay traffic-shaping

Interface subcommand; enables FRTS on the interface.

class name

Interface DLCI subcommand; enables a specific FRTS map class for the DLCI.

frame-relay class name

Interface or subinterface command; enables a specific FRTS map class for the interface or subinterface.

map-class frame-relay map-class-name

Global configuration mode; names a map class, and places CLI into map-class configuration mode

frame-relay priority-group list-number

Map-class configuration mode; enables PQ for the shaping queues associated with this map class

frame-relay custom-queue-list list-number

Map-class configuration mode; enables CQ for the shaping queues associated with this map class

frame-relay fair-queue [congestive discard threshold [number dynamic conversation queues [number reservable conversation queues [max buffer size_for_fair queues]]]]

Map-class configuration mode; enables WFQ for the shaping queues associated with this map class

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

Map-class configuration mode; enables LLQ or CBWFQ on the shaping queues associated with the map class.

frame-relay traffic-rate average [peak]

Map-class configuration mode; sets the shaped rate, and the EIR*. Bc and Be are calculated from these, based on Tc of 125ms.

frame-relay bc {in | out} bits

Map-class configuration mode; sets the Bc value. Alternative configuration option to frame-relay traffic-rate.

frame-relay be {in | out} bits

Map-class configuration mode; sets the Be value. Alternative configuration option to frame-relay traffic-rate.

frame-relay cir {in | out} bps

Map-class configuration mode; sets the CIR value. Alternative configuration option to frame-relay traffic-rate.

frame-relay adaptive-shaping {becn | foresight}

Map-class configuration mode; enables adaptive shaping, specifying either BECN or Foresight for signaling.

frame-relay mincir {in | out} bps

Map-class configuration mode; sets the minimum CIR used for adaptive shaping.

Table 5-14 Command Reference for Frame Relay Traffic Shaping (Continued)

Table 5-15

Table 5-14 Command Reference for Frame Relay Traffic Shaping (Continued)

Command

Mode and Function

frame-relay tc milliseconds

Map-class configuration mode; for 0 CIR VCs, sets the Tc value.

frame-relay qos-autosense

Interface configuration mode; uses ELMI to automatically discover CIR, Bc, and Be settings for each VC.

* EIR = excess information rate

Exec Command Reference for Frame Relay Traffic Shaping

Command

Function

show frame-relay pvc [interface interface] [dlci]

Shows PVC statistics, including shaping statistics

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

Shows information about FRTS configuration per VC

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

Shows information about the queuing tool used with the shaping queue

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

Shows traffic-shaping statistics

For the sake of comparison, the first FRTS example follows the same requirements as the first GTS and CB shaping examples. The 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.

• Do not specify a particular queuing method for the shaping queue.

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 PC also downloads a file using FTP get. In addition, a VoIP call is placed between extension 302 and 102. Example 5-6 shows the configuration and some sample show commands.

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)

Active Inactive Deleted Static

Switched 0 0 0 0

Unused 0 0 0 0

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

input pkts 135486 output pkts 129093 in bytes 8648302

out bytes 17252015 dropped pkts 5102 in pkts dropped 0

out pkts dropped 7876 out bytes dropped 1227684

late-dropped out pkts 7876 late-dropped out bytes 1227684

in FECN pkts 0 in BECN pkts 0 out FECN pkts 0

out BECN pkts 0 in DE pkts 0 out DE pkts 0

out bcast pkts 1441 out bcast bytes 117294

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

input pkts 135152 output pkts 128787 in bytes 8626938

out bytes 17210463 dropped pkts 5060 in pkts dropped 0

out pkts dropped 7834 out bytes dropped 1212912

late-dropped out pkts 7834 late-dropped out bytes 1212912

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

in FECN pkts 0 in BECN pkts 0 out FECN pkts 0

out BECN pkts 0 in DE pkts 0 out DE pkts 0

out bcast pkts 1440 out bcast bytes 117230

pvc create time 01:45:40, last time pvc status changed 01:29:54

cir 64000 bc 64000 be 0 byte limit 1000 interval 125

mincir 32000 byte increment 1000 Adaptive Shaping none pkts 96272 bytes 11677007 pkts delayed 58459 bytes delayed 9188174

shaping active

traffic shaping drops

2774

Queueing strategy: fifo

Output queue 3/40, 678

drop,

3777 dequeued

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

1000

64000

0

125

1000

R3#show traffic-shape statistics

Access

Queue

Packets

Bytes

Packets

Bytes

Shaping

I/F List

Depth

Delayed

Delayed

Active

Se0/0.1

39

97123

11816731

59238

9317918

yes

R3#show traffic-shape statistics serial

0/0.1

Access

Queue

Packets

Bytes

Packets

Bytes

Shaping

I/F List

Depth

Delayed

Delayed

Active

Se0/0.1

6

97584

11884637

59643

9379560

yes

R3#show traffic-shape queue

Traffic queued in shaping queue on Serial0/0.1 dlci 101 Queueing strategy: fcfs

Queueing Stats: 23/40/959 (size/max total/drops) Packet 1, linktype: ip, length: 64, flags: 0x10000088

source: 192.168.3.254, destination: 192.168.2.251, id: 0x0384, ttl: 253, TOS: 0 prot: 17, source port 16704, destination port 19472 data: 0x4140 0x4C10 0x0028 0x0000 0x8012 0x16FD 0x4D91 0x0E64 0x22FC 0x03FE 0x1E90 0xC796 0x387A 0x5193

Packet 2, linktype: ip, length: 64, flags: 0x10000088

source: 192.168.3.254, destination: 192.168.2.251, id: 0x0384, ttl: 253, TOS: 0 prot: 17, source port 16704, destination port 19472 data: 0x4140 0x4C10 0x0028 0x0000 0x8012 0x16FE 0x4D91 0x0F04 0x22FC 0x03FE 0x144B 0x2EE8 0xC8C2 0x1483

Packet 3, linktype: ip, length: 64, flags: 0x10000088

source: 192.168.3.254, destination: 192.168.2.251, id: 0x0384, ttl: 253, TOS: 0 prot: 17, source port 16704, destination port 19472

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

data: 0x4140 0x4C10 0x0028 0x0000 0x8012 0x16FF 0x4D91 0X0FA4 0x22FC 0x03FE 0xDCEA 0xB529 0x916A 0x5254

! Many lines omitted for brevity

FRTS configuration typically involves three separate steps, although only the first step is actually required.

1 FRTS must be enabled on the physical interface with the frame-relay traffic-shape interface subcommand. This is the only required step.

2 The shaping parameters—the shaping rate, Bc, and Be—need to be configured inside a FRTS map-class command.

3 The shaping parameters defined in the map-class should be enabled on the interface, subinterface, or DLCI using the frame-relay class class-name command.

All three steps were used in Example 5-6. The frame-relay traffic-shape interface subcommand, under serial 0/0, enables FRTS. Next, the frame-relay class shape-all-64 subinterface subcommand tells the router to use the shaping parameters in the map-class called shape-all-64. Finally, the map-class frame-relay shape-all-64 command creates a map class, with the frame-relay traffic-rate 64000 64000 command specifying the shaping rate of 64,000 bps. From the first 64000 parameter, FRTS calculates the Bc and Tc values. The second 64000 in the command sets the excess information rate (EIR), from which the Be is calculated; to have a burst greater than zero, the excess rate must be larger than the shaping rate.

The show frame-relay pvc command, which follows the configuration in the example, lists statistics about each Frame Relay permanent virtual circuit (PVC). However, the show frame-relay pvc 101 command, with a specific VC listed, gives some basic information about FRTS operation on the VC. In this case, the output shows that shaping is active, which means that FRTS was actively shaping packets when this command was issued. (As with other shapers, FRTS shaping is active when packets are in the shaping queues, or as soon as a packet exceeds the traffic contract so that it should be placed in the queues.) The command also lists that the default queuing type of FIFO is used, along with some statistics about the number of packets tail dropped from the shaping queue.

The same show traffic-shape commands used with GTS also provide useful information for FRTS. The show traffic-shape command output shown in Example 5-6 lists the basic shaping settings. Remember, the frame-relay traffic-rate 64000 64000 command did not explicitly set Bc, Be, or Tc, but Bc and Be are shown in the show traffic-shape command output. The logic to derive the values works like this, with CIR representing the configured shaping rate:

• Bc = Tc * CIR (in this example, Bc = .125 * 64000 = 8000)

In this example, the shaping parameters are set as follows:

For each Tc of 125 ms, FRTS allows 8000 bits, so the overall rate becomes 64,000 bps.

Those of you who are thoroughly reading the command output may have noticed that the show traffic-shape command actually lists Bc as 64,000, not the 8000 bits suggested previously. Interestingly, when using the frame-relay traffic-rate command, the show traffic-shape "Sustained Bits/interval" heading lists the bits per second. Internally, a 125-ms Tc value is really used, and a Bc of 8000 is really used—but the output of the command lists the number of bits that can be sent in a full second. The value of 1000 bytes under the heading "Increment (Bytes)" accurately lists the real Bc value used. (I did not believe it either; check out www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/fwan_r/frcmds/ wrffr3.htm#xtocid24, and look for the frame-relay traffic-rate command, for some confirming comments.)

The show traffic-shape statistics and the show traffic-shape queue commands list the same basic information for FRTS as they did for GTS. One piece of terminology not seen with GTS, however, is that the default queuing type of FRTS shaping tools is called "FCFS" in the show command output. FCFS stands for first-come, first-served, which is just another term for FIFO.

You can configure basic FRTS shaping parameters in two ways. The first example, Example 5-6, used the traffic-shape rate command. Alternatively, you can use the frame-relay cir, frame-relay Bc, and frame-relay Be commands to set FRTS shaping parameters inside an FRTS map class. In fact, if you want to manipulate Tc down to a smaller value, which you typically should do to support voice and video traffic, you must use these alternative commands. Remember, Tc = Bc/shaped rate, or Tc = Bc/CIR if you are shaping at the CIR. Example 5-7 lists two examples that use these additional FRTS commands, with show commands listing the changed Tc and Bc values. The commands are applied to R3, the same router as in Example 5-6.

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

R3#show running-config

! Portions of Configuration omitted for Brevity map-class frame-relay shape-all-64-long frame-relay cir 64000 frame-relay bc 8000

! Portions of the configuration omitted for brevity !

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

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 1000 8000 0 125 1000 -

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

Interface Se0/0.1

Access Target VC List Rate 101 64000

Byte Sustain Limit bits/int 80 640

Excess Interval bits/int (ms) 0 10

Increment Adapt (bytes) Active 80 -

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 frame-relay class shape-all-64-shortTC command. The show traffic-shape command follows, listing a Tc value of 10 ms.

In Example 5-8, the lab network has a new remote site added, with a PC named Kris, and a router (R2) with a 64-kbps CIR VC to R3. Suppose that the Frame Relay provider actually polices each VC at 96 kbps. The criteria for the configuration is summarized as follows:

• Shape all traffic from R3 to R1, and from R3 to R2, at 96 kbps.

• Allow burst rates of 112 kbps on each VC.

• Use default settings for Bc and Be.

In this case, traffic to site R1 consists of a single VoIP call, and one web connection with two frames inside the page. At site R2, PC Kris FTP transfers a large file from the FTP server near R3. Figure 5-20 shows the network, and Example 5-8 shows the configuration and some sample show command output.

Figure 5-20 Example Network with VCs from R3 to Two Remote Sites

Figure 5-20 Example Network with VCs from R3 to Two Remote Sites

Example 5-8 R3 FRTS Configuration on Two Different VCs, with Identical Settings

! Many lines omitted for brevity interface Serial0/0 description connected to FRS port S0. Single PVC to R1. no ip address encapsulation frame-relay load-interval 30 no fair-queue clockrate 128000 frame-relay class shape-all-96 frame-relay traffic-shaping

interface Serial0/0.1 point-to-point description point-point subint global DLCI 103, connected via PVC to DLCI 101 (

Example 5-8 R3 FRTS Configuration on Two Different VCs, with Identical Settings (Continued)

ip address 192.168.2.253 255.255.255.0 frame-relay interface-dlci 101

interface Serial0/0.2 point-to-point description point-to-point subint connected to DLCI 102 (R2) ip address 192.168.23.253 255.255.255.0 frame-relay interface-dlci 102

map-class frame-relay shape-all-96 frame-relay traffic-rate 96000 112000 no frame-relay adaptive-shaping

! Lines omitted for brevity

R3#show frame pvc 101

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

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

input pkts 251070 output pkts 239522 in bytes 16004601

out bytes 34597106 dropped pkts 15567 in pkts dropped 0

out pkts dropped 15567 out bytes dropped 3005588

late-dropped out pkts 15567 late-dropped out bytes 3005588

in FECN pkts 0 in BECN pkts 0 out FECN pkts 0

out BECN pkts 0 in DE pkts 0 out DE pkts 0

out bcast pkts 1951 out bcast bytes 158000

pvc create time 02:22:11, last time pvc status changed 02:06:26

cir 96000 bc 96000 be 16000 byte limit 3500 interval 125

mincir 48000 byte increment 1500 Adaptive Shaping none pkts 33292 bytes 4753889 pkts delayed 19315 bytes delayed 3460327

shaping inactive traffic shaping drops 0

Queueing strategy: fifo

Output queue 0/40, 747 drop, 18449 dequeued

R3#show frame pvc 102

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

DLCI = 102, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/0.2

input pkts 4063 output pkts 3820 in bytes 250312

out bytes 3863342 dropped pkts 1206 in pkts dropped 1206

out pkts dropped 0 out bytes dropped 0

in FECN pkts 0 in BECN pkts 0 out FECN pkts 0

out BECN pkts 0 in DE pkts 0 out DE pkts 0

out bcast pkts 587 out bcast bytes 50380

pvc create time 02:22:13, last time pvc status changed 02:05:29

cir 96000 bc 96000 be 16000 byte limit 3500 interval 125

Example 5-8 R3 FRTS Configuration on Two Different VCs, with Identical Settings (Continued)

Example 5-8 R3 FRTS Configuration on Two Different VCs, with Identical Settings (Continued)

The FRTS configuration in this example sets FRTS parameters in a map class, which is then enabled on a physical interface. FRTS always performs shaping on each VC separately; therefore, in this case, the shaping parameters per VC will be picked up from the map class that has been enabled on the physical interface. Notice that a new map class, map-class shape-all-96, is configured with a frame-relay traffic-rate 96000 112000 command to set the CIR and EIR values. The frame-relay class shape-all-96 command has been added to the physical interface, and not to the individual subinterfaces. FRTS includes a feature that I call the inheritance feature, whichjust means that if a subinterface does not have a frame-relay class command, it uses the frame-relay class configured on the physical interface. Similarly, on multipoint subinterfaces, if a map class has not been configured on a particular DLCI, it inherits the FRTS parameters from the map class configured on the subinterface.

The first two show commands after the configuration (show frame pvc 101 and show frame pvc 102) list both shaping parameters and operational statistics. The parameters are the same, because each subinterface picked up its parameters from the map class (shape-all-96) that was enabled on the physical interface. However, the operational statistics differ, because FRTS shapes each VC separately. The show traffic-shape commands that follow confirm the same settings are used on each of the two subinterfaces as well. And in case you still think that FRTS may be shaping all the subinterfaces together, the show traffic-shape statistics command lists the varying statistics for shaping on each VC at the end of the example.

FRTS uses a default setting of CIR = 56kbps, and Tc = 125 ms, if the frame-relay class command does not appear on the interface. In other words, if you enable FRTS on the physical interface with the frame-relay traffic-shape command, but do not enable a map class, FRTS still shapes each VC individually—but it does so with default parameters. So, be careful—pick a good set of default settings, put them in a map class, and enable it on the physical interface as in Example 5-8, just to be safe.

In Example 5-8, the G.729 voice call between R1 and R3 suffered, mainly due to the fact that shaping increases delay, and no effort was made to service the voice traffic more quickly. Suppose that the network engineer notices that IOS supports LLQ as an option for queuing in the shaping queues for FRTS. Therefore, he wants to solve the problem of poor voice quality by putting the voice call into a low-latency queue. With a shaping rate of 96 kbps, and with a single G.729 call, the voice call quality should improve. The criteria for the configuration is summarized as follows:

• Shape all traffic from R3 to R1, and from R3 to R2, at 96 kbps, respectively.

• Use LLQ for queuing on the VC to R1, with 30 kbps maximum in the low-latency queue.

In this case, traffic to site R1 consists of a single VoIP call, and one web connection with two frames inside the page. At site R2, PC Kris FTP transfers a large file from the FTP server near R3. Example 5-9 shows the configuration and some sample show commands.

Example 5-9 FRTS to Two Sites, with LLQ Used in the Shaping Queue to Site 1

R3#show running-config

! Many lines omitted for brevity class-map match-all voip-rtp match ip rtp 16384 16383

policy-map voip-and-allelse class voip-rtp priority 30

interface Serial0/0 description connected to FRS port S0. Single PVC to R1. no ip address encapsulation frame-relay load-interval 30 no fair-queue clockrate 128000 frame-relay class shape-all-96 frame-relay traffic-shaping

Example 5-9 FRTS to Two Sites, with LLQ Used in the Shaping Queue to Site 1 (Continued)

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-with-LLQ frame-relay interface-dlci 101

interface Serial0/0.2 point-to-point description point-to-point subint connected to DLCI 102 (R2) ip address 192.168.23.253 255.255.255.0 frame-relay interface-dlci 102

! Note - No frame-relay class command on previous VC!

map-class frame-relay shape-all-96

frame-relay cir 96000 frame-relay bc 960 frame-relay be 0

map-class frame-relay shape-with-LLQ frame-relay cir 96000 frame-relay bc 960 frame-relay be 0

service-policy output voip-and-allelse

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

input pkts 18487 output pkts 17749 in bytes 1184282

out bytes 2639555 dropped pkts 863 in pkts dropped 0

out pkts dropped 863 out bytes dropped 115649

late-dropped out pkts 863 late-dropped out bytes 115649

in FECN pkts 0 in BECN pkts 0 out FECN pkts 0

out BECN pkts 0 in DE pkts 0 out DE pkts 0

out bcast pkts 364 out bcast bytes 30272

pvc create time 00:26:08, last time pvc status changed 00:24:49 cir 96000 bc 96000 be 16000 byte limit 3500 interval 125 mincir 48000 byte increment 1500 Adaptive Shaping none pkts 17718 bytes 2621259 pkts delayed 15671 bytes delayed 2238337 shaping active traffic shaping drops 0 service policy voip-and-allelse Serial0/0.1: DLCI 101 -

Service-policy output: voip-and-allelse

Example 5-9 FRTS to Two Sites, with LLQ Used in the Shaping Queue to Site 1 (Continued)

Class-map: voip-rtp (match-all) 5101 packets, 326464 bytes

30 second offered rate 25000 bps, drop rate 0 bps Match: ip rtp 16384 16383 Weighted Fair Queueing Strict Priority Output Queue: Conversation 24 Bandwidth 30 (kbps) Burst 750 (Bytes) (pkts matched/bytes matched) 4468/285952 (total drops/bytes drops) 0/0

Class-map: class-default (match-any) 386 packets, 412201 bytes

30 second offered rate 31000 bps, drop rate 0 bps Match: any

Output queue size 42/max total 600/drops 0

R3#show traffic-shape queue serial 0/0.1

Traffic queued in shaping queue on Serial0/0.1 dlci 101 Queueing strategy: weighted fair

Queueing Stats: 15/600/64/0 (size/max total/threshold/drops) Conversations 4/8/16 (active/max active/max total) Reserved Conversations 0/0 (allocated/max allocated) Available Bandwidth 18 kilobits/sec

(depth/weight/total drops/no-buffer drops/interleaves) 5/0/0/0/0 Conversation 24, linktype: ip, length: 64

source: 192.168.3.254, destination: 192.168.2.251, id: 0x012F, ttl: 253, TOS: 0 prot: 17, source port 19018, destination port 17766

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

source: 192.168.3.100, destination: 192.168.1.100, id: 0x177B, ttl: 127, TOS: 0 prot: 6, source port 80, destination port 1148

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

source: 192.168.3.100, destination: 192.168.1.100, id: 0x1775, ttl: 127, TOS: 0 prot: 6, source port 80, destination port 1147

(depth/weight/total drops/no-buffer drops/interleaves) 5/32384/0/0/0 Conversation 12, linktype: ip, length: 1244

source: 192.168.3.100, destination: 192.168.1.100, id: 0x1758, ttl: 127, TOS: 0 prot: 6, source port 1176, destination port 1146

R3#sh traffic-shape queue s 0/0.2

Traffic queued in shaping queue on Serial0/0.2 dlci 102 Queueing strategy: fcfs

Example 5-9 begins with the new FRTS and LLQ configuration. The policy-map voip-and-allelse command defines a policy map that puts all even RTP ports into a low-latency queue, with 32 kbps maximum, and all other traffic into the class-default class. LLQ is enabled inside a new FRTS map-class shape-with-LLQ command, with the service-policy output voip-and-allelse command enabling LLQ inside the map class. Any VC that uses the shape-with-LLQ map class will use the settings in that map class, including the LLQ configuration. In this case, the single VC on subinterface s 0/0.1 uses LLQ for the shaping queue because of the frame-relay class shape-with-LLQ command.

The VC on subinterface S0/0.2 does not use map-class voip-and-allelse. Because no frame-relay class command is configured on subinterface 0/0.2, FRTS uses the shaping parameters from map-class shape-all-64, because it is configured on physical interface s 0/0.

Immediately following the configuration, the show frame-relay pvc 101 command lists a large amount of new information. Essentially, IOS lists the same kinds of information normally seen with the show policy-map interface command in the show frame-relay pvc 101 command. Information about the MQC classes defined, and statistics about the packets in each class, is listed. Also note that the show traffic-shape queue s 0/0.2 at the end of the example reminds us that FCFS is used on the other subinterface.

If you take a step back from the configuration and show commands for a moment, it may be obvious that the two VCs, shaped at 96 kbps each, oversubscribe R3's access link, which is clocked at 128 kbps. Because FRTS only supports FIFO Queuing on the physical interface, congestion still occurs there. Although adding LLQ to subinterface S0/0.1 helped the quality of the voice call, call quality still suffered due to drops and jitter caused by the oversubscribed FIFO output queue on the physical interface s 0/0.

The final solution to the voice quality problem in this case is to take advantage of the queuing feature introduced by FRF. 12 fragmentation. Frame Relay fragmentation (FRF) can be used with FRTS. FRF actually creates a set of two queues on the physical interface, called dual-FIFO queues. Packets that are larger than the fragmentation size are fragmented and placed into one queue. Packets that are equal to, or smaller than, the fragmentation size are not fragmented, and placed into the other queue. IOS treats the nonfragmented frame queue as a priority queue—in other words, it is always serviced first. Therefore, if you want to give great service to small packets such as VoIP, FRF can provide the traditional benefits of fragmentation, and provide a priority queue for all small packets, including VoIP. Figure 5-21 outlines the basic idea, with FRTS on two subinterfaces.

Using FRF to create a two-queue PQ system works well with voice traffic, because the packets are generally small. However, video traffic includes too many larger packets to benefit substantially from FRF's queuing feature, because the larger packets are fragmented and placed in the lower-priority queue. Chapter 7 shows the configuration for adding FRF to this network.

Other FRTS configuration items that might be on the exam include how to configure adaptive shaping, and how to enable FRTS parameters on a VC on a multipoint subinterface. Example 5-10 lists a simple map class configuration that enables adaptive shaping, with the configuration added to DLCI 101, but not DLCI 102, on multipoint subinterface S0/0.33.

Figure 5-21 Interaction Between Shaping Queues, and Frame Relay Fragmentation Queues

Shaping Queues for Subinterface 1

Figure 5-21 Interaction Between Shaping Queues, and Frame Relay Fragmentation Queues

Shaping Queues for Subinterface 1

Shape to 64 kbps
Dual FIFO Interface Queues

Unfragmented Frames; PQ-Like Service

1

TX Ring

Fragmented Frames

t

AR 128 kbps

Example 5-10 FRTS Adaptive Shaping andper-DLCI Configuration

R3#show running-config

! Many lines omitted for brevity interface Serial0/0 description connected to FRS port S0. Single PVC to R1. no ip address encapsulation frame-relay load-interval 30 no fair-queue clockrate 128000 frame-relay class shape-all-96 frame-relay traffic-shaping

interface Serial0/0.33 multipoint description multipoint subint, w/ DLCIs 101 and 102 ip address 192.168.2.253 255.255.255.0 frame-relay interface-dlci 101

class my-adapt-shape-class frame-relay interface-dlci 102

map-class frame-relay shape-all-96 frame-relay traffic-rate 96000 112000

map-class frame-relay my-adapt-shape-class frame-relay traffic-rate 96000 112000 frame-relay adaptive-shaping becn frame-relay mincir 64000

The map-class frame-relay my-adapt-shape-class command creates a new map class with adaptive FRTS enabled. With adaptive shaping, FRTS uses the shape rate as the maximum rate, and the rate configured on the frame-relay mincir command as the minimum rate. The new map-class my-adapt-shape-class command enables adaptive shaping with the frame-relay adaptive-shaping becn command, and sets the mincir with the frame-relay mincir 64000 command. The map class is enabled on DLCI 101, but not DLCI 102, on subinterface s0/0.33.

The example also shows how to enable a map class for a single DLCI. To enable an FRTS map class per DLCI, first enter subinterface configuration mode, and then issue the frame-relay interface-dlci command. This command places you into DLCI configuration mode, where the class my-adapt-shape-class command enables map class my-adapt-shape-class just for this DLCI. Note that after the frame-relay interface-dlci 102 command, there is no class command. So, on DLCI 102, the FRTS parameters in class shape-all-96, as configured on the physical interface, are used.

Table 5-16 summarizes the key points for comparison between the various traffic-shaping tools, highlighting FRTS.

Table 5-16 Comparison of Traffic Shaping Tools: GTS, CB Shaping, DTS, and FRTS

Table 5-16 summarizes the key points for comparison between the various traffic-shaping tools, highlighting FRTS.

Table 5-16 Comparison of Traffic Shaping Tools: GTS, CB Shaping, DTS, and FRTS

Feature

GTS

CB Shaping

DTS

FRTS

Supports ATM, FR, HDLC, PPP, LAN interfaces

Yes

Yes

Yes

No

Can be enabled on interfaces and subinterfaces

Yes

Yes

Yes

Yes

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

No

No

No

Yes

Supports adaptive shaping

Yes

Yes

Yes

Yes

Supports concurrent FRF. 12 Frame Relay fragmentation

No

No

No

Yes

Queuing methods in shaping queue

CBWFQ,

CBWFQ,

LLQ

FIFO, WFQ, CBWFQ, LLQ, PQ, CQ

Concurrent queuing methods on Physical interface

All

All

All

FIFO, FRF*

Can be configured using MQC commands

No

Yes

Yes

No

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

Yes

Yes

Yes

No

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

Feature

GTS

CB Shaping

DTS

FRTS

Default Tc

Variable

125 ms

125 ms

125 ms

Distributes shaping processing to VIPs in 7500 series routers

No

No

Yes

No

* The Cisco QoS course claims WFQ is supported on the physical interface. In addition, FRF is not technically a queuing tool, although its feature of using two queues does achieve the same effect.

* The Cisco QoS course claims WFQ is supported on the physical interface. In addition, FRF is not technically a queuing tool, although its feature of using two queues does achieve the same effect.

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