GET /api2/tm/rulesets/ viewer
POST /api2/tm/rulesets/ user
GET /api2/tm/rulesets/<id> viewer
PUT /api2/tm/rulesets/<id> user
DELETE /api2/tm/rulesets/<id> userPOST api2/tm/rulesets/import userGET api2/tm/rulesets/export?ids=<rules_set_ids_list> user{
"id": 1,
"name": "set_name",
"description": "set_description",
"created_by": "user1",
"created_at": 1542373932,
"modified_at": 1542373932,
"resource_use": 0.25,
"resource_use_entries": 128,
"ingress_resource_use": 0,
"ingress_resource_use_entries": 0
}The resource_use/ingress_resource_use fields hold the predicted resource use of the rule-set — the egress/ingress TCAM entries its enabled rules would consume if it were activated — as a utilization ratio (*_entries / the corresponding max_*resource_entries of GET /api2/tm/) alongside the raw entry counts. The values are computed whenever the rule-set is compiled (rule changes, activation, or fetching it via GET /api2/tm/rulesets/<id>); until then all four fields are null:
1.0 when the rule-set exceeds the device limits — such a rule-set is stored but cannot be activated.max_ingress_resource_entries is 0, e.g. the X2 family) ingress entries are counted as egress entries and the ingress fields report 0.null when the value is unknown: the rule-set has not been compiled since daemon start — GET /api2/tm/rulesets/ does not trigger compilation, fetching the rule-set via GET /api2/tm/rulesets/<id> computes and caches it — or the rule-set's rules fail to compile (possible for imported rule-sets and after firmware upgrades).GET /api2/tm/.{
"api_ver": 1,
"sw_ver": "v0.0.test_alpha",
"model": "x2-3200g",
"date": 1563185883,
"rulesets": [
{
"name": "ruleset_name",
"description": "ruleset_description",
"created_by": "",
"created_at": 1562065130,
"modified_at": 1563185878,
"vid_groups": [
...
],
"l4_port_groups": [
...
],
"rules": [
...
]
}
]
}