Actions

The actions group defines actions to be taken when packets match a certain bit pattern (the matching rules are defined in the rules group, described in the next section). It contains statements with the following syntax:

action new_action = action

new_action

is the index of the new action.

action

is one of

class qdisc:class,$\ldots$

drop

unspec

conform bucket yes_action no_action

count bucket next_action

action action

class

selects the corresponding class or classes. qdisc is the index of the queuing discipline. class is the number of the class within the queuing discipline. If tcc is able to identify the sequence of queues and classes visited by a packet when taking this action, the whole sequence is described in a comma-separated list of queue and class numbers, starting with the outermost queue.

drop

indicates that the packet shall be dropped.

unspec

indicates that the packet was not recognized by the classifier, and that the default action of the queuing discipline should be taken. Note that the meaning of unspec changes when using nocombine, see section 7.2.9.

conform

tests whether the current packet can be accepted by the token bucket number bucket, and executes yes_action if it does, no_action otherwise. Note that conform does not remove tokens from the bucket.

count

removes tokens corresponding to the current packet from token bucket bucket, and continues with next_action. If the bucket contains fewer tokens than required for the current packet, count sets the bucket to zero.

yes_action, no_action, and next_action are of the form

action action

which continues with the action statement with index meta.

Example:

action 0 = drop
action 1 = class 1:1
action 2 = class 1:2
action 3 = count 1 action 2
action 4 = conform 1 action 3 action 0

Historical note: action statements used to contain more than one action, and the syntax still reflects this original design. This was changed in order to simplify the data structures in programs using the external interface.

Implementation note: while, in theory, tokens are continuously added to a bucket, an implementation will typically choose to add tokens only at packet arrival, and possibly only to buckets considered for the current packet. In this context, it is important to consider that count may be used without prior conform, so adding tokens only on conform would not yield correct behaviour.