GET /api2/tm/rulesets/<set_id>/chains viewer
POST /api2/tm/rulesets/<set_id>/chains user
GET /api2/tm/rulesets/<set_id>/chains/<chain_id> viewer
PUT /api2/tm/rulesets/<set_id>/chains/<chain_id> user
DELETE /api2/tm/rulesets/<set_id>/chains/<chain_id> userOn the three mutation endpoints, if the chain belongs to the active ruleset the response also includes an nm_response field with the network module's redeployment result.
A chain entry that carries no rule costs no TCAM entry at all: the traffic is simply replicated to the tool. The rules of an entry select what reaches it and the rest is dropped there, which costs entries in both directions, and those are charged to the ruleset like the entries of a traffic rule (see the resource_use fields in Rule-Set Management). A hop into a "distribution" tool group is charged like a traffic rule delivering to a link aggregation: depending on the rules the entry carries it may cost one entry per member port of the group. A chain that no longer fits the device is refused with 409.
The network module can add a link aggregation but neither alter nor delete one, so what a change does to the internal aggregations decides how it is deployed. Creating a chain that goes through a "distribution" tool group, and adding such a group to a chain direction, only add aggregations: the change is deployed on its own and costs nothing beyond the entries that name them. Deleting such a chain, taking the group out of a chain, changing the group's members and changing the ports of a member drop or rewire an aggregation, which redeploys the rule set in full; the rule set's hardware counters restart then, as they do on any full redeployment. Editing the rules of such an entry leaves the aggregations untouched.
The mutation endpoints above accept an optional ?dry_run=true query parameter. With the flag set, the handler runs all the same checks as the non-dry-run call but does not persist to the DAO and does not push to the network module. Error responses (status code and body) are identical to the non-dry-run call.
On success the answer is the resource cost the mutation would have: 200 {} when it costs nothing (which is the case for every chain whose entries carry no rule), otherwise a report of what each affected chain and rule costs before and after:
{
"rules": [],
"chains": [
{
"id": 3,
"name": "traffic-chain",
"ingress": {"before": 0, "after": 0, "delta": 0},
"egress": {"before": 0, "after": 4, "delta": 4}
}
],
"total": {
"ingress": {"before": 0, "after": 0, "delta": 0},
"egress": {"before": 2, "after": 6, "delta": 4}
}
}The entries a chain is translated into belong to the chain, not to any rule: they are reported under chains and never appear under rules. total covers the whole ruleset, chains included.
A chain carries the traffic between its a_ports and its b_ports, through the tools and tool groups listed in ab_chain in that order.
The B to A direction is defined by ba_chain:
null (or absent) — the chain is symmetric: the return traffic goes through the same hops in reverse order, with the same rules and bypass flags.The filters of an entry rule are direction-sensitive and apply as written in both directions. Define ba_chain explicitly to treat the two directions differently.
{
"id": 1,
"set_id": 10,
"name": "traffic-chain",
"is_enabled": true,
"a_ports": [{"id":1, "type":"INF"}, ...],
"b_ports": [{"id":2, "type":"INF"}, ...],
"ab_chain": [
{
"type": "tool",
"id": 123,
"bypass_enabled": true,
"rules": [
{
"filter": { <same object as the rule filter> },
"actions": [ <same objects as the rule actions> ],
"priority_class": 0
}, ...
]
}, ...
],
"ba_chain": null
}name: mandatory; does not have to be unique.is_enabled: whether the chain carries traffic. Defaults to true when absent.a_ports: mandatory, at least one port. The A side of the chain.b_ports: mandatory, at least one port. The B side of the chain.ab_chain: mandatory, may be empty; the hops of the A to B direction, in order. An empty array carries the traffic straight through, so a chain can be created before its tools exist.ba_chain: the hops of the B to A direction, see Directions. null when absent.Chain entry:
type: mandatory, "tool" or "group" — what the entry points at.id: mandatory; the ID of that tool or tool group, which must belong to the same ruleset.bypass_enabled: when true, the traffic flows on to the next hop while this one is offline. While the chain belongs to the active rule set, the daemon deploys the hop again each time the tool behind it goes offline or comes back online, so the bypass takes effect — and is taken back — without any request of yours. Only valid on hops the traffic goes through, see the restrictions below. Defaults to false when absent, which keeps the traffic on this hop whatever its state: it then stops at the hop's dead port and flows again by itself the moment the link is back, and no deployment follows.rules: what the hop does with the traffic reaching it. Each element carries the filter, the actions and the priority_class of a traffic rule, with the same meaning and the same validation (see Rule Management), and traffic matching the filter of any of them is treated by that rule — so a rule with a drop action drops it at the hop instead of sending it in. Traffic matching none of them is treated the way the rules of a traffic rule set treat it: as long as at least one of the entry rules lets traffic in, everything else is dropped at the hop; an entry whose rules all drop is a blacklist, and everything else enters the hop. An absent, null or empty array means the hop receives everything untouched.All three fields are mandatory within an entry rule. A rule that selects nothing, or that leaves its precedence against the other rules of the entry unstated, is rejected. To let the traffic a filter selects into the hop untouched, give the rule an empty actions array.