FireBrick Weighted Guide

Weighted rules

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.