Routing and Mapping rules can include a weighting factor between 0% and
100% which allows the rule to be applied randomly with a specific
chance. This feature can be useful when load sharing traffic between
different ISPs or different servers.
To use the feature you make a number of rules, each with the same
criteria (IP, port/protocol, etc) and each with its required
destination. You then set a weighting on each rule.
For example, if you had two ISPs, you may make two rules (after
subnets) routing to each gateway and NATing your traffic. Each rule may
have a weighting on 50% making half the sessions go via one ISP and
half via the other. If you needed to bias the weighting, e.g. one was a
2Mb link and the other a 500Kb link, you might want to have the rules
weigthed 80% and 20%. If you had four equal rules you could set 25%,
25%, 25% and 25% to give each an equal chance.
When setting up weighted rules you should follow these basic guidelines
:-
Group your rules together. This improves efficience and makes it
easier to read and manage
Ensure the rules all have the same criteria (same IP and ports
and protocol to be checked)
Ensure the weightings add up to at least 100%. E.g. for three
equal rules, use 34%, 34% and 34% (not 33%, 33% and 33%)
Fallback
If you make your rules dependant on a profile, for example a ping
profile that checks that the corresponding server or ISP or router is
working, then you can ensure that only rules which will work are
considered. This is a very useful feature when using load sharing as it
ensures that the load is shared between the working options.
The FireBrick will consider inactive
rules that would otherwise match when trying to find a set of rules
making at least 100%. This means that if you had, say, five options
each of 20% and one was inactive then the remaining four would be
considered equally as if they were all 25%. This means the set of rules
is still applied as long as at least one of the rules is active. If all
of the rules in a set are inactive then later rules are considered as
normal.
Technical Reference
Each rule is considered in turn, and only rules which match the
session are considered. Other rules that do not match have no affect
Where a matching rule is weighted under 100%, then later matching
rules are considered until a total of at least 100% is found
In finding a total of 100%, inactive matching rules are counted
If there are no active rules in the set of matching rules that
are found, then checking continues looking for the next match and
possibly another set
If there are active rules in the set of matching rules, then one
of these is picked randomly based on the weighting of active rules
In the routing rules, the subnet rules are checked as normal, so
you should not make a set of weigthed rules span before and after the
subnet rules
If the end of the rules is reached without a set being coimplete,
e.g. 33%, 33% and 33%, then the rule set is not considered at all
Care should be taken to ensure rules add up to at least 100%.
E.g. 33%, 33%, 33% and then a later 100% match would actually share
traffic 4 ways, 33/199 for each of the first and 100/199 for the last.
For three way, use 34%, 34% and 34%. This makes more than 100% but will
ensure equal sharing. 33%, 33%, and 34% is obviously valid but gives
the last rule a slight bias.
Care should be taken to ensute rules have the same critera,
otherwise some sessions may only see some of the rules in a set and so
the set not complete or the behaviour not be as intended.
In the routing rules, the default rule is not actually in the
table, so does not complete a set. As such an incomplete set before the
default rulle will simply mean all traffic goes via the default rule. This is different to behaviour in previous
versions which would allow, for example, a single 50% rule and
then the default rule. Such a combination would not always use the
default rule.
