[ovs-dev] [tests+nxm-ofctl 38/42] ofp-parse: Add support for tun_id.

Justin Pettit jpettit at nicira.com
Tue Dec 7 00:15:13 UTC 2010


On Nov 23, 2010, at 2:44 PM, Ben Pfaff wrote:

> --- a/utilities/ovs-ofctl.8.in
> +++ b/utilities/ovs-ofctl.8.in
> @@ -337,6 +337,26 @@ as a decimal number between 0 and 255, inclusive.
> .IP
> When \fBdl_type\fR and \fBnw_proto\fR take other values, the values of
> these settings are ignored (see \fBFlow Syntax\fR above).
> +.IP \fBtun_id=\fItunnel-id\fR
> +Matches tunnel identifier \fItunnel-id\fR.  Only packets that arrive
> +over a tunnel that carries a key (e.g. GRE with the RFC 2890 key
> +extension) will have a nonzero tunnel ID.
> +.IP
> +\fBtun_id\fR requires use of one of two Nicira extensions to OpenFlow:
> +.RS
> +.IP "NXM (Nicira Extended Match)"
> +This extension fully supports \fBtun_id\fR. 
> +.IP "Tunnel ID from Cookie"
> +This extension supports \fBtun_id\fR with two caveats: the top 32 bits
> +of the \fBcookie\fR (see below) are used for \fItunnel-id\fR and thus
> +unavailable for other use, and specifying \fBtun_id\fR on
> +\fBdump\-flows\fR or \fBdump\-aggregate\fR has no effect.
> +.RE
> +.IP

In general, I think you may want to escape the hyphen in "tunnel-id".

> +When \fBtun_id\fR is specified, \fBovs\-ofctl\fR will automatically
> +attempt to negotiate use of one of these extensions, preferring NXM.
> +If the switch does not support either extension, then \fBovs\-ofctl\fR
> +will report a fatal error.

Is this true?  I haven't read patch 41 in detail yet, but it seems like it prefers "Tunnel ID from Cookie":

+ *   - Otherwise, the chosen format should be as backward compatible as
+ *     possible.  (NXFF_OPENFLOW10 is more backward compatible than
+ *     NXFF_TUN_ID_FROM_COOKIE, which is more backward compatible than
+ *     NXFF_NXM.)

--Justin






More information about the dev mailing list