From: Radoslav Vasilev (deckland@gmail.com)
Date: Sat Sep 30 2006 - 06:14:46 ART
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 : Sun Oct 01 2006 - 16:55:41 ART