Traffic control elements are attached to certain points in the hierarchy dangling off an interface. We call such a point of attachment the ``parent'' of an element. The parent is usually given by the nesting of elements.
Example:
eth0 # ID # Parent cbq (1,...) { 1:0 root class (1,...) { 1:1 1:0 class (3,...) { 1:3 1:1 } prio (2) { 2:0 1:1 class (1) ... 2:1 2:0 } } class (2,...) { 1:2 1:0 tcindex (1,...) { prio 1 at 1:2 1:2 class (4,...) 1:4 1:2 on (...); ? prio 1 at 1:2 } } }
Sometimes, this is not sufficient to obtain the desired structure. In such cases, variables can be used to specify elements at other locations. Queuing disciplines, classes, and filters can be assigned to variables by putting a variable assignment in front of their specification, e.g
$q = prio;
The parent of this element is then determined by the location of its specification, not the location of its actual use. To access such an element, use the keyword qdisc, class, or filter, followed by the variable name.
Similarly, a policer or bucket may be used at several places, and can therefore also be stored in a variable.
Examples:
// Single queuing discipline shared by multiple classes // Note: in the case of "prio", this is actually pointless. prio { $q = tbf ...; class (1) { qdisc $q; } class (2) { qdisc $q; } }
// Top-level filter directly selects classes deeper in the tree cbq ... { $f = rsvp ...; class ... on filter $f element (...) { class ... on filter $f element (...); class ... on filter $f element (...); } }
Note: on filter $f element () can be abbreviated to on $f().
// Different filters select the same class $c = class ... tcindex (...) { class $c on ...; } rsvp ... { class $c on ...; }
// Policer used for multiple flows $p = police ...; prio ... { class ... ... police $p; class ... ... police $p; class ... }
When using a bucket variable in an if expression, the bucket (or police, for compatibility) keyword can be omitted, e.g. conform bucket $p is equivalent to conform $p.