From: Radoslav Vasilev (deckland@gmail.com)
Date: Sun Oct 01 2006 - 13:22:21 ART
When you have policy-map applied in that fashion (with percantage),it
will use the mincir value as the DLCI bandwidth. That could easily be
checked.
Rado
On 10/1/06, Daniel Fredrick <dfredrick@gmail.com> wrote:
> Another good question is... how would I verify that the IEWB answer is
> correct. Because it is setting the CIR ( in the end to 512Kbps) and the
> mincir is 384Kbps... In my understanding, mincir is only used with adaptive
> shaping. If I looked that this map-class in the end...
>
> map-class frame-relay DLCI_501
> frame-relay cir 512000
> frame-relay bc 5120
> frame-relay mincir 384000
> service-policy output DLCI_501
> frame-relay fragment 640
>
> I would think that the policy-map that is allowing 80% of the bandwidth...
> it will be 80% of 512Kbps, which I don't think is correct.
>
> Doesn't anyone know a show command to verify frame-relay map-class and see
> what effect the policy-map has on it?
>
> Thanks,
> Dan
>
>
>
> On 9/30/06, Radoslav Vasilev <deckland@gmail.com> wrote:
> > Hi Daniel,
> >
> > I'm not an QoS expert and therefore I would do it exactly like in the
> > IEWB solution.
> > The reason for this is that the next task (8.3) calls for LFI on the
> > same PVC and I personally am not sure how your solution would work in
> > conjunction with the lower-level frame-relay map.
> >
> > I recall that once you enable FRTS on an PVC, it gets dual-FIFO queues
> > and this is the part where I don't understand how your hierarchical
> > policy-map would fit in.
> >
> > Any opinion appreciated!
> >
> > Rado
> >
> >
> > On 9/29/06, Daniel Fredrick < dfredrick@gmail.com> wrote:
> > > Hello,
> > >
> > > I am not clear about the following question:
> > >
> > > Configure a QOS policy on R5 so that HTTP packets returning from the
> > > Internet destined for vlan 11 are guaranteed 80% of the CIR value (384K)
> > > outbound on S0/0's DLCI 501.
> > >
> > > The solutions guide states the following solution using the frame relay
> > > traffic shaping.
> > >
> > > class-map match-all HTTP_RESPONSES
> > >
> > > match access-group name HTTP_RESPONSES
> > >
> > > !
> > >
> > > policy-map DLCI_501
> > >
> > > class HTTP_RESPONSES
> > >
> > > bandwidth percent 80
> > >
> > > !
> > >
> > > interface Serial0/0
> > >
> > > frame-relay traffic-shaping
> > >
> > > !
> > >
> > > interface Serial0/0.501 multipoint
> > >
> > > frame-relay class DLCI_501
> > >
> > > !
> > >
> > > ip access-list extended HTTP_RESPONSES
> > >
> > > permit tcp any eq www 139.1.11.0 0.0.0.255
> > >
> > > !
> > >
> > > map-class frame-relay DLCI_501
> > >
> > > frame-relay mincir 384000
> > >
> > > service-policy output DLCI_501
> > >
> > > However, I thought that the above problem could be addressed using
> nested
> > > policy maps instead
> > >
> > > policy-map www
> > > class HTTP_RESPONSES
> > > bandwidth percent 80
> > > policy-map parent
> > > class class-default
> > > shape average 384000
> > > service-policy www
> > >
> > > int s0/0.15 point-to-point
> > > service-policy output parent
> > >
> > > Rack1R5#sho policy-map interface
> > > Serial0/0
> > >
> > > Service-policy output: parent
> > >
> > > Class-map: class-default (match-any)
> > > 3 packets, 181 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)
> > > 384000/384000 2400 9600 9600
> 25 1200
> > >
> > > Adapt Queue Packets Bytes Packets Bytes Shaping
> > > Active Depth Delayed Delayed Active
> > > - 0 2 168 0 0 no
> > >
> > > Service-policy : www
> > >
> > > Class-map: www (match-all)
> > > 0 packets, 0 bytes
> > > 5 minute offered rate 0 bps, drop rate 0 bps
> > > Match: access-group 105
> > > Queueing
> > > Output Queue: Conversation 41
> > > Bandwidth 80 (%)
> > > Bandwidth
> > >
> > > Rack1R5#sho policy-map interface
> > > Serial0/0
> > >
> > > Service-policy output: parent
> > >
> > > Class-map: class-default (match-any)
> > > 3 packets, 181 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)
> > > 384000/384000 2400 9600 9600
> 25 1200
> > >
> > > Adapt Queue Packets Bytes Packets Bytes Shaping
> > > Active Depth Delayed Delayed Active
> > > - 0 2 168 0 0 no
> > >
> > > Service-policy : www
> > >
> > > Class-map: www (match-all)
> > > 0 packets, 0 bytes
> > > 5 minute offered rate 0 bps, drop rate 0 bps
> > > Match: access-group 105
> > > Queueing
> > > Output Queue: Conversation 41
> > > Bandwidth 80 (%)
> > > Bandwidth 307 (kbps)Max Threshold 64 (packets)
> > > (pkts matched/bytes matched) 0/0
> > > (depth/total drops/no-buffer drops) 0/0/0
> > >
> > > Class-map: class-default (match-any)
> > > 3 packets, 181 bytes
> > > 5 minute offered rate 0 bps, drop rate 0 bps
> > > Match: any
> > >
> > > Max Threshold 64 (packets)
> > > (pkts matched/bytes matched) 0/0
> > > (depth/total drops/no-buffer drops) 0/0/0
> > >
> > > Class-map: class-default (match-any)
> > > 3 packets, 181 bytes
> > > 5 minute offered rate 0 bps, drop rate 0 bps
> > > Match: any
> > >
> > > And it looks like the correct answer because the web traffic is getting
> 80%
> > > of 384Kbps (307Kbps)
> > >
> > > I understand that there is more than one way of doing things, but just
> > > wondering if this would be considered a correct answer as well?
> > >
> > > Thanks,
> > >
> > > Dan
> > >
> > >
> _______________________________________________________________________
> > > Subscription information may be found at:
> > > http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Wed Nov 01 2006 - 07:29:03 ART