Путеводитель по Руководству Linux

  User  |  Syst  |  Libr  |  Device  |  Files  |  Other  |  Admin  |  Head  |



   ovs-actions    ( 7 )

действия и инструкции OpenFlow с расширениями Open vSwitch (OpenFlow actions and instructions with Open vSwitch extensions)

PROGRAMMING AND CONTROL FLOW ACTIONS

The resubmit action Syntax: resubmit:port resubmit([port],[table][,ct])

Searches an OpenFlow flow table for a matching flow and executes the actions found, if any, before continuing to the following action in the current flow entry. Arguments can customize the search:

• If port is given as an OpenFlow port number or name, then it specifies a value to use for the input port metadata field as part of the search, in place of the input port currently in the flow. Specifying in_port as port is equivalent to omitting it.

• If table is given as an integer between 0 and 254 or a table name, it specifies the OpenFlow table to search. If it is not specified, the table from the current flow is used.

• If ct is specified, then the search is done with packet 5-tuple fields swapped with the corresponding conntrack original direction tuple fields. See the documentation for ct above, for more information about connection tracking, or ovs-fields(7) for details about the connection tracking fields.

This flag requires a valid connection tracking state as a match prerequisite in the flow where this action is placed. Examples of valid connection tracking state matches include ct_state=+new, ct_state=+est, ct_state=+rel, and ct_state=+trk-inv.

The changes, if any, to the input port and connection tracking fields are just for searching the flow table. The changes are not visible to actions or to later flow table lookups.

The most common use of resubmit is to visit another flow table without port or ct, like this: resubmit(,table).

Recursive resubmit actions are permitted.

Conformance:

The resubmit action is an Open vSwitch extension. However, the goto_table instruction in OpenFlow 1.1 and later can be viewed as a kind of restricted resubmit.

Open vSwitch 1.2.90 added table. Open vSwitch 2.7 added ct.

Open vSwitch imposes a limit on resubmit recursion that varies among version:

• Open vSwitch 1.0.1 and earlier did not support recursion.

• Open vSwitch 1.0.2 and 1.0.3 limited recursion to 8 levels.

• Open vSwitch 1.1 and 1.2 limited recursion to 16 levels.

• Open vSwitch 1.2 through 1.8 limited recursion to 32 levels.

• Open vSwitch 1.9 through 2.0 limited recursion to 64 levels.

• Open vSwitch 2.1 through 2.5 limited recursion to 64 levels and impose a total limit of 4,096 resubmits per flow translation (earlier versions did not impose any total limit).

• Open vSwitch 2.6 and later imposes the same limits as 2.5, with one exception: resubmit from table x to any table y > x does not count against the recursion depth limit.

The clone action Syntax: clone(action...)

Executes each nested action, saving much of the packet and pipeline state beforehand and then restoring it afterward. The state that is saved and restored includes all flow data and metadata (including, for example, in_port and ct_state), the stack accessed by push and pop actions, and the OpenFlow action set.

This action was added in Open vSwitch 2.6.90.

The push and pop actions Syntax: push:src pop:dst

The push action pushes src on a general-purpose stack. The pop action pops an entry off the stack into dst. src and dst should be fields or subfields in the syntax described under ``Field Specifications'' above.

Controllers can use the stack for saving and restoring data or metadata around resubmit actions, for swapping or rearranging data and metadata, or for other purposes. Any data or metadata field, or part of one, may be pushed, and any modifiable field or subfield may be popped.

The number of bits pushed in a stack entry do not have to match the number of bits later popped from that entry. If more bits are popped from an entry than were pushed, then the entry is conceptually left-padded with 0-bits as needed. If fewer bits are popped than pushed, then bits are conceptually trimmed from the left side of the entry.

The stack's size is limited. The limit is intended to be high enough that ``normal'' use will not pose problems. Stack overflow or underflow is an error that stops action execution (see ``Stack too deep'' under ``Error Handling'', above).

Examples:

