Frame Relay Fragmentation Configuration

The configuration of FRF.12 requires very little effort in itself. However, FRF. 12 requires FRTS, and for the FRF.12 interleaving function to actually work, you need to enable IP RTP Priority or LLQ for the shaping queues on one or more VCs. Therefore, although the FRF.12 new configuration details are brief, the related tools make the configuration a little longer.

The show commands related to FRF.12 give a fairly detailed view into what is actually happening with fragmentation and are covered as part of a couple of examples. Tables 7-13 and 7-14 list the configuration and show commands, respectively, and are followed by two FRF.12 examples.

Table 7-13 Command Reference for Frame Relay Fragmentation

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 user in map-class configuration mode.

frame-relay fragment fragment size

Map-class configuration mode; enables FRF.12 for VCs using this class

Table 7-14 Exec Command Reference for Frame Relay Fragmentation

Command

Function

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

Shows fragmentation statistics

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

Shows statistics about overall performance of a VC

show queueing [interface atm-subinteface [vc [[vPi/] vci]]]

Lists configuration and statistical information about the queuing tool on an interface

The FRF. 12 sample configuration that follows uses the same FRTS configuration details as one of the FRTS examples from Chapter 5, but with the FRF.12 configuration added. The criteria for the configuration is as follows:

• Clock rate is 128 kbps on the access links on each end of the VC between R3 and R1.

• Fragment to 10-ms fragments.

• Shape all traffic at a 64-kbps rate.

• Enable the configuration on the subinterface.

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

In the example, Client 1 downloads two to three web pages, each of which has two frames inside the page. Each web page uses two separate TCP connections to download two separate large JPG files. Client 1 also downloads a file using FTP get. In addition, a VoIP call is placed between extensions 3002 and 1002. Figure 7-16 shows the network used for the example, and Example 7-6 shows the configuration and some sample show commands.

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 clockrate 128000 bandwidth 128

