The Internal Condition Verificator (ICV) feature allows organizations to develop advanced and customized condition-based configurations.
Common uses for the Internal Condition Verificator include:
Taking action when specific conditions appear such as link failure or link saturation
Modify traffic algorithms based on the time of day
Optimize utilization on burstable links or links with data transfer limits
Reset statistics and counters at a specific date/time
The ICV command describes a test to run and can only have a true or false status based on the results of the test. For example, test whether the second link usage has exceeded 200 Gigabytes or if the current date/time is contained within business hours (mon-fri 9am-5pm).
In a more advanced setup, a number of conditional tests may need to be performed before an action can be taken. ICVs can be chained together with logical operators (and/or) to build comprehensive tests encompassing multiple conditions.
This layer of flexibility also means that there is usually more than one way to configure the wanted set of conditions to achieve the target effect.
Once ICVs are configured and the tests give the expected results, “ICV Action” commands can be used to program the desired effects in the Link LB unit. The “ICV Action” configuration uses the resulting status from an ICV to execute a configuration change when the correct conditions are met. “ICV Actions” can have a wide range of effects, for example:
enabling or disabling a GMAC, change the GMAC threshold values or reset the GMAC statistics.
Another potential use for an “ICV Action” is to alter the ACL lists to modify load balancing strategies. This is done through
“ICV Action groups”. The “ICV Action groups” are not explicitly defined but rather implied by their usage in an “ICV Action”
rule. Their objective is to activate or deactivate ACLs. Marking the relevant ACLs in your configuration is as simple as appending the ICV Action group number to the target ACLs.
NOTE: Deactivated ACLs remain visible in the configuration but stop processing new sessions. Sessions that were already load-balanced prior to an ACL activation/deactivation keep the same control blocks.
4.7.6.2. Syntax for ICV icv [id] [description]
[expression|timer.[trigger_on|trigger_off|state_on|state_off]] [mon-fri|weekend|daily|yyyy/mm/dd|dd] [hh:mm] [hh:mm]
The
[id]
is a numerical identifier. This number will be used as a reference when chaining ICVs or using ICV actions.The
[description]
is an explanation label that will help you remember its purpose (no spaces are allowed in the label).The
[expression|timer.[trigger_on|trigger_off|state_on|state_off]]
section refers to the expression of the condition that will be checked by the Link LB. There are two major types of conditions: state and time.For those based on state, the expression’s syntax will look like this:
vfix:gmac:x.state_down
. The parameters are the index number of the target vfi module (virtual forwared interface) followed by the component and its index number, followed by the relevant status check.The passing from one state to another, known as a trigger, can also be verified as a condition. Unlike the state, a trigger is the infinitely short moment when a condition changes, as opposed to the relatively long duration of that condition.
Time-based expression will look like this:
timer.[trigger_on|trigger_off|state_on|state_off]][mon-fri|weekend|daily|yyyy/mm/dd|dd] [hh:mm] [hh:mm]
The following example is designed to return a “true” value when the current date/time is contained within business hours (mon-fri 9am-5pm).icv 1 business_hours timer.state_on mon-fri 09:00 08:00
The time-based ICVs always use ISO 8601 24h format time (hh:mm). The
trigger_on|trigger_off
is used when you want to make an action happen only once as opposed to a condition that you wish to be continually true or false for the duration of the period. For example, a timed based ICV to add a log entry to the system logs.4.7.6.3. ICV logical concatenation
Multiple ICVs can be chained together to get a precise result out of a conjunction of multiple conditions. The ICV command syntax varies depending on the operator used.
Operator Definition Example
or True if one or the other ICV is true icv 1 one_or_the_other icv:2 or icv:3 and True when both ICVs are true icv 1 both_are_true icv:2 and icv:3
gt Greater than (>) icv 1 totalmb_limit vfi0:gmac:1.total_mb gt 50000 lt Lower than (<) icv 1 low_rtt icv:1 lt 50
ge Greater or equal to (>=) icv 1 totalmb_limit vfi0:gmac:1.total_mb ge 50000 le Lower or equal to (<=) icv 1 low_rtt icv:1 le 50
eq Equal to (=) icv 1 average_in vfi0:gmac:1.usage_avg_in eq 60
You can combine multiple ICV verifications using the above expressions in order to get a precise result based on different situation. For example, you may want to combine the 2 following situations:
1. Is the secondary GMAC currently over 50 GB of download? AND 2. Is the primary link up and running?
For those 2 situations we get those ICV:
1. icv 1 total_download_mb_limit vfi0:gmac:2.total_in_mb gt 50000 2. icv 2 gmac_down vfi0:gmac:1.state_up
Those ICV will each return true or false based on the result of the verifications. A third ICV can be configured to evaluate the results of the first two:
3. icv 3 if_download_limit_reached_AND_primary_link_up icv:1 and icv:2
Then we configure the action based on the conjunction of the two ICV:
1. icv action 1 disable_gmac_2 icv:3 true vfi0:gmac:2.state_disable
Remember that the ICV Actions do not imply their reverse action, the rule above by itself would work perfectly the first time, but then your second GMAC would remain down forever (or until you reboot the Link LB) because there are no rule that says otherwise. Even the condition result becomes “false”, the Link LB will not automatically do the opposite of the
“true” rule. You need to explicitly configure the opposite rule to re-enable the secondary link whenever the condition is false.
2. icv action 2 enable_gmac_2 icv:3 false vfi0:gmac:2.state_enable
As you can see ICV Actions and their ICV Action groups brings flexibility and power to the ICV mechanic.
4.7.6.4. Syntax for ICV Action
Based on the results of the verifications made by the ICVs an ICV Action will apply an action or enable/disable an action group. Here is the syntax:
icv action [id] [description] [icv:id] [true|false] [action]
Let’s have a closer look to each element of that command:
The first element is the
[id]
which is a numerical number that represents a single ICV Action.The
[description]
is a simple explanation label that will help you remember its purpose (no spaces are allowed in the label).The
[icv:id]
specifies which ICV’s results will the ICV Action depend on. If you need to chain together ICVs, only the last ICV will be specified here.The
[true|false]
parameter is used to specify whether to act on a “true” or “false” ICV verification result. It is important to note that the opposite action is never implied and therefore it usually needs to be configured as well. Typically this means the whenever a “true” ICV results in a given action, the “false” result needs to be configured for the opposite action. For example, if you wish to change the load balancing rules during business hours for a given set of special configuration rules, you also need to configure an action to disable those special configuration rules once business hours come to an end.This last part of the command is the actual action to be performed. It may look like this:
vfi0:iagrp:1.state_enable
. This action means that the “ICV action” will enable the “ICV Action group” 1 (iagrp:1
) in the VFI0 module. The result of this group activation is the activation of each configuration line marked withiagrp:1
in the VFI0 configuration. If this is applied to an acl, it means that the acl will become enabled. For the list of all possible actions, you can see the table below.An ICV Action Group (IAGRP) is a set of configuration markers noted in this format: “
iagrp:x
” where “x” is an index number. The groups are not specifically created in the configuration and are simply evoked by their usage in ICV Action rules of ACL rules. Multiple events can trigger the same effect through different actions. If we look at this action:vfi0:iagrp:1.state_enable
, it refers toiagrp:1
which can then be applied to the end of an acl. Here is the acl syntax when attached to itsiagrp:id
:acl nat in +tcp 3 +194.204.1.3/32:0-0 +any:80-80 +nat poolip:1,10 wfa qos:10,20 iagrp:1
This acl nat in +tcp 3 will be applied whenever the ICV Action group 1 is enabled. One or many ICV Actions can alter the state of the ICV Action group. When disabled, the group and related ACLs will remain in the configuration but will not be used by new sessions.
4.7.6.5. ICV/ICV Action Examples
Here are some examples to better understand how the ICV and the ICV Action work together, and how they interact with the configuration.
This first example is a configuration to rate limit the browsing bandwidth during business hours (9AM to 5PM).
The first step would be to create an ICV that will return a “true” result during business hours:
icv 1 business_hours timer.state_on mon-fri 09:00 08:00
This ICV will return “true” (
timer.state_on
) Monday through Friday between 09:00 and 17:00. Note that the expression of time is in this format:[start time (24-hour standard)] [duration in “hours:minutes”]
Therefore, the ICV would be configured with “
09:00
” to express the time at which to start counting and “08:00
” to express the duration of the time window.Here is the ICV Action that will respond to the state of the ICV above:
icv action 1 throttle_down_browsing icv:1 true vfi0:iagrp:1.state_enable icv action 2 unlimited_browsing icv:1 false vfi0:iagrp:1.state_disable
The first ICV Action will look at the returned value of the ICV with id 1 (
icv:1
). When the returned value is true, it will enable iagrp (ICV Action group) id 1 within the vfi0 (vfi0:iagrp:1.state_enable
). As a result, this ICV Action group will in turn enable each configuration line to which it is attached.The second ICV Action rule will also look at the return value of the ICV with id 1 (
icv:1
). When that value is false, it will disable the iagrp (ICV Action group) id 1 within the vfi0 (vfi0:iagrp:1.state_disable
). This ICV Action group will in turn disable each configuration line to which it is attached.With this ICV and its related ICV Action, we can start applying the
iagrp:1
(ICV Action group 1) to different parts of the configuration. The web browsing traffic can be identified with the help of an “acl nat in” rule that will select TCP traffic with a source IP of the firewall on any source port going to any destination IP on port 80. Since the goal is to apply a ceiling (or limitation) to the bandwidth usage, we will use QoS markers to be applied to the relevant “acl nat in” rule. Because this rule will be enabled or disabled based on the state of the iagrp, we will create a second rule to catch the traffic whenever the rate-limiting ACL is disabled. The first ACL will rate limit the bandwidth with QoS during business hours with theiagrp:1
marker, and the second one with no QoS and no iagrp:1 marker. Because ACLs are always read by the Link LB from top to bottom, the second rule will not be used whenever the first one is enabled.acl nat in +tcp 3 +194.204.1.3/32:0-0 +any:80-80 +nat poolip:1,10 etfa qos:10,20 iagrp:1
acl nat in +tcp 4 +194.204.1.3/32:0-0 +any:80-80 +nat poolip:1,10 etfa
qos 10 tc_htb 1/1,1024/1024 gmac:1 catchall_qos_gmac1 qos 20 tc_htb 1/1,768/768 gmac:2 catchall_qos_gmac2
4.7.6.6. ICV notes and considerations
The ICV can work across multiple VFI if needed. As an example, if you have 2 VFI, you can change the rules in vfi0 based on the state of the gmac in vfi1.
Also, it is possible to use ICV to monitor the state of exported data in a GEO environment. For example, you can apply a change based on the state of a gmac shadow located at the other site.
Another example in a GEO environment is to use ICVs to determine the ultimate destination of inbound traffic. Depending on the state of an ISV, the Link LB can change the “acl nat out” rules in order to select the best possible destination. In other words, if all the internet links at the primary site are down but the servers are still running, we can receive traffic at the DR site for those servers and send it over to the primary site through a WAN link. However, if the primary servers are down as well, then we can send the incoming traffic to the backup servers at the DR site.
IMPORTANT: When using time based ICV, always ensure that your NTP configuration is complete and pointing to a valid NTP server.
4.7.6.7. ICV Tables
The following tables are designed to help define the different logic tests that can be applied and also the actions that can be taken based on the results of those tests.
This first table contains all the syntax and examples for the ICV conditions.
Expression (where x is an ID) Definition Type of value returned
Example
icv:x True when
referenced ICV is true
True or false icv 1 reference_icv vfi0:gmac:1.state_up icv 2 depends_on_icv_1 icv:1
True or false icv 1 current_up vfi0:gmac:1.state_up
vfix:gmac:x.state_down True while GMAC is down
True or false icv 1 current_down vfi0:gmac:1.state_down
vfix:gmac:x.total_mb Holds the current total data transferred for other ICVs to reference
Integer icv 1 totalmb_var vfi0:gmac:1.total_mb icv 2 high_totalmb icv:1 gt 50000
Expression (where x is an ID) Definition Type of value
Integer icv 1 in_mb_var vfi0:gmac:1.total_in_mb icv 2 high_in_mb icv:1 gt 25000
vfix:gmac:x.total_out_mb Holds the current uploaded data for other ICVs to reference
Integer icv 1 out_mb_var vfi0:gmac:1.total_out_mb icv 2 high_out_mb icv:1 gt 25000
vfix:gmac:x.total_mb [operator] [value] True when total data matches
“value” as per operator
True or false icv 1 totalmb_limit vfi0:gmac:1.total_mb gt 50000
vfix:gmac:x.total_in_mb [operator] [value] True when downloaded data matches “value”
as per operator
True or false icv 1 inmb_limit vfi0:gmac:1. total_in_mb gt 25000
vfix:gmac:x.total_out_mb [operator] [value] True when uploaded data matches “value”
as per operator
True or false icv 1 outmb_limit vfi0: gmac:1.total_out_mb gt 25000
vfix:gmac:x.rtt Is a
value-holding variable for other ICVs to reference
Integer icv 1 rtt_var vfi0:gmac:1.rtt icv 2 high_rtt icv:1 gt 200 icv 3 low_rtt icv:1 lt 50 vfix:gmac:x.rtt [operator] [value] True when RTT
matches “value”
as per operator
True or false icv 1 rtt_limit vfi0:gmac:1.rtt gt 299
vfix:gmac:x.usage_in Holds the current inbound usage (%) for other ICVs to reference
Integer icv 1 usage_in_var vfi0:gmac:1.usage_in icv 2 high_usage_in icv:1 gt 75
icv 3 low_usage_in icv:1 lt 25
vfix:gmac:x.usage_out Holds the current outbound usage (%) for other ICVs to reference
Integer icv 1 usage_out_var vfi0:gmac:1.usage_out icv 2 high_usage_out icv:1 gt 75
icv 3 low_usage_out icv:1 lt 25
vfix:gmac:x.usage_avg_in Holds the average inbound usage (%) for other ICVs to reference
Integer icv 1 average_in_var vfi0:gmac:1.usage_avg_in icv 2 high_average_in icv:1 gt 75
icv 3 low_average_in icv:1 lt 25
vfix:gmac:x.usage_avg_out Holds the
Integer icv 1 average_out_var vfi0:gmac:1.usage_avg_out icv 2 high_average_out icv:1 gt 75
icv 3 low_average_out icv:1 lt 25
vfix:gmac:x.usage_in [operator] [value] True when the True or false icv 1 usage_in vfi0:gmac:1.usage_in gt 75
Expression (where x is an ID) Definition Type of value vfix:gmac:x.usage_out [operator] [value] True when the
upload usage (%) reaches the
“value” as per operator
True or false icv 1 usage_out vfi0:gmac:1.usage_out gt 75
vfix:gmac:x.usage_avg_in [operator] [value] True when the average download usage (%) reaches the
“value” as per operator
True or false icv 1 average_in vfi0:gmac:1.usage_avg_in gt 60
vfix:gmac:x.usage_avg_out [operator]
True or false icv 1 average_out vfi0:gmac:1.usage_avg_out gt 60
vfix:isv:x.state_up True when the specified ISV is up
True or false icv 1 isv_check vfi0:isv:1.state_up
vfix:isv:x.state_down True when the specified ISV is down
True or false icv 1 isv_check vfi0:isv:1.state_down
vfix:spath:x.state_up True when the specified SitePath is up
True or false icv 1 sitepath_check vfi0:spath:1.state_up
vfix:spath:x.state_down True when the specified SitePath is down
True or false icv 1 sitepath_check vfi0:spath:1.state_down
vfix:spath:x.rtt_avg Holds the current
Integer icv 1 current_rtt vfi0:spath:1.rtt_avg icv 2 high_rtt_average icv:1 gt 299 icv 3 low_rtt_average icv:1 lt 61
vfix:spath:x.rtt_avg [operator] [value] True when current average RTT for specified SitePath reaches
“value” as per operator
True or false icv 1 current_rtt vfi0:spath:1.rtt_avg gt 299
This table focuses on the time-based logic tests.
Expression Definition Example(s)
Expression Definition Example(s) timer.state_on [value] [start time] [duration] True while the current date/time is
within the specified “value”, start
icv 1 business_hours timer.state_on mon-fri 09:00 08:00
icv 2 weekend_nights timer.state_on weekend 19:00 08:00
icv 3 lunchtime timer.state_on daily 12:00 01:00
icv 4 saturday_morning timer.state_on sat 07:00 05:00
icv 5 specific_day timer.state_on 2009/12/31 00:00 24:00
icv 6 month_end timer.state_on 27 08:00 01:00
timer.state_off [value] [start time] [duration] False while the current date/time is within the specified “value”.
Possible values are the same as above.
icv 1 business_hours timer.state_on mon-fri 09:00 08:00
icv 2 exception timer.state_off thu 09:00 08:00
icv 3 logic_test icv:1 and icv:2 timer.trigger_on [value] [start time] True for the instant when the
date/time reaches the specified
“value”.
icv 1 monthly_trigger timer.trigger_on 01 00:00
timer.trigger_off [value] [start time] False for the instant when the date/time reaches the specified
“value”.
icv 1 inverted_trigger timer.trigger_on daily 00:00
Here is the ICV action table.
Action (where x is an ID) Effect Example
vfix:gmac:x.state_disable Disables the specified GMAC icv 1 totalmb_limit vfi0:gmac:1.total_mb gt 50000
icv action 1 disable_gmac1 icv:1 true vfi0:gmac:1.state_disable
vfix:gmac:x.state_enable Enables the specified GMAC icv action 1 enable_gmac1 icv:1 true vfi0:gmac:1.state_disable
vfix:gmac:x.stat_reset Resets the statistics for the specified GMAC
icv action 1 reset_gmac1 icv:1 true vfi0:gmac:1.stat_reset
vfix:spathgrp:x.stat_reset Resets the statistics for the specified SitePath group
icv action 1 reset_spathgrp1 icv:1 true vfi0:spathgrp:1.stat_reset
vfix:qos:x.stat_reset Resets the statistics for the specified QoS instance
icv action 1 reset_qos1 icv:1 true vfi0:qos:1.stat_reset
vfix.stat_reset Resets the statistics for the specified VFI
icv action 1 reset_vfi0 icv:1 true vfi0.stat_reset
icv action 1 reset_vfi0 icv:1 true vfi0.stat_reset