FireBrick FB6402, Руководство пользователя

Страница: 66 / 196

Session Handling
49
7.3.3.3. Graphing and traffic shaping
The set-graph and set-reverse-graph attributes cause the session traffic to be graphed, and therefore
possibly be subject to traffic shaping ; they perform the same function as the graph attribute that can be
specified on many different objects, as described in Chapter 10.
Each direction of the final established session can have a graph set. The normal
set-graph
attribute sets
the forward direction graph, and
set-reverse-graph
sets the reverse session graph (remember, sessions
have two sides). Because of this, with
set-graph
, the graph "Tx" direction will be the direction in which
the session was established, and the "Rx" direction is therefore the opposite direction. With
set-reverse-
graph
, the "Tx"/"Rx" directions are swapped compared to using
set-graph
.
There is also an option for
set-graph-source-mac
which causes the session to set a (forward) graph that
is based on the MAC address of the source packet, if from an Ethernet interface. The graph is created if it does
not exist. If
set-graph
is also defined then each new session created also causes the speed settings and long
term shaper parameters to be copied from the named graph (in
set-graph
) to the MAC named graph being
used. This is aimed at management of open WiFi and the like allowing a named shaper to be defined and a
copy of its settings created for each client based on MAC address.
7.3.3.4. Configuring session time-outs
As discussed in Section 7.2.1, each session-table entry has a timer associated with it - this ensures that inactive
sessions are removed from the session-table. Two time-out values are configurable :-
• Initial time-out : this time-out period begins when the first reply packet of the session arrives at the FB6000 ;
it is specified by the set-ongoing-timeout attribute.
• Ongoing time-out : this time-out period begins when each subsequent packet of the session arrives at the
FB6000 ; it is specified by the
set-initial-timeout
attribute.
Note
The actual timeout used is taken from a list of timeouts, and set to the next highest available value. The
status/sessions list shows the timeout in force as well as useful flags for session started, and closed,
and so on.
• The session timeout is actually maintained separately for each direction, and only when the timeout happens
in both directions does the session get dropped. This allows one-sided keep-alive packets as often used by
protocols such as VoIP.
• The ongoing-timeout is set for both directions at once, only when both directions are considered to have
started. The initial forward packet does not count as starting, but a further packet does. An ICMP error
packet does not count to start a session either, and neither does a TCP packet that does not carry the ACK
bit. These subtlties are designed to better handle unresponsive TCP endpoints and spoofed TCP packets even
if allowed through the firewall.
• There are default timeouts for UDP, TCP, ICMP, and other protocols. For UDP the timeout also depends on
the target port with ports 1024 and higher getting a longer timeout as per RFC recommendations.
7.3.3.5. Load balancing
Session tracking rules can include an additional set of share records which define a choice of possible changes
to make when setting up the session. This choice is normally random and based on a weighting for each choice.
This allows various forms of load balancing to be applied. E.g. you could port map to one of a set of web
servers or mail servers.
Each share can also have a profile which can be used to exclude the option from the selection - this is typically
tied to a ping or some other test to confirm the choice makes sense. In the example of web services being load
balanced, a ping based profile could confirm each web server is actually up.