Shaping

Shaping causes a traffic flow to conform to a bandwidth value referred to as the shaping rate. Excess traffic beyond the shaping rate is queued inside the shaper and transmitted only when doing so does not violate the defined shaping rate.

A shaper is implemented using a token bucket. If a packet fulfills the bandwidth/burst specification, it can pass. Otherwise, the packet is kept in a delay queue until it fulfills the bandwidth/burst specification. As soon as the delay queue is full, the incoming packets are dropped.

Shaping is applied to egress traffic on interfaces.

Note

The interface cannot be a loopback interface.

../../../_images/shap_design.svg

Shaper templates

Shaper templates are created in the global qos context with the shaper command. They can then be referenced by a physical interface for egress.

Enter the global qos context and create a shaper:

vsr running config# qos
vsr running qos#
vsr running qos# shaper shaper1
vsr running shaper shaper1#! bandwidth 1G
vsr running shaper shaper1# burst 2K
vsr running shaper shaper1# queue-size 128
vsr running shaper shaper1# ..
vsr running qos#

Interfaces that use this shaper will have their frame bandwidth shaped to 1 Gbps, with bursts up to 2 Kbytes. Frames that would cause this profile to be exceeded will be temporary saved in a delay queue to be sent later to fulfill the frame rate limitation. When the delay queue is full, the incoming frames are dropped.

By default the size of the delay queue is 256 packets. It can be changed via the queue-size command.

vsr running config# qos
vsr running qos#
vsr running qos# shaper shaper1
vsr running shaper shaper1# queue-size 128
vsr running shaper shaper1# ..
vsr running qos#

Note

If a scheduler and a shaper template are applied on an interface, the queue size of the shaper template is ignored. In this case the different queues of the scheduler are also used as delay queues.

In order to take into account bytes added to the frame size by the layer 1 level (by default 24 bytes for Ethernet CRC, Internet Frame Gap and preamble), you can specify an amount of bytes to add to the frame size in rate and burst calculations via the layer1-overhead command.

vsr running config# qos
vsr running qos#
vsr running qos# shaper shaper2
vsr running shaper shaper2#! bandwidth 10G
vsr running shaper shaper2# layer1-overhead 24
vsr running shaper shaper2# ..
vsr running qos#

Review the QoS configuration:

vsr running qos# show config
qos
    shaper shaper1
        bandwidth 1G
        burst 2K
        queue-size 128
        layer1-overhead 0
        ..
    shaper shaper2
        bandwidth 10G
        queue-size 256
        layer1-overhead 24
        ..
    ..

The same settings can be applied using the following NETCONF XML configuration:

vsr running qos# show config xml absolute
<config xmlns="urn:6wind:vrouter">
  <qos xmlns="urn:6wind:vrouter/qos">
    <shaper>
      <name>shaper1</name>
      <burst>2000</burst>
      <layer1-overhead>0</layer1-overhead>
      <queue-size>128</queue-size>
      <bandwidth>1000000000</bandwidth>
    </shaper>
    <shaper>
      <name>shaper2</name>
      <layer1-overhead>24</layer1-overhead>
      <queue-size>256</queue-size>
      <bandwidth>10000000000</bandwidth>
    </shaper>
  </qos>
</config>

Configuring a shaper on an interface

Shapers are configured in the qos context of interfaces.

Enter the qos context of the eth0 physical interface:

vsr running config# vrf main
vsr running vrf main# interface physical eth0
vsr running physical eth0# qos

Configure shaper2 as the rate limiter for egress traffic:

vsr running qos# egress rate-limit shaper shaper2
vsr running qos# ..
vsr running physical eth0#

Review eth0 configuration:

vsr running physical eth0# show config nodefault
physical eth0
    (...)
    qos
        egress
            rate-limit
                shaper shaper1
                ..
            ..
        ..
    ..

Commit the configuration:

vsr running physical eth0# commit
Configuration committed.
vsr running physical eth0# /
vsr running config#

Review the QoS state of the interface:

vsr running config# show state vrf main interface physical eth0
physical eth0
    qos
        egress
            rate-limit
                shaper
                    bandwidth 10G
                    burst 125M
                    queue-size 256
                    layer1-overhead 24
                    stats
                        pass-packets 0
                        drop-packets 0
                        ..
                    ..
                ..
            ..
        ..
    ..
..

The same settings can be applied using the following NETCONF XML configuration:

vsr running config# show config xml absolute
<config xmlns="urn:6wind:vrouter">
  <vrf>
    <name>main</name>
    <interface xmlns="urn:6wind:vrouter/interface">
      <physical>
        <name>eth0</name>
        (...)
    </qos>
        <qos>
          <egress>
            <rate-limit>
              <shaper>shaper1</shaper>
            </rate-limit>
          </egress>
        </qos>
      </physical>
    </interface>
  </vrf>
</config>

Protecting critical control plane traffic

When configuring a simple shaper on the output of an interface that is constantly fed with traffic over the limit, a part of the traffic is necessarily dropped. There is a risk that critical control plane traffic be dropped.

In order to protect this critical control plane and preserve it from being dropped, a simple QoS scheduler and traffic filter should be configured in addition to the shaper. Please refer to chapter Shaping the output while protecting critical control plane traffic.