From: Thomwin Chen (thomwin_chen@yahoo.com)
Date: Sun Jul 03 2005 - 08:25:05 GMT-3
Bob and Chris,
thanks.
I also get the same result
Rack1R4(config-pmap-c)#shape average 64000
Shaping is not allowed simultaneously at the physical interface and subinterfaces or at interface/subinterface and PVCs
Rack1R4(config)#map-class frame-relay cisco
Rack1R4(config-map-class)#servic
Rack1R4(config-map-class)#service-policy outpu
Rack1R4(config-map-class)#service-policy output cisco2
Remove frame-relay traffic shaping first beforeusing GTS in Modular QoS CLI
below is the output after applying MQC-Based FRTS ( after frame-relay traffic-shaping command removed in main interface )
Rack1R4#show policy-map int s0/1.1
Serial0/1.1
Service-policy output: cisco2
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)
64000/64000 2000 8000 8000 125 1000
Adapt Queue Packets Bytes Packets Bytes Shaping
Active Depth Delayed Delayed Active
- 0 0 0 0 0 no
yup, the be and bc by default has the same value. (8000 in this example)
thanks.
"Chris Lewis (chrlewis)" <chrlewis@cisco.com> wrote:
Hi Bob,
Yes, that would not work, but that was not what I was suggesting :)
perhaps I could be a little clearer, so here goes an attempt.
Let's say you want to classify multiple types of IP traffic for
different treatment on the one DLCI, but want per DLCI shaping,
fragmentation and so forth. This is accomplished in many large providers
that offer QoS enabled MPLS VPN service by the following (the config
below would appear on the CE):
Classification will be similar to this
class-map match-all voip
match ip access-group 100
class-map match-all bus
match ip access-group 101
class-map match-all mgt
match ip access-group 103
class-map match-all rp
match ip access-group 104
class-map match-all be
match any
A policy map will be setup something like this:
policy-map XYZ
class voip
priority 64 1600
class rp
bandwidth 8
queue-limit 40
class mgt
bandwidth 8
class bus
bandwidth 154
class be
bandwidth 22
The service policy is then applied to the map-class (so that frame-relay
traffic shaping and FRTS can be applied), which then makes it in to the
interface as follows:
interface serial1/0
encap frame-relay IETF
frame relay traffic-shaping
!
interface serial1/0.1 point-to-point
ip address 192.168.48.4 255.255.255.0
frame-relay class frts-xyz
frame-relay interface-dlci 100 IETF
!
map-class frame-relay frts-xyz
no frame-relay adaptive-shaping
frame-relay cir 256000
frame-relay mincir 256000
frame-relay bc 2560
service-policy output XYZ <--this is the glue that gives you MQC
functionality with FRTS on a per DLCI basis
frame-relay fragment 160
Now this specific example is specifically setup so that the frame is
assumed to be lossless (cir=mincir), so that all drop decisions are at
layer 3, but the general concept of applying a service-policy to the
map-class to illustrate the use of MQC when fame-relay traffic shaping
is enabled on the interfaces is what I was trying to show.
HTH
Chris
________________________________
From: Bob Sinclair [mailto:bsinclair@netmasterclass.net]
Sent: Thursday, June 16, 2005 11:18 AM
To: Chris Lewis (chrlewis); ccielab@groupstudy.com
Subject: Re: MQC-Based FRTS
Chris,
Combining frame-relay traffic-shaping with MQC-based does not seem to
work for me. When I try to apply the map-class I get this response:
R1(config-subif)#frame interface-dlci 102
R1(config-fr-dlci)#class SHAPE
Remove frame-relay traffic shaping first beforeusing GTS in Modular QoS
CLI
It seems to be OK if the policy-map is just policing, for example. But
the IOS does not seem to permit multiple shaping techniques on the same
interface.
HTH,
Bob Sinclair
CCIE #10427, CCSI 30427, CISSP
www.netmasterclass.net
----- Original Message -----
From: Chris Lewis (chrlewis)
To: Bob Sinclair ;
Thomwin Chen ; ccielab@groupstudy.com
Sent: Thursday, June 16, 2005 2:10 AM
Subject: RE: MQC-Based FRTS
Bob,
Would you agree that there may be circumstances where even
though you
are using MQC, you also need to apply a class map, as some
command may
not yet be supported within MQC.
So, in this case one would apply the MQC service-policy under
the
map-class configuration, the class then gets applied to a frame
interface or DLCI, depending on configuration, and then the
frame-relay
traffic-shaping command is required under the frame interface,
even
though MQC is being used.
Chris
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On
Behalf Of
Bob Sinclair
Sent: Wednesday, June 15, 2005 12:23 PM
To: Thomwin Chen; ccielab@groupstudy.com
Subject: Re: MQC-Based FRTS
Thomwin,
No, do not configure the command "frame-relay traffic-shaping"
when
doing MQC-based shaping. When doing MQC-based shaping remember
that the
"shape average" command automatically sets Be equal to Bc, so
set Be
explictly to 0 if the task does not require an excess burst.
Also
remember that if you want to shape at the DLCI level, using a
map-class
frame-relay, then you must shape class class-default.
HTH,
Bob Sinclair
CCIE #10427, CCSI 30427, CISSP
www.netmasterclass.net
----- Original Message -----
From: Thomwin Chen
To: ccielab@groupstudy.com
Sent: Wednesday, June 15, 2005 1:02 PM
Subject: MQC-Based FRTS
Hi All,
just want to confirm.
to configure MQC-Based FRTS, should I use frame-relay
traffic-shaping
command in main interface ?
In CiscoDoc, MQC-Based FRTS don't have frame-relay
traffic-shaping
command in main interface ??
http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122newft
/12
2t/122t13/frqosmqc.htm
thanks
This archive was generated by hypermail 2.1.4 : Sun Sep 04 2005 - 17:00:29 GMT-3