mirror of https://github.com/opnsense/docs
You cannot select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
81 lines
3.5 KiB
ReStructuredText
81 lines
3.5 KiB
ReStructuredText
===============
|
|
Traffic Shaping
|
|
===============
|
|
Traffic shaping (also known as “packet shaping”) is the control of computer network
|
|
traffic in order to optimize or guarantee performance, lower latency, and/or
|
|
increase usable bandwidth by delaying packets that meet certain criteria. More
|
|
specifically, traffic shaping is any action on a set of packets (often called a
|
|
stream or a flow), which imposes additional delay on those packets such that they
|
|
conform to some predetermined constraint (a contract or traffic profile).
|
|
|
|
|
|
.. image:: images/traffic_shaping.png
|
|
|
|
------------
|
|
Introduction
|
|
------------
|
|
Traffic shaping within OPNsense is very flexible and is organized around pipes,
|
|
queues and corresponding rules. The pipes define the allowed bandwidth, the queues
|
|
can be used to set a weight within the pipe and finally the rules are used to apply
|
|
the shaping to a certain package flow. The shaping rules are handled independently
|
|
from the firewall rules and other settings.
|
|
|
|
OPNsense traffic shaping is a reliable solution to limit bandwidth or prioritize
|
|
traffic and can be combined with other functions such as captive portal or high
|
|
availability (CARP).
|
|
|
|
Bandwidth limitations can be defined based upon the interface(s), IP source &
|
|
destination, direction of traffic (in/out) and port numbers (application).
|
|
|
|
Available bandwidth can be shared evenly over all users, this allows for
|
|
optimum performance at all times.
|
|
|
|
Traffic can also be prioritized by adding queues and defining weights. Strictly
|
|
speaking traffic is not really prioritized but applications with a higher weight can
|
|
consume more bandwidth than others when the total available bandwidth is limited.
|
|
|
|
The traffic shaper implementation uses IPFW and dummynet to offer a modern,
|
|
reliable solution with a low cpu footprint.
|
|
|
|
---------------
|
|
Dummynet & ipfw
|
|
---------------
|
|
|
|
Dummynet operates by first using the firewall to classify packets and
|
|
divide them into flows, using any match pattern that can be used in ipfw
|
|
rules. Depending on local policies, a flow can contain packets for a
|
|
single TCP connection, or from/to a given host, or entire subnet, or a
|
|
protocol type, etc.
|
|
|
|
Packets belonging to the same flow are then passed to either of two different
|
|
objects, which implement the traffic regulation:
|
|
|
|
pipe
|
|
A pipe emulates a link with given bandwidth, propagation
|
|
delay, queue size and packet loss rate. Packets are queued
|
|
in front of the pipe as they come out from the classifier,
|
|
and then transferred to the pipe according to the pipe's
|
|
parameters.
|
|
|
|
queue
|
|
A queue is an abstraction used to implement the WF2Q+ (Worstcase Fair
|
|
Weighted Fair Queueing) policy, which is an efficient variant of the
|
|
WFQ policy. The queue associates a weight and a reference pipe to each
|
|
flow, and then all backlogged (i.e., with packets queued) flows linked
|
|
to the same pipe share the pipe's bandwidth proportionally to their
|
|
weights. Note that weights are not priorities; a flow with a lower
|
|
weight is still guaranteed to get its fraction of the bandwidth even if
|
|
a flow with a higher weight is permanently backlogged.
|
|
|
|
In practice, pipes can be used to set hard limits to the bandwidth that a
|
|
flow can use, whereas queues can be used to determine how different flow
|
|
share the available bandwidth.
|
|
|
|
The shaping rules can be defined in the rules section of the traffic shaper.
|
|
|
|
-------------
|
|
Configuration
|
|
-------------
|
|
|
|
Read the how to, here: :doc:`how-tos/shaper`
|