create policy with curl

LTM policy is fairly nested. First, it consists of policy itself and one or more rules. And a rule consists of one or more condition spec and action spec.

Creating an empty (no rule) draft policy is fairly straight forward.

curl -sku admin: https:///mgmt/tm/ltm/policy \
  -X POST -H "Content-type:application/json" \
  -d '{"name":"/Common/Drafts/TestPolicy", "strategy":"first-match"}'

Then, you can add an empty rule named

rule

to the policy (

/Common/Drafts/TestPolicy

😞

curl -sku admin: https:///mgmt/tm/ltm/policy/~Common~Drafts~TestPolicy/rules \
  -X POST -H "Content-type:application/json" \
  -d '{"name":"rule"}'

The above steps can be put into one single JSON body (POST it to

/mgmt/tm/ltm/policy

😞

{
  "name": "/Common/Drafts/TestPolicy",
  "strategy": "/Common/first-match",
  "rules": [
    {
      "name": "rule"
    }
  ]
}

Note that the value of the

rules

field is an array (list), hence

[]

. The array must contain a number of objects ({...}) each having a unique name: e.g.,

[ { rule1 }, { rule2 }, ... ]

.

Each rule contains one or more conditions and actions. They are both represented as array. So, the JSON body for creating a policy with empty rule with empty condition/action would become like this:

{
  "name": "/Common/Drafts/TestPolicy",
  "strategy": "/Common/first-match",
  "rules": [
    {
      "name": "rule",
      "conditions": [],
      "actions":[]
    }
  ]
}

Now, the arrays of

conditions

and

actions

contain a number of condition/action specs represented as object. Each of them can be accessed from

/mgmt/tm/ltm/policy//rules//conditions/

or

/mgmt/tm/ltm/policy//rules//actions/

.

is the index number of the array, starting from 0. So, adding a condition as the first element of the array would look like this:

 curl -sku admin: https:///mgmt/tm/ltm/policy/~Common~Drafts~TestPolicy/rules/rule/conditions/0 \
  -X POST -H "Content-type: application/json" \
  -d '{ "http-header":true, "all":true, "tmName":"X-Sat", "starts-with":true,  "values":[ "www.google.com" ], "request":true}'

Note that the property name for the HTTP field name is called

tmName

here. In tmsh, it is called

name

: e.g.,

http-header response name Content-type starts-with values { text/ }

(from tmsh help). The field name is changed because

name

is used for the name of the condition index in iControl REST. The payload would be very different from one condition to another. Refer to the

tmsh help ltm poilicy

.

You can put all of them together in one single JSON like what Fred 01 had shown in 24-Oct-2018.

  "name": "/Common/Drafts/TestPolicy2",
  "strategy":"/Common/first-match",
  "rules": [
    {
      "name": "rule",
      "conditions": [
        {
          "name":"0",
          "http-header":true,
          "all":true,
          "tmName":"X-Sat",
          "starts-with":true,
          "values":[ "www.google.com" ],
          "request":true
        }
      ],
      "actions":[
        {
          "name":"0",
          "http-reply":true,
          "redirect":true,
          "location":"https://www.google.com"
        }
      ]
    }
  ]
}

Note that the field name (index number in the arrays) of condtions and actions is

name

, and its value is string (so "0". not numeric 0).

If you get confused with the nested json body, create each entity one by one.

• A policy with empty rule with empty conditions/actions
• The condition(s)
• The action(s)

I hope this clarifies the myth.