Hi,
I saw in the archive some discussions about those topics but I did't see any aggreement.
So I'll try to put here my thoughts (sorry for my english and some kind of "expression" ). If one get such a topic on a lab it would be a hard task, but we should just think what does Lab expect to from us.
6.2 it says "are guaranteed 80% of CIR value (384Kbit)", it seems that Lab wants us to use "bandwidth percent" command and to solve arrising side effects, not just "bandwidth XXX" because other way it would just say "guaranted 384kbit" as in previous labs. It means that DLCI 501-105 has CIR=384Kbit, and could be configured on R5 like in SG. In oder to get "bandwidth percent 80" working the mincir should be configured to 384000 (CIR means guaranteed bandwidth for this DLCI, means we should be able always use 384000 on that link). it always problem to correctly understand what should we use in particuluar case - cri or mincir, in or case it's mincir, because service policy use mincir for the calculation of available bandwidth.
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 point-to-point
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 cir 384000
frame-relay mincir 384000
service-policy output DLCI_501
if we check now the available bansidth we will see 77 kBits:
show traffic-shape queue
Traffic queued in shaping queue on Serial0/0.501 dlci 501
Queueing strategy: weighted fair
Queueing Stats: 0/600/64/0 (size/max total/threshold/drops)
Conversations 0/0/32 (active/max active/max total)
Reserved Conversations 0/0 (allocated/max allocated)
Available Bandwidth 77 kilobits/sec
6.3. it asks to manage the traffic between Vlan 43 and 367. Remember that R5 sees VLAN367 via R1 and DLCI 501-105, but if this DLCI 501 or R1 goes down the VLAN367 will be seen via DLCI 502.
it states "R1 and R5's port speed is 512KBit", what does it actually mean (in the real world) we can send 512Kbit via DLCI 501 but only upto 384kBit will be guaranteed, it means that in the R5's config we can change CIR to 512000 (we can so much we want or can), but leave mincir as 384000 (in case of congestions we should still get the guaranteed 384kBits), accordingly this new CIR value we should define new bc=5120 and fragment = 640.
new map-class for R5 looks like:
map-class frame-relay DLCI_501
frame-relay cir 512000
frame-relay bc 5120
frame-relay fragment 640
frame-relay mincir 384000
service-policy output DLCI_501
for R1 is the same but without service-policy and mincir, because there is no requriments for this. the "bandwith percent" on R5 still uses the mincir value 38400 as tha baseline for the calculation.
the next statement is "this configuration should not impact R5's DLCI 502", it means if you configured the frame-relay main interface with command "frame-relay traffic-shaiping" then all DLCI which are not explicitly defined use the default value for CIR=56000 but we should keep the 502 DLCI's parameters.
Before we changed the configuration on R5 each DLCIs could be used for sending of 512kBit traffic, we know from 6.2 that DLCI 501 has CIR=384kBits, but we don't know exactly which CIR should we use for DLCI 502. From the 6.3 we know that port speed is 512kBits, it could mean that CIR for DLCI 502 is simply the remaining bandwidth of the port: 512kBit-384kBit = 128kBit, DLCI502 just can't have more then 128kBits guaranteed bandwidth on that serial link, and it doesn't really metter which value we use (because we don't have the information) , it just shouldn't exceed 128000, it means we could leave it as default 56000, but if this task expicitly asks us that the configuration shoudn't impact DLCI 502, it means that the ask wants us to configure DLCI 502 to non-default value and we can use any value which is less 128kBits. then we use following config on R5:
map-class frame-relay DLCI_502
frame-relay cir 512000
frame-relay mincir 128000
and aplly it on DLCI 502 on R5's s0/0.502 interface.This config means that DLCI 502 can use upto 512kBits (as it could before the DLCI 501 was changed) and guaranteed not more then 128kBits (as we suppose it was
before)
As we don't need any QoS on R2 yet and we didn't change it, we leave it unchanged.
6.5 ok, now the most unclear part and from my view the SG is somehow incomplete.
The path from R4 to BB2 is loadsharing between DLCI 501 and 502 (or the task 6.4 should have been policy route the traffic to BB2 via R2), it means that we should configure R5 , R1 and R2 (SG cofgiguresonly R2 and R5). The task ask us simply to give the voice traffic lowest possible latency but don't specify the needed bandwidth and avaiable CIR on the R2. The only possible tool to use in this case is the "ip rtp priority" R5 R2 and R1's configuration looks like:
map-class frame-relay DLCI_502 (DLCI_205, DLCI_105)
frame-relay cir 512000
frame-relay bc 5120
frame-relay fragment 640
frame-relay ip rtp priority 16384 16383 512
task asks as well "voice traffic should also be reduced in size" again without any additional information we can use only "frame-relay ip rtp header-compression" command under R5 and R2 serial interfaces (this command is a recomended command and in CiscoDOC it's used very often togeather wiht "ip rtp priority" command ).
any comments are welcome!