[ovs-dev] [PATCH 2/3] ofp-util: Enforce OpenFlow 1.1+ table_id requirements in flow_mod messages.

Jarno Rajahalme jrajahalme at nicira.com
Fri Nov 1 22:42:30 UTC 2013


On Nov 1, 2013, at 9:43 AM, Ben Pfaff <blp at nicira.com> wrote:

> Signed-off-by: Ben Pfaff <blp at nicira.com>
> ---
> lib/ofp-util.c           |   21 +++++++++++++-
> tests/learn.at           |    4 +--
> tests/ofp-print.at       |   12 ++++----
> tests/ovs-ofctl.at       |   48 +++++++++++++++----------------
> utilities/ovs-ofctl.8.in |   71 +++++++++++++++++++++++++++++++++++-----------
> 5 files changed, 106 insertions(+), 50 deletions(-)
> 
> diff --git a/lib/ofp-util.c b/lib/ofp-util.c
> index 3d9efab..e6a9494 100644
> --- a/lib/ofp-util.c
> +++ b/lib/ofp-util.c
> @@ -1530,7 +1530,19 @@ ofputil_decode_flow_mod(struct ofputil_flow_mod *fm,
>         }
>         fm->modify_cookie = false;
>         fm->command = ofm->command;
> +
> +        /* Get table ID.
> +         *
> +         * OF1.1 entirely forbids table_id == 255.
> +         * OF1.2+ allows table_id == 255 only for deletes. */
>         fm->table_id = ofm->table_id;
> +        if (fm->table_id == 0xff

I’d rather see “255” here as well to match the comments.

> +            && (oh->version == OFP11_VERSION
> +                || (ofm->command != OFPFC_DELETE &&
> +                    ofm->command != OFPFC_DELETE_STRICT))) {
> +            return OFPERR_OFPFMFC_BAD_TABLE_ID;
> +        }
> +
…

> +For flow dump commands, limits the flows dumped to those in the table
> +with the given \fInumber\fR between 0 and 254.  If not specified (or if
> +255 is specified as \fInumber\fR), then flows in all tables are
> +dumped.
> +.
> +.IP
> +For flow table modification commands, behavior varies based on the
> +OpenFlow version used to connect to the switch:
> +.
> +.RS
> +.IP "OpenFlow 1.0"
> +OpenFlow 1.0 does not support \fBtable\fR for modifying flows.
> +\fBovs\-ofctl\fR will exit with an error if \fBtable\fR (other than
> +\fBtable=255\fR) is specified for a switch that only supports OpenFlow
> +1.0.
> +.IP
> +In OpenFlow 1.0, the switch chooses the table into which to insert a
> +new flow.  The Open vSwitch software switch always chooses table 0.
> +Other Open vSwitch datapaths and other OpenFlow implementations may
> +choose different tables.

IMO any implementation should pick the “input table”, which by definition is 0, or no?

> +.IP
> +The OpenFlow 1.0 behavior in Open vSwitch for modifying or removing
> +flows depends on whether \fB\-\-strict\fR is used.  Without
> +\fB\-\-strict\fR, the command applies to matching flows in all tables.
> +With \fB\-\-strict\fR, the command will operate on any single matching
> +flow in any table; it will do nothing if there are matches in more
> +than one table.  (The distinction between these behaviors only matters
> +if non-OpenFlow 1.0 commands were also used, because OpenFlow 1.0
> +alone cannot add flows with the same matching criteria to multiple
> +tables.)
> +.
…

  Jarno




More information about the dev mailing list