- A virtual community of network engineers
 Home  BookStore  StudyNotes  Links  Archives  StudyRooms  HelpWanted  Discounts  Login
RE: FRTS with PQ/CBWFQ!!! posted 09/02/2004
[Chronological Index] [Thread Index] [Top] [Date Prev][Date Next] [Thread Prev][Thread Next]


Regarding the first part of your posting.....

If you apply a service-policy directly to the physical interface then the 75/25 rule (max-reserved-bandwidth) applies. However, as soon as you apply frame relay traffic shaping and apply the service policy via a frame relay map-class the rules change and the 75/25 constraint no longer applies.

In FRTS, the "available bandwidth" = minCIR which by default is half the CIR which by default is 56k. However you have specified a minCIR of 768k. So the available bandwidth is 768k - all of it!

Now you have also allocated two class-maps having reservations of 600 & 168 = 768 which is ALL of the "available bandwidth". So if under congestion PRUEBA1 needs ALL of its 600k and PRUEBA2 needs ALL of its 168k then there is nothing left for the class-default and you are going to have problems!

Given your specifications you should not allocate more than about 75% to the classes so that the class-default has some bandwidth available for L2 headers, etc.



-----Original Message-----
From: Sergio Jimenez Arguedas [mailto:sejimenez@xxxxxxxxx]
Sent: 01 September 2004 18:29
Subject: FRTS with PQ/CBWFQ!!!

Hi Group,

I have a question about FRTS with PQ/CBWFQ,

I know that I can use 75% of the bandwith of the interface when I use
PQ/CBWFQ, By default the class-default take 25%.

But in FRTS with PQ/CBWFQ.....

What happend if before the class-default, I apply the following class
PRUEBA2 that matches ALL

policy-map PRUEBAS
  class PRUEBA1
    priority 600
  class PRUEBA2
    bandwith 168
  class class-default

class-map match-all PRUEBA1
  match access-group 100
class-map match-all PRUEBA2
  match access-group 101
access-list 100 permit ip any host
access-list 100 permit ip any host
access-list 101 permit ip any any

interface Serial0.1 point-to-point
 bandwidth 1544
 ip address
 frame-relay class FRQoS
 frame-relay interface-dlci 110
  load-interval 30

map-class frame-relay FRQoS
 frame-relay adaptive-shaping becn
 frame-relay fecn-adapt
 frame-relay cir 768000
 frame-relay bc 76800
 frame-relay be 76800
 frame-relay mincir 768000
 service-policy output PRUEBAS

I know that I can not use more than the MINCIR in the PQ and Fair queues...

So in this configuration, How much bandwith does the class-default have?

....Another question..???

In a normal configuration in the Physical interface... If I have a link of
1Mbps, So I have 75% to redistribute between the queues, What happen in the
moment of the congestion If I only use 50% in the queues??? What happen with
the 25%???

50% class 1, 2, 3
25% class-default

Also, If you are going to transmit VoIP over FrameRelay(PVC of voice and
data)... Cisco says that you need to configure the BE=0. So What happen if
the Service provider have the following parameters:


So the FRTS is:

frame-relay cir 768000
frame-relay mincir 768000
 frame-relay bc 76800
 frame-relay be 0

I use a TC of 100ms, Do you think I need to use a delay of 10ms...

frame-relay cir 768000
frame-relay mincir 768000
 frame-relay bc 7680
 frame-relay be 0

What happen if I use the following FRTS with a TC of 100ms:

frame-relay cir 768000
frame-relay mincir 768000
 frame-relay bc 76800
 frame-relay be 76800

Can somebody help me please??? I really apreciated your help!!!


Sergio Jiminez Arguedas

Please help support GroupStudy by purchasing your study materials from:

Subscription information may be found at:

The information contained in this email is confidential and is intended for the recipient only. If you have received it in error, please notify us immediately by reply email and then delete it from your system. Please do not copy it or use it for any purposes, or disclose its contents to any other person or store or copy this information in any medium. The views contained in this email are those of the author and not necessarily those of Lorien plc.

Thank you for your co-operation.