RE: GOOD URL: MQC comparing between bandwidth vs priority

From: simon hart (simon.hart@btinternet.com)
Date: Mon May 23 2005 - 10:54:10 GMT-3


San,

A couple of points here, that may add some clarity. If you apply a service
policy direct to a Frame interface then the queueing mechanism will be
applied to a single large interface queue rather than to per-Virtual
Circuit (VC) queues. By applying directly to the Frame interface, you
cannot use Frame Relay Traffic shaping, and therefore cannot apply a policy
per pvc.
In such a situation the Service policy will use the 'max-reserved-bandwidth'
configured for the interface, however the queueuing would be across all
PVC's.

The URL Mani posted referred to implies that the service policy is being
applied to an ATM or Frame PVC. In such a case FRTS would need to be
invoked. When you embed a service policy into a FRTS map class, then the
service policy no longer uses the max reserved bandwidth on the interface as
its reference point.
The service policy will now use MinCir to determine the bandwidth by which
it is calculating its queueing. The MinCir will either be hard configured,
or derived from the CIR configured as part of the FRTS statements (MinCir =
CIR/2).

http://www.cisco.com/warp/public/105/cbwfq_frpvs.html

HTH

Simon

-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com]On Behalf Of
san
Sent: 23 May 2005 04:47
To: simon hart
Cc: gladston@br.ibm.com; ccielab@groupstudy.com
Subject: Re: GOOD URL: MQC comparing between bandwidth vs priority
command

Glad / Simon,

Why not "max-reserved-bandwidth" is supported in FR interfaces ?

See the below output, the above command is allowed if fair-queue. I
am missing something very basic, clarify me.

/SAN

Rack1R1#sh queueing inter serial 0/0
Interface Serial0/0 queueing strategy: none
Rack1R1#sh inter serial 0/0
Serial0/0 is up, line protocol is up
  Hardware is PowerQUICC Serial
  Internet address is 174.1.145.1/24
  MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec,
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation FRAME-RELAY, loopback not set
  Keepalive set (10 sec)
  LMI enq sent 17069, LMI stat recvd 17050, LMI upd recvd 0, DTE LMI up
  LMI enq recvd 0, LMI stat sent 0, LMI upd sent 0
  LMI DLCI 1023 LMI type is CISCO frame relay DTE
  FR SVC disabled, LAPF state down
  Broadcast queue 0/64, broadcasts sent/dropped 19481/0, interface
broadcasts 13519
  Last input 00:00:01, output 00:00:01, output hang never
  Last clearing of "show interface" counters 1d23h
  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
  Queueing strategy: fifo
  Output queue: 0/40 (size/max)
  5 minute input rate 1000 bits/sec, 1 packets/sec
  5 minute output rate 3000 bits/sec, 1 packets/sec
     77933 packets input, 9003395 bytes, 0 no buffer
     Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
     3 input errors, 0 CRC, 3 frame, 0 overrun, 0 ignored, 0 abort
     80287 packets output, 11421181 bytes, 0 underruns
     0 output errors, 0 collisions, 9 interface resets
     0 output buffer failures, 0 output buffers swapped out
     4 carrier transitions
     DCD=up DSR=up DTR=up RTS=up CTS=up

Rack1R1#sh queueing inter fas0/0
Interface FastEthernet0/0 queueing strategy: none
Rack1R1#confi t
Enter configuration commands, one per line. End with CNTL/Z.
Rack1R1(config)#inter seri
Rack1R1(config)#inter serial 0/0
Rack1R1(config-if)#max
Rack1R1(config-if)#max-reserved-bandwidth ?
  <1-100> Max. reservable bandwidth as % of interface bandwidth
  <cr>

Rack1R1(config-if)#max-reserved-bandwidth 50
<<<<<================
Reservable bandwidth is being reduced.
Some existing reservations may be terminated.
Rack1R1(config-if)#exit
Rack1R1(config)#
Rack1R1(config)#end
Rack1R1#sh
*Mar 3 20:49:36.009: %SYS-5-CONFIG_I: Configured from console by console
Rack1R1#sh queueing inter serial 0/0
Interface Serial0/0 queueing strategy: none
Rack1R1#confi t
Enter configuration commands, one per line. End with CNTL/Z.
Rack1R1(config)#inter serial 0/0
Rack1R1(config-if)#fair
Rack1R1(config-if)#fair-queue
Rack1R1(config-if)#end
Rack1R1#
Rack1R1#confi t
*Mar 3 20:50:10.317: %SYS-5-CONFIG_I: Configured from console by console
Rack1R1#sh queueing inter serial 0/0
Interface Serial0/0 queueing strategy: fair
  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
  Queueing strategy: weighted fair
  Output queue: 0/1000/64/0 (size/max total/threshold/drops)
     Conversations 0/1/256 (active/max active/max total)
     Reserved Conversations 0/0 (allocated/max allocated)
     Available Bandwidth 772 kilobits/sec ....===================<<<<

On 5/21/05, simon hart <simon.hart@btinternet.com> wrote:
> Gladston,
>
> I see where you are coming from. It would be better phrased (IMHO)
>
> If you apply this policy to a link where the maximum reserved bandwidth is
> 1Mbps...........................................
>
> Also this would work where the configured MinCir for the Frame relay link
> was 1Mbps
>
> Simon
>
> -----Original Message-----
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com]On Behalf Of
> gladston@br.ibm.com
> Sent: 21 May 2005 21:49
> To: ccielab@groupstudy.com
> Subject: Re: GOOD URL: MQC comparing between bandwidth vs priority command
>
>
> Thanks,
>
> Would you think that this phrase on the Doc could be rephrased?
>
> =========================
> policy-map foo
> class bar
> bandwidth percent 30
> class baz
> bandwidth percent 60
> If you apply this policy to a 1 Mbps link, it means that 300 kbps is
> guaranteed to class bar, and 600 kbps is guaranteed to class baz.
> Importantly, 100 kbps is leftover for class-default.
> ===========================
>
> With:
>
> That is true if applyed to a Frame-Relay, where max-reserved-bandwidth
> command is not supported.
>
> If applyed to ATM or Ethernet, the service-policy command will not be
> accepted because only 75% of the interface bandwidth can be used by
default.
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
> --
> No virus found in this incoming message.
> Checked by AVG Anti-Virus.
> Version: 7.0.322 / Virus Database: 266.11.14 - Release Date: 20/05/2005
>
> --
> No virus found in this outgoing message.
> Checked by AVG Anti-Virus.
> Version: 7.0.322 / Virus Database: 266.11.14 - Release Date: 20/05/2005
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html



This archive was generated by hypermail 2.1.4 : Fri Jun 03 2005 - 10:12:00 GMT-3