Frame-relay trafficshaping

[Amit Singh]

All,

Just need a little clarification on the doubt that I have with FRTS.

1. Do we enable " frame-relay traffic shaping )under the FR interface only with legacy FRTS config.

2. With MQC FRTS we dont need the "frame-relay traffic shaping command" under the FR interface.

I think the answer is correct for both the questions, just need suggestion on that.

-amit singh

[Amit Singh]

Thanks Guys.. Got the answer for that. Yes, its true for both the questions.

" Configuring traffic shaping using MQC and configuring traffic shaping using traditional FRTS commands are mutually exclusive. Traffic shaping cannot be configured on the same interface using both methods."

-amit singh

[Edison Ortiz]

Hi Amit :)

1. Here is the output I get if I try to enable frame-relay traffic shaping under a serial interface with MQC configured.

Rack1R2(config-if)#frame traffic-shaping

Generic traffic shaping commands must be removed before enabling frame-relay

traffic shaping.

2. Correct, the following output from an interface configured with MQC FRTS

Rack1R2#sh policy-map interface

Serial1/0: DLCI 203 -

Service-policy output: FRTS

Class-map: class-default (match-any)

0 packets, 0 bytes

5 minute offered rate 0 bps, drop rate 0 bps

Match: any

Traffic Shaping

Target/Average Byte Sustain Excess Interval Increment

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

192000/192000 240 1920 0 10 240

Adapt Queue Packets Bytes Packets Bytes Shaping

Active Depth Delayed Delayed Active

- 0 0 0 0 0 no

___________________________

Rack1R2#sh run | sec MQC-FRTS

class MQC-FRTS

map-class frame-relay MQC-FRTS

service-policy output FRTS

Rack1R2#sh run | sec policy-map

policy-map FRTS

class class-default

shape peak 192000 1920 0

Rack1R2#sh run int s1/0

interface Serial1/0

ip address 192.168.23.2 255.255.255.0

encapsulation frame-relay

serial restart-delay 0

frame-relay map ip 192.168.23.3 203 broadcast

frame-relay interface-dlci 203

class MQC-FRTS

no frame-relay inverse-arp

HTH,