From: Roberto Fernandez (rofernandez@us.telefonica.com)
Date: Fri Sep 29 2006 - 18:11:14 ART
Frederick,
This result is very interesting, from just seeing your configurations
I'd said you would need also a "bandwith" and "max-reserve-bandwith"
commands on the interface (as a calculations base for the "bandwith
percent" reserve). But your show policy-map interface Serial 0/0 looks
convincing otherwise...
The nested method, first shape, then anything else is the method of
choice for sub interfaces, especially Ethernet ones... for frame relay;
FRTS looks more straight forward but as they say, "there are many ways
to cut a pie".
Best Regards,
Roberto
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Daniel Fredrick
Sent: Friday, September 29, 2006 4:30 PM
To: Cisco certification
Subject: IEWB vol1Lab13 8.2
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
This archive was generated by hypermail 2.1.4 : Sun Oct 01 2006 - 16:55:41 ART