speed limit according to the installed bandwidth on the uplink port

[fractal90]

I have several branches with channels of different bandwidth, I hang the bandwidth parameter on the uplink port for monitoring, can the same parameter be used in policy or shaper to allocate speed to the necessary applications? let's say there is 300 mbps on the port and start from this speed?

[Flavio Miranda]

Hi

 You can do many things on this direction but you need to be more specific. For example, which device do you have?

[fractal90]

we have isr4331

[Joseph W. Doherty]

Bandwidth statements, in policy classes, in CBWFQ versions for some time, can use percentages based on what the policy believes the interface bandwidth is, such as what's set using an interface bandwidth statement.

I think (??) some of the most recent CBWFQ versions also support percentages on shapers and policers (but I'm unsure).

What you could do, is when typing the command line for a policer or shaper, see what options appear for command continuation/completion.

[JimWicks]

The bandwidth command on an interface does not actually do anything, it's there as an indication for routing protocols such as EIGRP which use the interface-bandwidth as one of their composit metrics, also some NMS platforms will tke that value for use when calculating link utilization percentage.

If you want to share traffic between different classes on your uplink within your 300Mb/s bandwidth budget then you will need to use a hierarchical QoS policy where the parent level of the policy shapes to the aggregate 300Mb/s and then the child-policy queues the different classes to allocate their "share" of the available bandwidth.  So would look something like the following (excuse the syntax, it's just an indication of the method and not to be pasted directly into the CLI).

policy-map child-policy

     class  gold       <-- you will need to define the class-maps to match the required traffic-type for each

         police 50mbps

         priority level 1

     class silver

         bandwidth-remaining 40   

     class bronze

         bandwidth-remaining 30   (you can define "bandwidth" or "bandwidth-remaining" but they all give a ratio to the scheduler)

     <there is an implicit class-default here which is allocated any bandwidth not used by the above classes>

policy-map parent-shaper

   class class-default                    <-- you can only define a class-default at this level in the policy

      shape-average 300mbps       <-- limits "everything" as it sits within class-default

        service-policy child-policy   <-- this now allocates the traffic classes within the overall shaped-rate

interface gig/0/0/0      <-- obviously your uplink interface needs enough b/w to accomodate the shaper-rate

    ip address 1.2.3.4 255.255.255.252

    service-policy output parent-shaper    <-- policy applied in the egress direction to limit the traffic to 300mbps

[Joseph W. Doherty]

"policy-map parent-shaper

class class-default <-- you can only define a class-default at this level in the policy"

I believe that's technically incorrect, although for what you're trying to explain, your parent policy (normally) would/should be as you show.

"bandwidth-remaining 30 (you can define "bandwidth" or "bandwidth-remaining" but they all give a ratio to the scheduler)"

Technically correct, as in your example your silver and bronze classes would share bandwidth, between just those two classes, in the ratio of 4:3 (assuming both wanted, at least, "their defined allocation" of bandwidth).  However, one should note, there can be a large difference in the effect of "bandwidth percentage #" vs. "bandwidth-remaining percentage #" (when number is same, depending on what percentages are being calculated against.

"<there is an implicit class-default here which is allocated any bandwidth not used by the above classes>"

Although there is always a class-default, whether implicit or explicit (BTW, it acts as a class for "none-of-the-above"), I've never seen it documented what's its bandwidth dequeuing ratio is when class not explicitly defined with a bandwidth statement.  If you do have a reference to such documentation, please provide a link.  (NB: my knowledge of CBWFQ is a bit dated, so it might now be so documented.)

[JimWicks]

Back in the "olden days" of traditional IOS, I remember being told that an un-defined class-default in MQC policy was defaulted to a value = 1 and that flavour was dependent on the other classes because you can't mix "bandwidth" and "bandwidth-remaining" in the same MQC policy (so either bandwidth=1 or bandwidth-remaining=1 within the class-default).........The value 1 was used because if it was zero then there would never be any tokens allocated to the scheduler for that class and so all packets would end up being dropped all the time.

I would guess that the bqs function in the newer IOS-XE boxes has a similar operation, however I have done a bit of digging and I cannot locate any documentation that explicitly states either the legacy IOS or the contemporary IOS-XE behaviour.