From: Daniel Fredrick (dfredrick@gmail.com)
Date: Sun Oct 01 2006 - 12:47:11 ART
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