• Home
• News
• About FireBrick
• Products

• FireBrick FB2500
• FireBrick FB2700
• FireBrick FB6000

• Legacy Products
• Buy FireBrick
• Contact Us
• Support
• Reseller Area
• Press Information

FireBrick FB6000

Control profiles

The FireBrick has a means to control various aspects of the operation automatically using profiles. These profiles are simple on/off switches which are based on a range of different tests and criteria and automatically updated. Many aspects of the operation of the FireBrick can be linked to a profile allowing it to be enabled or disabled.

Profile config

The config for a profile consists of a <profile.../> object with a unique name="...". The profile object has various attributes defining how the profile works and what is tested.

Most other objects in the config have a profile="..." allowing a named profile to be referenced. In most cases, if the referenced profile is off then it is like the object referencing it was not in the config. Some objects are more sophisticated, e.g. vrrp will work on lower priority when the profile is inactive. The exact effect of the profile is documented for each feature that uses them.

Timeout and recovery

The profiles work by doing a test, typically every second. However the testing can be controlled by interval="...", timeout="..." and recovery="...". The interval defines how often the test is done. The timeout defines how long the test has to fail before the profile will switch off. The recovery defines how long the profile must past before a profile switches back on.

The rules are applied slightly differently to some aspects. The interval does not affect tests that are dependant on other profiles, manually set, or based on date/time, as these are tested every second. Also, the timeout does not apply to the profile going off due to dependant profiles, manually set or date/time profiles and these turn off the profile immediately.

Manual control

The set="true" or set="false" profile attribute forces the state of the profile on or off regardless of all other tests. This is tested first and do not depend on the interval="..." setting.

Interdependent profiles

A profile can depend on another profile. There are there attributes and="...", or="..." and not="..." reference other profiles by name. if any of the profiles listed in or="..." are active, then the profile is active. Otherwise, if any of the profiles listed in and="..." are inactive then the profile is immediately inactive. Finally, if the profile referenced in not="..." is active then this profile is immediately inactive. Dependant profiles are tested after manual controls, and do not depend on the interval="..." setting.

Note that if you have no tests then the profile normally passes as not tests fail. A special case is if you only have an "or" test and none of the or profiles have passed then the profile fails.

Time and date

A profile can have one or more <time.../> object with lists days of the week and time ranges in the day. You can also have one or more <date.../>. If any time is specified then the current time has to be in range else the profile is immediately inactive. Similarly if any date is listed then the current date/time has to be within range or the profile is immediately inactive. Date and time tests are done after the dependant profile tests and do not depend on the interval="..." setting.

If the time is not known then date and time controls are assumed to be in/out of profile depending on initial state setting (and invert setting) so that they would not change initial state - however other tests can cause state changes.

Other tests

Other tests are done at intervals, and must fail for a period (timeout) or pass for a period (recover) to change the profile state. These tests are done after date/time tests are done.

Mixing it up

Whilst typically a profile will be used for one type of test, such as ping, or time, it is quite possible to combine many tests. Generally, as soon as a test fails, the profile fails (though manual setting and the or="..." setting are exceptions to this rule. The profile has a logging option which causes state changes to be logged to syslog.