From: Dale Shaw (dale.shaw@gmail.com)
Date: Fri Feb 27 2009 - 00:54:15 ARST
Hi all,
Re: traffic shaping on Frame Relay links using the MQC (as distinct from FRTS)
Is there any functional difference between the following two configs? See below:
Configuration #1:
class-map match-all FR-R2
match fr-dlci 102
class-map match-all FR-R3
match fr-dlci 103
class-map match-all FR-R4
match fr-dlci 104
!
policy-map THING
class FR-R2
shape average 64000 8000 0
shape adaptive 32000
class FR-R3
shape average 128000 16000 0
shape adaptive 64000
class FR-R4
shape average 192000 24000 0
shape adaptive 96000
!
interface Serial0/0/0
ip address 10.1.1.1 255.255.255.0
encapsulation frame-relay
load-interval 30
frame-relay map ip 10.1.1.2 102
frame-relay map ip 10.1.1.3 103
frame-relay map ip 10.1.1.4 104
no frame-relay inverse-arp
service-policy output THING
Configuration #1 "sh policy-map interface" output:
R1#sh policy-map int s0/0/0 out
Serial0/0/0
Service-policy output: THING
Class-map: FR-R2 (match-all)
3226 packets, 4616500 bytes
30 second offered rate 64000 bps, drop rate 0 bps
Match: fr-dlci 102
Traffic Shaping
Target/Average Byte Sustain Excess Interval Increment
Rate Limit bits/int bits/int (ms) (bytes)
64000/64000 1000 8000 0 125 1000
Adapt Queue Packets Bytes Packets Bytes Shaping
Active Depth Delayed Delayed Active
- 3 3223 4612240 1150 1612073 yes
[...]
Configuration #2:
policy-map THING-R2
class class-default
shape average 64000 8000 0
shape adapt 32000
!
policy-map THING-R3
class class-default
shape average 128000 16000 0
shape adapt 64000
!
policy-map THING-R4
class class-default
shape average 192000 24000 0
shape adapt 96000
!
map-class frame FR-R2
service-policy out THING-R2
!
map-class frame FR-R3
service-policy out THING-R3
!
map-class frame FR-R4
service-policy out THING-R4
!
interface Serial0/0/0
ip address 10.1.1.1 255.255.255.0
encapsulation frame-relay
load-interval 30
frame-relay map ip 10.1.1.2 102
frame-relay map ip 10.1.1.3 103
frame-relay map ip 10.1.1.4 104
no frame-relay inverse-arp
frame-relay interface-dlci 102
class FR-R2
frame-relay interface-dlci 103
class FR-R3
frame-relay interface-dlci 104
class FR-R4
Configuration #2 "sh policy-map interface" output:
R1#sh policy-map int s0/0/0 out
Serial0/0/0: DLCI 102 -
Service-policy output: THING-R2
Class-map: class-default (match-any)
1537 packets, 2214376 bytes
30 second offered rate 64000 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 1000 8000 0 125 1000
Adapt Queue Packets Bytes Packets Bytes Shaping
Active Depth Delayed Delayed Active
BECN 3 1534 2210116 1533 2208612 yes
[...]
Configuration #2 provides cleaner/more intuitive output in "show
policy-map interface" (e.g. shows the discrete DLCIs the policies are
applied to). It's not clear to me whether Configuration #1 results in
a functional adaptive shaping configuration, either, since the "show
policy-map interface" output says nothing about BECNs.
In terms of the actual shaping rate, both configurations seem to have
the desired effect:
R1#sh int s0/0/0 | i output rate
30 second output rate 384000 bits/sec, 33 packets/sec
(this is with R2 (64Kbps), R3 (128Kbps) and R4 (192Kbps) all
transferring an IOS image from R1 using HTTP -- total = 384Kbps)
cheers,
Dale
Blogs and organic groups at http://www.ccie.net
This archive was generated by hypermail 2.1.4 : Sun Mar 01 2009 - 09:44:13 ARST