Table of Contents
The FB2700 includes traffic shaping functionality that allows you to control the speed of specific traffic flows through the FB2700. The FB2700 also provides graphing functionality, allowing specific traffic flows to be plotted on a graph image (PNG or SVG format) that the FB2700 generates. Within the FB2700, 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 FB2700'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 FB2700 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 K 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 FB2700'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 FB2700. 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 FB2700, and "rx" will be traffic arriving at the FB2700.
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 FB2700 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 what is normally used if nothing else is set, but if a min and max are set then the
shaper will actually use the max speed normally.
However, if the usage exceeds the target speed then this is considered to be bursting and this continues until the average speed since the bursting started drops below the target speed.
When bursting, a time is intially allowed with no change of speed (e.g. tx-min-burst
)
and after that the speed drops. This can be automatic, or using a rate of drop per hour (e.g. tx-step
).
The rate will drop down to the defined minimum speed.
Once the average, since bursting started, drops below the target and the restrictions are lifted, returning to the maximum speed. If the minimum speed is below the target speed then this will happen eventually even if the link is used solidly at the maximum it is allowed. If the minimum is at the target or higher then the usage will have to drop below the target for a time before the average speed drops low enough to restore full speed.
The overall effect of this means that you can burst up to a specified maximum, but ultimately you cannot transfer more than if the target speed had been applied the whole time.
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.