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

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



   ovs-vswitchd.conf.db    ( 5 )

схема базы данных Open_vSwitch (Open_vSwitch database schema)

Flow_Table TABLE

Configuration for a particular OpenFlow table.

Summary: name optional string Eviction Policy: flow_limit optional integer, at least 0 overflow_policy optional string, either evict or refuse groups set of strings Classifier Optimization: prefixes set of up to 3 strings Common Columns: external_ids map of string-string pairs

Details: name: optional string The table's name. Set this column to change the name that controllers will receive when they request table statistics, e.g. ovs-ofctl dump-tables. The name does not affect switch behavior.

Eviction Policy:

Open vSwitch supports limiting the number of flows that may be installed in a flow table, via the flow_limit column. When adding a flow would exceed this limit, by default Open vSwitch reports an error, but there are two ways to configure Open vSwitch to instead delete (``evict'') a flow to make room for the new one:

• Set the overflow_policy column to evict.

• Send an OpenFlow 1.4+ ``table mod request'' to enable eviction for the flow table (e.g. ovs-ofctl -O OpenFlow14 mod-table br0 0 evict to enable eviction on flow table 0 of bridge br0).

When a flow must be evicted due to overflow, the flow to evict is chosen through an approximation of the following algorithm. This algorithm is used regardless of how eviction was enabled:

1. Divide the flows in the table into groups based on the values of the fields or subfields specified in the groups column, so that all of the flows in a given group have the same values for those fields. If a flow does not specify a given field, that field's value is treated as 0. If groups is empty, then all of the flows in the flow table are treated as a single group.

2. Consider the flows in the largest group, that is, the group that contains the greatest number of flows. If two or more groups all have the same largest number of flows, consider the flows in all of those groups.

3. If the flows under consideration have different importance values, eliminate from consideration any flows except those with the lowest importance. (``Importance,'' a 16-bit integer value attached to each flow, was introduced in OpenFlow 1.4. Flows inserted with older versions of OpenFlow always have an importance of 0.)

4. Among the flows under consideration, choose the flow that expires soonest for eviction.

The eviction process only considers flows that have an idle timeout or a hard timeout. That is, eviction never deletes permanent flows. (Permanent flows do count against flow_limit.)

flow_limit: optional integer, at least 0 If set, limits the number of flows that may be added to the table. Open vSwitch may limit the number of flows in a table for other reasons, e.g. due to hardware limitations or for resource availability or performance reasons.

overflow_policy: optional string, either evict or refuse Controls the switch's behavior when an OpenFlow flow table modification request would add flows in excess of flow_limit. The supported values are:

refuse Refuse to add the flow or flows. This is also the default policy when overflow_policy is unset.

evict Delete a flow chosen according to the algorithm described above.

groups: set of strings When overflow_policy is evict, this controls how flows are chosen for eviction when the flow table would otherwise exceed flow_limit flows. Its value is a set of NXM fields or sub-fields, each of which takes one of the forms field[] or field[start..end], e.g. NXM_OF_IN_PORT[]. Please see meta-flow.h for a complete list of NXM field names.

Open vSwitch ignores any invalid or unknown field specifications.

When eviction is not enabled, via overflow_policy or an OpenFlow 1.4+ ``table mod,'' this column has no effect.

Classifier Optimization:

prefixes: set of up to 3 strings This string set specifies which fields should be used for address prefix tracking. Prefix tracking allows the classifier to skip rules with longer than necessary prefixes, resulting in better wildcarding for datapath flows.

Prefix tracking may be beneficial when a flow table contains matches on IP address fields with different prefix lengths. For example, when a flow table contains IP address matches on both full addresses and proper prefixes, the full address matches will typically cause the datapath flow to un-wildcard the whole address field (depending on flow entry priorities). In this case each packet with a different address gets handed to the userspace for flow processing and generates its own datapath flow. With prefix tracking enabled for the address field in question packets with addresses matching shorter prefixes would generate datapath flows where the irrelevant address bits are wildcarded, allowing the same datapath flow to handle all the packets within the prefix in question. In this case many userspace upcalls can be avoided and the overall performance can be better.

This is a performance optimization only, so packets will receive the same treatment with or without prefix tracking.

The supported fields are: tun_id, tun_src, tun_dst, tun_ipv6_src, tun_ipv6_dst, nw_src, nw_dst (or aliases ip_src and ip_dst), ipv6_src, and ipv6_dst. (Using this feature for tun_id would only make sense if the tunnel IDs have prefix structure similar to IP addresses.)

By default, the prefixes=ip_dst,ip_src are used on each flow table. This instructs the flow classifier to track the IP destination and source addresses used by the rules in this specific flow table.

The keyword none is recognized as an explicit override of the default values, causing no prefix fields to be tracked.

To set the prefix fields, the flow table record needs to exist:

ovs-vsctl set Bridge br0 flow_tables:0=@N1 -- --id=@N1 create Flow_Table name=table0 Creates a flow table record for the OpenFlow table number 0.

ovs-vsctl set Flow_Table table0 prefixes=ip_dst,ip_src Enables prefix tracking for IP source and destination address fields.

There is a maximum number of fields that can be enabled for any one flow table. Currently this limit is 3.

Common Columns:

The overall purpose of these columns is described under Common Columns at the beginning of this document.

external_ids: map of string-string pairs