push:reg2[0..5] or push:NXM_NX_REG2[0..5] pushes on the stack the 6 bits in register 2 bits 0 through 5.

pop:reg2[0..5] or pop:NXM_NX_REG2[0..5] pops the value from top of the stack and copy bits 0 through 5 of that value into bits 0 through 5 of register 2.

Conformance:

Open vSwitch 1.2 introduced push and pop as OpenFlow extension actions.

The exit action Syntax: exit

This action causes Open vSwitch to immediately halt execution of further actions. Actions which have already been executed are unaffected. Any further actions, including those which may be in other tables, or different levels of the resubmit call stack, are ignored. However, an exit action within a group bucket terminates only execution of that bucket, not other buckets or the overall pipeline. Actions in the action set are still executed (specify clear_actions before exit to discard them).

The multipath action Syntax: multipath(fields, basis, algorithm, n_links, arg, dst)

Hashes fields using basis as a universal hash parameter, then the applies multipath link selection algorithm (with parameter arg) to choose one of n_links output links numbered 0 through n_links minus 1, and stores the link into dst, which must be a field or subfield in the syntax described under ``Field Specifications'' above.

The bundle or bundle_load actions are usually easier to use than multipath.

fields must be one of the following:

eth_src Hashes Ethernet source address only.

symmetric_l4 Hashes Ethernet source, destination, and type, VLAN ID, IPv4/IPv6 source, destination, and protocol, and TCP or SCTP (but not UDP) ports. The hash is computed so that pairs of corresponding flows in each direction hash to the same value, in environments where L2 paths are the same in each direction. UDP ports are not included in the hash to support protocols such as VXLAN that use asymmetric ports in each direction.

symmetric_l3l4 Hashes IPv4/IPv6 source, destination, and protocol, and TCP or SCTP (but not UDP) ports. Like symmetric_l4, this is a symmetric hash, but by excluding L2 headers it is more effective in environments with asymmetric L2 paths (e.g. paths involving VRRP IP addresses on a router). Not an effective hash function for protocols other than IPv4 and IPv6, which hash to a constant zero.

symmetric_l3l4+udp Like symmetric_l3l4+udp, but UDP ports are included in the hash. This is a more effective hash when asymmetric UDP protocols such as VXLAN are not a consideration.

symmetric_l3 Hashes network source address and network destination address.

nw_src Hashes network source address only.

nw_dst Hashes network destination address only.

The algorithm used to compute the final result link must be one of the following:

modulo_n Computes link = hash(flow) % n_links.

This algorithm redistributes all traffic when n_links changes. It has O(1) performance.

Use 65535 for max_link to get a raw hash value.

This algorithm is specified by RFC 2992.

hash_threshold Computes link = hash(flow) / (MAX_HASH / n_links).

Redistributes between one-quarter and one-half of traffic when n_links changes. It has O(1) performance.

This algorithm is specified by RFC 2992.

hrw (Highest Random Weight) Computes the following:

for i in [0,n_links]: weights[i] = hash(flow, i) link = { i such that weights[i] >= weights[j] for all j != i }

Redistributes 1/n_links of traffic when n_links changes. It has O(n_links) performance. If n_links is greater than a threshold (currently 64, but subject to change), Open vSwitch will substitute another algorithm automatically.

This algorithm is specified by RFC 2992.

iter_hash (Iterative Hash) Computes the following:

i = 0 repeat: i = i + 1 link = hash(flow, i) % arg while link > max_link

Redistributes 1/n_links of traffic when n_links changes. O(1) performance when arg/max_link is bounded by a constant.

Redistributes all traffic when arg changes.

arg must be greater than max_link and for best performance should be no more than approximately max_link * 2. If arg is outside the acceptable range, Open vSwitch will automatically substitute the least power of 2 greater than max_link.

This algorithm is specific to Open vSwitch.

Only the iter_hash algorithm uses arg.

It is an error if max_link is greater than or equal to 2**n_bits.

Conformance:

This is an OpenFlow extension added in Open vSwitch 1.1.