frame-relay traffic-shaping interface Serial0/0.1 point-to-point description point-point subint global DLCI 103, connected via PVC to DLCI 101 ( ip address 192.168.2.253 255.255.255.0 frame-relay class shape-all-64

Figure 7-16 Sample Network for FRF.12 Configuration

Note: All IP Addresses Begin 192.168.

Figure 7-16 Sample Network for FRF.12 Configuration

Note: All IP Addresses Begin 192.168.

3001 3002

Example 7-6 FRF.12 Configuration Sample

Example 7-6 FRF.12 Configuration Sample (Continued) frame-relay interface-dlci 101 IETF

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

! Many lines omitted for brevity map-class frame-relay shape-all-64 frame-relay traffic-rate 64000 640 no frame-relay adaptive-shaping frame-relay fair-queue frame-relay fragment 160

R3#show frame-relay fragment interface s 0/0.1 101

fragment size 160 in fragmented pkts 52 in fragmented bytes 5268 in un-fragmented pkts 5552 in un-fragmented bytes 341743 in assembled pkts 5577 in assembled bytes 346749 in dropped reassembling pkts 0 in timeouts 0

in out-of-sequence fragments 0 in fragments with unexpected B bit in fragments with skipped sequence out interleaved packets 0

fragment type end-to-end out fragmented pkts 9367 out fragmented bytes 1511866 out un-fragmented pkts 6320

out un-fragmented bytes 405268 out pre-fragmented pkts 7387 out pre-fragmented bytes 1862784 out dropped fragmenting pkts 0

set 0 number 0

R3#show frame-relay fragment interface dlci frag-type frag-size in-frag out-frag dropped-fr ag

Serial0/0.1 101 end-to-end 160 54 9700 0

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 6094 output pkts 7926 in bytes 379217

out bytes 1998660 dropped pkts 0 in FECN pkts 0

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

Example 7-6 FRF.12 Configuration Sample (Continued)

in DE pkts 0 out DE pkts 0

out bcast pkts 31 out bcast bytes 2416

pvc create time 00:25:19, last time pvc status changed 00:15:50

R3#show interface s 0/0

Serial0/0 is up, line protocol is up Hardware is PowerQUICC Serial

Description: connected to FRS port S0. Single PVC to R1. MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec, reliability 255/255, txload 20/255, rxload 4/255 Encapsulation FRAME-RELAY, loopback not set Keepalive set (10 sec)

LMI enq sent 14, LMI stat recvd 14, LMI upd recvd 0, DTE LMI up LMI enq recvd 0, LMI stat sent 0, LMI upd sent 0 LMI DLCI 1023 LMI type is CISCO frame relay DTE

Broadcast queue 0/64, broadcasts sent/dropped 65/0, interface broadcasts 61 Last input 00:00:03, output 00:00:00, output hang never Last clearing of "show interface" counters 00:02:20 Queueing strategy: dual fifo Output queue: high size/max/dropped 0/256/0 Output queue 77/128, 176 drops; input queue 0/75, 0 drops 30 second input rate 26000 bits/sec, 51 packets/sec 30 second output rate 122000 bits/sec, 126 packets/sec 6599 packets input, 409250 bytes, 0 no buffer Received 0 broadcasts, 0 runts, 0 giants, 0 throttles 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort 17824 packets output, 2169926 bytes, 0 underruns 0 output errors, 0 collisions, 0 interface resets 0 output buffer failures, 0 output buffers swapped out 0 carrier transitions DCD=up DSR=up DTR=up RTS=up CTS=up

R3#show queueing interface s 0/0

Interface Serial0/1 queueing strategy: priority

Output queue utilization (queue/count)

high/0 medium/0 normal/16513 low/0

! Many lines omitted for brevity

Take a look at the highlighted configuration at the beginning of the example. FRF is configured with the frame-relay fragment command inside a map-class command. In this case, the fragment size was set to 160 bytes, which at a clock rate of 128 kbps implies 10 ms of serialization delay for the longest frame. The rest of the configuration enables FRTS on serial 0/0.1, which enables fragmentation, because the frame-relay fragment 160 command sits inside map-class frame-relay shape-all-64. To review, FRTS is enabled for all VCs on interface s0/0 by the frame-relay traffic-shaping command on the physical interface. To use the specific parameters in the shape-all-64 map class, the frame-relay class shape-all-64 command is used under interface s0/0.1, causing FRTS to use the shaping parameters in the map class, rather than defaults, for the VC to R1.

The next command in the example, show frame-relay fragment int s 0/0.1 101, lists most of the detailed statistics about FRF behavior. It lists counters for input and output packets and bytes as you might expect. In the example, 405,268 bytes have been sent in unfragmented frames, and 1,511,866 bytes in the fragmented frames, for a total of1,917,134 bytes. It also lists a measurement of the number of output bytes that would have been sent had fragmentation not been used, as shown in the counters labeled "pre-fragmented." The number of prefragmented bytes, listed as 1,862,784 in the command, implies that R3 sent about 55,000 more bytes than it otherwise would have had to send had fragmentation not been used.

The shorter version of the same command, show frame-relay fragment, lists the basic configuration settings and just the counter of input and output fragmented packets.

The show frame-relay pvc command lists statistics for each VC, but the counters represent values before fragmentation occurs. To see how the counters in this command and the show frame-relay fragment command compare, examine the highlighted value for packets sent, and the value of prefragmented output packets in the show frame-relay fragment command. The show frame-relay pvc command lists 7926 packets sent. The show frame-relay fragment command lists 7387 prefragmented packets sent, which is only a few less than what was seen in the show frame-relay pvc command that was typed just a few seconds later. Therefore, the show frame-relay pvc command counters are based on the packets before fragmentation.

Next, the show interfaces serial 0/0 command lists one last tidbit of insight into FRF operation. The highlighted portion of the command output lists the queuing method as Dual FIFO. As explained earlier, FRF causes two physical interface output queues to be used, as shown in Figure 7-9. The High queue gets PQ-like treatment, which is how FRF interleaves frames between the fragments in the other FRF output queue.

The final command in the example actually drives home two essential points. The show queueing interface serial 0/0 command lists information about queuing on interface serial 0/0, just as was seen many times in Chapter 4. In this case, it describes the queuing on the physical interface, which we call Dual FIFO. Notice, however, that the command lists the queuing method as "priority," and it lists counters for four queues, named High, Medium, Normal, and Low. So although the queuing method is called Dual FIFO, it behaves like PQ, with only two queues in use.

You may have noticed that the only queue with nonzero counters in the show queueing command is the Normal queue. With FRF.12, the only way to get a packet into the High interface queue is to use IP RTP Priority or LLQ on a shaping queue. In the previous example, the default queuing tool, WFQ, is used on the shaping queues. The next example shows a more typical configuration, with LLQ in use. Networks that need FRF.12 most often are those supporting voice traffic. These same networks need to use LLQ in the shaping queues to help reduce delay and jitter, and use FRF to reduce serialization delay. Shaping should also be tuned with a low

Tc value, to reduce the delay waiting for the next shaping interval. The next example uses a class map called shape-all-96-shortTC, which includes FRF.12, LLQ, with shaping using a 10-ms Tc.

This next example also oversubscribes the access link from R3 to the FR cloud. When supporting voice, Cisco recommends to not oversubscribe an access link. However, many data-oriented Frame Relay designs purposefully oversubscribe the access links. Therefore, when the time comes to add VoIP traffic, increasing the CIRs on all the VCs may not be financially possible. This example uses two VCs, with each shaped at 96 kbps, with a 128-kbps access rate. Figure 7-17 outlines the network.

Figure 7-17 Frame Relay Network with the R3 Access Link Oversubscribed

Client2

The criteria for the example is as follows:

• Clock rate is 128 kbps on all access links.

• Fragment to 10-ms fragments.

• Configure LLQ, with VoIP in the low-latency queue, and all other traffic in another queue.

In the example, Client 1 and Client 2 each download one web page, which has two frames inside the page. Each page download uses two separate TCP connections to download two separate large JPG files. Both PCs also download a file using FTP get. In addition, a VoIP call is placed between extensions 3002 and 1002. Figure 7-17 depicts the network used in the example. Example 7-7 shows the configuration and some sample show commands.

Example 7-7 Oversubscribed Access Link, with FRF.12, LLQ, and Tc = 10 ms

R3#show running-config

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

policy-map voip-and-allelse class voip-rtp priority 30 class class-default fair-queue

interface Serial0/0 description connected to FRS port S0. Single PVC to R1. no ip address encapsulation frame-relay load-interval 30 clockrate 128000 bandwidth 128

frame-relay traffic-shaping

interface Serial0/0.1 point-to-point description point-point subint global DLCI 103, connected via PVC to DLCI 101 ( ip address 192.168.2.253 255.255.255.0 frame-relay class shape-all-96-shortTC frame-relay interface-dlci 101 IETF

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 class shape-all-96-shortTC frame-relay interface-dlci 102

map-class frame-relay shape-all-96-shortTC no frame-relay adaptive-shaping frame-relay cir 96000 frame-relay bc 960

service-policy output voip-and-allelse frame-relay fragment 160

Example 7-7 Oversubscribed Access Link, with FRF.12, LLQ, and Tc = 10 ms (Continued) R3#show traffic-shape serial 0/0.1

Interface Se0/0.1

Access Target Byte Sustain Excess Interval

VC List Rate Limit bits/int bits/int (ms)

101 96000 120 960 0 10

Increment Adapt (bytes) Active 120 -

R3#show traffic-shape serial 0/0.2

Interface Se0/0.2

Access Target Byte Sustain Excess Interval

VC List Rate Limit bits/int bits/int (ms)

102 96000 120 960 0 10

Increment Adapt (bytes) Active 120 -

R3#show frame-relay fragment interface serial 0/0.1 101

fragment size 160 in fragmented pkts 14 in fragmented bytes 1386 in un-fragmented pkts 596 in un-fragmented bytes 35967 in assembled pkts 603 in assembled bytes 37283 in dropped reassembling pkts 0 in timeouts 0

in out-of-sequence fragments 0 in fragments with unexpected B bit in fragments with skipped sequence out interleaved packets 662

fragment type end-to-end out fragmented pkts 843 out fragmented bytes 135638 out un-fragmented pkts 1607 out un-fragmented bytes 103064 out pre-fragmented pkts 1706 out pre-fragmented bytes 234764 out dropped fragmenting pkts 0

set 0 number 0

R3#show frame-relay fragment interface serial 0/0.2 102

fragment size 160 in fragmented pkts 0 in fragmented bytes 0 in un-fragmented pkts 285 in un-fragmented bytes 12764 in assembled pkts 285 in assembled bytes 12764 in dropped reassembling pkts 0 in timeouts 0

in out-of-sequence fragments 0 in fragments with unexpected B bit set 0 in fragments with skipped sequence number 0 out interleaved packets 0

fragment type end-to-end out fragmented pkts 1541 out fragmented bytes 235482 out un-fragmented pkts 27 out un-fragmented bytes 1555 out pre-fragmented pkts 296 out pre-fragmented bytes 227911 out dropped fragmenting pkts 0

R3#show policy-map interface serial 0/0.2

Service-policy output: voip-and-allelse

Example 7-7 Oversubscribed Access Link, with FRF.12, LLQ, and Tc = 10 ms (Continued)

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

30 second offered rate 0 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) 0/0 (total drops/bytes drops) 0/0

Class-map: class-default (match-any) 1440 packets, 1275806 bytes

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

R3#show queueing interface serial 0/0

Interface Serial0/0 queueing strategy: priority

Output queue utilization (queue/count)

high/9514 medium/0 normal/34038 low/0

The FRF.12 configuration portion of the example is comprised again of a single command, frame-relay fragment 160, configured inside map-class frame-relay shape-all-96-shortTC. The rest of the configuration meets the other requirements stated before the example. The map class includes a setting of CIR to 96,000 bps, and a Bc of 960 bits, yielding a Tc value of 960/96,000, or 10 ms. The policy-map voip-and-allelse command defines LLQ for VoIP, with all other traffic being placed in the class-default queue. The service-policy output voip-and-allelse command under class-map frame-relay shape-all-96-shortTC enables LLQ for all VCs that use the class. FRTS is of course enabled on the physical interface, with the frame-relay class shape-all-96-shortTC subinterface command causing each of the two VCs to use the FRTS parameters in the map class, rather than the FRTS defaults.

Immediately following the configuration in the example, two show frame-relay traffic-shaping commands verify the settings made in the configuration. Both show a calculated Tc value of 10 ms, and a Bc of 960.

Next comes a pair of show frame-relay fragment interface commands, one for subinterface s 0/0.1, and one for serial interface 0/0.2. On serial 0/0.1, the last line of output points out that interleaves did occur. For interleaves to occur, at least a small amount of congestion must occur on the physical interface. With two VCs shaped at 96 kbps, and a 128-kbps access link, and plenty of generated traffic, some congestion did occur. Notice however that serial 0/0.2 does not show any interleaved packets. All the traffic generated going from R3 to R2 was FTP and HTTP traffic, neither of which gets classified into the low-latency queue. In the show policy-map interface serial 0/0.2 command that ends the example, for instance, notice that the counters show no packets have been in the low-latency queue. This example shows a perfect case where you have a VC (R3 to R2) that does not really need FRF for itself; FRF should be enabled, however, so that the small packets from other VCs can be interleaved.

The show queueing interface serial 0/0 command shows incrementing counters for both the High queue and the Normal queue. Because one voice call is using the VC from R3 to R1, the voice packets get placed into the R3-to-R1 VC's low-latency queue, and then placed into the Dual FIFO High queue. (Interestingly, I did a few repetitive show queueing commands, once every 5 seconds, and saw the High queue counter increment about 250 packets per 5-second interval. With 20 ms of payload, each G.729 call sends 50 packets per second, so the counters reflected the fact that the voice packets from the low-latency queue were being placed into the Dual FIFO High queue.)

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