Table of Contents
The FB6000 includes traffic shaping functionality that allows you to control the speed of specific traffic flows through the FB6000. The FB6000 also provides graphing functionality, allowing specific traffic flows to be plotted on a graph image (PNG or SVG format) that the FB6000 generates. Within the FB6000, traffic shaping and graphing are closely associated, and this is reflected in how you configure traffic shaping - in order to be able to perform traffic shaping, you must first graph the traffic flow.
Several objects in the FB6000's configuration allow you to specify the name of a graph, by setting the value of the
graph
attribute. This causes the traffic flow that
is associated with that object (a firewall rule, an interface, or whatever the attribute is attached to) to be recorded on a graph with the specified name.
For connections that have a defined state, such as a PPP link, the graph will also show the link state history. Other information, such as packet loss and latency
may also be displayed, depending on whether it can be provided by the type of object you are graphing.
For example, the XML snippet below shows the graph
attribute being set on an interface
. As soon as you
have set a graph
attribute (and saved the configuration), a new graph with the specified name will be created.
<interface name="LAN" port="LAN" graph="LAN">
The graph is viewable directly from the FB6000 via the web User Interface - to view a graph, click the "PNG" or "SVG" item in the "Graphs" menu. This will display all the graphs that are currently configured - it is not currently possible to show a single graph within the web User Interface environment.
It is possible to access the graph data in many ways, using the URL to control what information is shown, labels, and colours, and also allowing graphs to be archived. See Appendix I for more details.
You may find images shown for graph names that are no longer specified anywhere in the configuration. Over time, these graphs will disappear automatically.
Alternatively, the underlying graph data is available in XML format, again via the FB6000's built-in HTTP server. The XML version of the data can be viewed in the web User Interface by clicking the "XML" item in the "Graphs" menu, and then clicking on the name of the graph you're interested in.
Both directions of traffic flow are recorded, and are colour-coded on the PNG image generated by the FB6000. The directions are labelled "tx" and "rx",
but the exact meaning of these will depend on what type of object the graph was referenced from - for example, on a graph for an interface
,
"tx" will be traffic leaving the FB6000, and "rx" will be traffic arriving at the FB6000.
Each data point on a graph corresponds to a 100 second interval ; where a data point is showing a traffic rate, the rate is an average over that interval. For each named graph, the FB6000 stores data for the last 24 hours.
Specifying a graph does not itself cause any traffic shaping to occur, but is a pre-requisite to specifying how the associated traffic flow should be shaped.
Graphing relies on the FireBrick's internal clock and so graphs will not work reliably if the clock is not set for any reason. However, you can still set an object's graph
attribute and use it for traffic shaping.
Once you have graphed a (possibly bi-directional) traffic flow, you can then also define speed restrictions on those flows. These can be simple "Tx" and "Rx" speed limits or more complex settings allowing maximum average speeds over time.
You define the speed controls associated with the graphed traffic flow(s) by creating a shaper
top-level object. To create or edit a shaper
object
in the web User Interface, first click on the "Shape" category icon. To create a new object, click the "Add" link. To edit an existing
object, click the appropriate "Edit" link instead.
The shaper
object specifies the parameters (primarily traffic rates) to use in the traffic shaping process, and the shaper
is associated with the
appropriate existing graph by specifying the name
attribute of the shaper
object to be the same as the name of the graph.
You can define a shaper
object and set the speed controls for that shaper, and then define the
graph
attribute on something, e.g. an interface, to apply that shaper to the interface.
It is also possible, in most cases, to simply set a speed
attribute on some object. This
creates an un-named shaper (so no graph) which has the specified speed for egress (tx). This is unique to that object
unlike named shapers which are shared between all objects using the same named shaper.
It is also possible to set graph
and speed
attributes to create a named
shaper with the specified speed, without having to create a separate shaper
object.
If you set a graph
attribute without a speed
attribute or creating a
shaper
object then that simply creates a graph without traffic shaping. Multiple objects can share
the same graph.
Graphs can sometimes be created automatically and may have speeds applied. For L2TP sessions the circuit ID (which may be overridden by RADIUS auth responses) is used to make a graph for the session.
If defining a shaper using the shaper
object there are a number of extra options which
allow a long term shaper to be defined. A long term shaper is one that changes the actual speed applied dynamically
to ensure a long term usage level that is within a defined setting.
The key parameters for the long term shaper are the target speed (e.g. tx
), the
minimum speed (e.g. tx-min
) and maximum speed (e.g. tx-max
).
The target speed is the maximum rate that should apply over a long term, but actual speed is set dynamically
between min and max rates.
The rate is initially set to the maximum. Actual usage below the target builds up credit. This credit is limited to allow a defined minimum burst time at the maximum rate. So if not used for a while the maximum rate can be used for the minimum burst time. However continued use at more than the target will accumulate over usage.
Once this credit is used up the rate starts to drop. It will drop all the way to the minimum set if necessary.
Once the over usage is cleared, but less usage or usage capped to below the target rate, the rate increases to the target rate.
Once a further credit is accumulated by lowere usage that target, and this is at a level to allow the minimum burst time at maximum rate, the rate increases to the maximum rate again.
Shapers can be shared between FireBricks with a common broadcast domain.
The interface to broadcast and listen on for sharing is set via the share-interface
setting in the global cqm
options.
Once that is configured then setting the share
option on a shaper
will combine its state with that of other FireBricks when calculating any damping required.
Shared shapers are identified in the broadcast domain by their name
, so this must be the same on all FireBricks participating in the share.