Introduced : BIG-IP_v11.3.0
Adds firewall rules to the specified virtual servers. Note that the abilities to add more than one rule or, especially, to add partial rules and to build them up introduce a need for best practices: (1) introduce the rule or rules initially disabled (using the states parameter) and enable them (or set them as scheduled) as a whole when you have them complete or (2) use transactions (see System::Session::start_transaction) to avoid accidentally putting partial rules or incomplete rule sets into place.


    in String [] virtual_servers,
    in String [] [] rules,
    in Common__FirewallRulePlacement [] [] placements,
    in FirewallRuleAction [] [] actions,
    in FirewallRuleState [] [] states


Parameter Type Description
virtual_servers String [] The virtual servers to modify.
rules String [] [] The firewall rules to add to the virtual servers, with one nested list of rules for each virtual server. A firewall rule may not be named “first” or “last”; see the documentation for FirewallRulePlacement.
placements FirewallRulePlacement [] [] The placement (ordering) information for the firewall rules, with one nested list of rule placements for each virtual server. Placements have a conceptual form like the following: place the new rule after existing rule “bar”. The firewall rules have numeric order whether you use a numeric placement to place them or not; if you add rules using non-numeric placements, the firewall rules may be renumbered by the system to accomodate your new rules. It’s most straightforward to choose to manage rules by using names or numeric order but not mix the two ways. The order for multiple rules added at a time is internally unspecified; if that is inconvenient, add them with each rule placed after a target rule of the one before it (and the first placement naming an existing element, or before or after the first or last element of the list), take advantage of the convenience which does this automatically, add them with numeric ordering (possibly adjusting the order separately to avoid duplicates), or add them one at a time. As conveniences: if the placements array is empty or contains a nested empty list, the system places a new rule or rules after the last element (or end) of any existing list. If the placements array has exactly one element in the nested array, then that placement is taken as the root for adding multiple rules (that is, in this case the system will generate placements sequentially for you if you do not specify them). Example: rules=”rule1”,”rule2””>”rule3”,”rule4”,”rule5””>”rule1”,”rule2”, , placements=”rule3”,”rule4”,”rule5”, placements=, `{after,"bar"}">"rule3","rule4","rule5" <>`__, placements=, {after,”bar”}”>”rule3”,”rule4”,”rule5”, placements=[[{after,”bar”}, [ means add rule1 and rule2 (in order) after existing rule “bar” in the first virtual server’s rule list, and add rule3 through rule5 in order after the end of second virtual server’s rule list. (It is as if you specified placements=[[{after,”bar”},{after,”rule1”}”>”>{after,”bar”}”>”rule3”,”rule4”,”rule5”, placements=[[{after,”bar”}

The BIG-IP API Reference documentation contains community-contributed content. F5 does not monitor or control community code contributions. We make no guarantees or warranties regarding the available code, and it may contain errors, defects, bugs, inaccuracies, or security vulnerabilities. Your access to and use of any code available in the BIG-IP API reference guides is solely at your own risk.