From: eicc tester (reto_ccie@yahoo.com)
Date: Mon Aug 13 2007 - 11:30:32 ART
This is a good point to discuss, in order to avoid misinterpretation in the lab requirements.
Herbert Maosa <asawilunda@googlemail.com> wrote:
I believe he IS doing FRTS, only that he is using MQC and not legacy FRTS. Using MQC you do not need to specify your traffic shaping parameters with the frame-relay CIR and frame-relay minCIR commands. The CIR becomes what you specify with the shape average|peak command and the minCIR is what you specify with the shape adapative command.
On 8/13/07, eicc tester <reto_ccie@yahoo.com> wrote: Hi,
In your config really your are not doing FRTS (frame relay traffic shapping) for that you need to configure the command frame-relay cir and mincir under map-class frame relay and active frame-relay traffic shaping on interface.
you configure fragment of 80 under map-class, this mean, that FRF-12, will be fragmenting every 640 bits. this mean about 10 msg.
But if you see the configuration you will see that your MQC shaping give you a TC of 125msg. please see below:
R1#sh policy-map INterface SErial 1/4.601
Serial1/4.601: DLCI 601 -
Service-policy output: shape_policy_map
Class-map: class-default (match-any)
2 packets, 405 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)
64000/64000 2000 8000 8000 125 1000
Adapt Queue Packets Bytes Packets Bytes Shaping
Active Depth Delayed Delayed Active
BECN 0 6 433 5 353 no
I suggest that you set the bc on shape average comand in order to ensure that you Tc be 10 msg. and agree with fragment use in FRF-12 fragment, to be consistent.
R1(config-pmap-c)#SHape AVerage 64000 640
sh policy-map INterface SErial 1/4.601
Serial1/4.601: DLCI 601 -
Service-policy output: shape_policy_map
Class-map: class-default (match-any)
2 packets, 405 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)
64000/64000 160 640 640 10 80
Adapt Queue Packets Bytes Packets Bytes Shaping
Active Depth Delayed Delayed Active
BECN 0 6 433 5 353 no
Voice traffic always have guaranted of 32 Kbps.
Ken Young <CiscoKid@ns.sympatico.ca> wrote:
Can anyone confirm my assumption about the following configuration?
- CIR = 64 kbps, miniCIR= 32 kbps.
- A nested LLQ policy which guarantees 32 kbps of low latency bandwidth for
voice (or 'ef' traffic).
*IF* a BECN is received on the PVC; this router will slow its shaping rate
to miniCIR of 32 kbps, because we have a llq configured for 32 kbps of
voice, during a period of congestion it is 'theatrically' possible that ONLY
voice traffic would be transmitted if the voice Q was pushing the full 32
kbps worth of voice traffic.
Am I interrupting that correctly?
class-map voice
match ip dscp ef
!
policy-map llq
class voice
priority 32
!
policy-map shape_policy_map
class class-default
shape average 64000
shape adaptive 32000
service-policy llq
!
map-class frame-relay shape_map_class
frame-relay fragment 80
service-policy output shape_policy_map
!
interface serial0/0
encapsulation frame-relay
!
interface serial0/0.601 point-to-point
ip address 192.168.1.1 255.255.255.0
frame-relay interface-dlci 601
class shape_map_class
This archive was generated by hypermail 2.1.4 : Sat Sep 01 2007 - 11:32:11 ART