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.
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.
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.
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.
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.
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 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.
|fb105||Lists fb105 tunnels by name. If all of them are down then the profile is inactive.|
|ppp||Lists PPPoE client endpointds by name. If all of them are down then the profile is inactive.|
|vrrp||Lists VRRP objects by name. If all of them are not master (for IPv4 and IPv6) then the profile is inactive.|
|route||List of IP addresses. If none of them are routeable then the profile is inactive. Routrable tests for local devices includes testing if ARP/ND responds.|
|ping||A <ping.../> object defining and endpoint to ping. If the endpoint fails to respond the profile is inactive.|
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.
|Yes||FB6000, all models|
|Yes||FB2700, all models|
|Yes||FB2500, all models|