Traffic Management: LAGs

Endpoints

• Display LAGs : GET /api2/tm/rulesets/<set_id>/lags/ viewer
  • Json structure
• Create new LAG : POST /api2/tm/rulesets/<set_id>/lags/ user
  • Json structure
  • If the rule set is the active one, the response also includes an nm_response field with the network module's deployment result: the LAG is created there straight away, so that a rule delivering to it can be added afterwards without redeploying the rule set.
• Display single LAG : GET /api2/tm/rulesets/<set_id>/lags/<LAG_id> viewer
  • Json structure
• Edit LAG : PUT /api2/tm/rulesets/<set_id>/lags/<LAG_id> user
  • Json structure
  • If the rule set is the active one and the ports change, the response also includes an nm_response field. The network module cannot alter a LAG in place, so the rule set is redeployed in full and its packet counters restart. An edit of the name alone changes nothing on the module and returns no nm_response.
• Delete LAG : DELETE /api2/tm/rulesets/<set_id>/lags/<LAG_id> user
  • If the rule set is the active one, the response also includes an nm_response field. Nothing but a full redeployment removes a LAG from the network module, so the rule set is redeployed in full and its packet counters restart.

Dry-run preview

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. Returns 200 {} on success; error responses (status code and body) are identical to the non-dry-run call. When the edit changes what the rule-set costs, the 200 body is instead the resource cost report described in Chain Management (rules, chains and total; both arrays are always present).

Json structures

Display Rule json structure

{
    "id": 1,
    "set_id": 10,
    "name": "lag_name",
    "ports": [{"id":0, "type":"INF"}, ...],
}

Back to X2-SERIES API Home