Summary:
Name Bytes Mask RW? Prereqs NXM/OXM Support
───────────────────── ──────────────── ───── ──── ──────── ─────────────────────
tun_id aka tunnel_id 8 yes yes none OF 1.3+ and OVS 1.1+
tun_src 4 yes yes none OVS 2.0+
tun_dst 4 yes yes none OVS 2.0+
tun_ipv6_src 16 yes yes none OVS 2.5+
tun_ipv6_dst 16 yes yes none OVS 2.5+
tun_gbp_id 2 yes yes none OVS 2.4+
tun_gbp_flags 1 yes yes none OVS 2.4+
tun_erspan_ver 1 (low 4 bits) yes yes none OVS 2.10+
tun_erspan_idx 4 (low 20 bits) yes yes none OVS 2.10+
tun_erspan_dir 1 (low 1 bits) yes yes none OVS 2.10+
tun_erspan_hwid 1 (low 6 bits) yes yes none OVS 2.10+
tun_gtpu_flags 1 yes no none OVS 2.13+
tun_gtpu_msgtype 1 yes no none OVS 2.13+
tun_metadata0 124 yes yes none OVS 2.5+
tun_metadata1 124 yes yes none OVS 2.5+
tun_metadata2 124 yes yes none OVS 2.5+
tun_metadata3 124 yes yes none OVS 2.5+
tun_metadata4 124 yes yes none OVS 2.5+
tun_metadata5 124 yes yes none OVS 2.5+
tun_metadata6 124 yes yes none OVS 2.5+
tun_metadata7 124 yes yes none OVS 2.5+
tun_metadata8 124 yes yes none OVS 2.5+
tun_metadata9 124 yes yes none OVS 2.5+
tun_metadata10 124 yes yes none OVS 2.5+
tun_metadata11 124 yes yes none OVS 2.5+
tun_metadata12 124 yes yes none OVS 2.5+
tun_metadata13 124 yes yes none OVS 2.5+
tun_metadata14 124 yes yes none OVS 2.5+
tun_metadata15 124 yes yes none OVS 2.5+
tun_metadata16 124 yes yes none OVS 2.5+
tun_metadata17 124 yes yes none OVS 2.5+
tun_metadata18 124 yes yes none OVS 2.5+
tun_metadata19 124 yes yes none OVS 2.5+
tun_metadata20 124 yes yes none OVS 2.5+
tun_metadata21 124 yes yes none OVS 2.5+
tun_metadata22 124 yes yes none OVS 2.5+
tun_metadata23 124 yes yes none OVS 2.5+
tun_metadata24 124 yes yes none OVS 2.5+
tun_metadata25 124 yes yes none OVS 2.5+
tun_metadata26 124 yes yes none OVS 2.5+
tun_metadata27 124 yes yes none OVS 2.5+
tun_metadata28 124 yes yes none OVS 2.5+
tun_metadata29 124 yes yes none OVS 2.5+
tun_metadata30 124 yes yes none OVS 2.5+
tun_metadata31 124 yes yes none OVS 2.5+
tun_metadata32 124 yes yes none OVS 2.5+
tun_metadata33 124 yes yes none OVS 2.5+
tun_metadata34 124 yes yes none OVS 2.5+
tun_metadata35 124 yes yes none OVS 2.5+
tun_metadata36 124 yes yes none OVS 2.5+
tun_metadata37 124 yes yes none OVS 2.5+
tun_metadata38 124 yes yes none OVS 2.5+
tun_metadata39 124 yes yes none OVS 2.5+
tun_metadata40 124 yes yes none OVS 2.5+
tun_metadata41 124 yes yes none OVS 2.5+
tun_metadata42 124 yes yes none OVS 2.5+
tun_metadata43 124 yes yes none OVS 2.5+
tun_metadata44 124 yes yes none OVS 2.5+
tun_metadata45 124 yes yes none OVS 2.5+
tun_metadata46 124 yes yes none OVS 2.5+
tun_metadata47 124 yes yes none OVS 2.5+
tun_metadata48 124 yes yes none OVS 2.5+
tun_metadata49 124 yes yes none OVS 2.5+
tun_metadata50 124 yes yes none OVS 2.5+
tun_metadata51 124 yes yes none OVS 2.5+
tun_metadata52 124 yes yes none OVS 2.5+
tun_metadata53 124 yes yes none OVS 2.5+
tun_metadata54 124 yes yes none OVS 2.5+
tun_metadata55 124 yes yes none OVS 2.5+
tun_metadata56 124 yes yes none OVS 2.5+
tun_metadata57 124 yes yes none OVS 2.5+
tun_metadata58 124 yes yes none OVS 2.5+
tun_metadata59 124 yes yes none OVS 2.5+
tun_metadata60 124 yes yes none OVS 2.5+
tun_metadata61 124 yes yes none OVS 2.5+
tun_metadata62 124 yes yes none OVS 2.5+
tun_metadata63 124 yes yes none OVS 2.5+
tun_flags 2 (low 1 bits) yes yes none OVS 2.5+
The fields in this group relate to tunnels, which Open vSwitch
supports in several forms (GRE, VXLAN, and so on). Most of these
fields do appear in the wire format of a packet, so they are data
fields from that point of view, but they are metadata from an
OpenFlow flow table point of view because they do not appear in
packets that are forwarded to the controller or to ordinary (non-
tunnel) output ports.
Open vSwitch supports a spectrum of usage models for mapping
tunnels to OpenFlow ports:
``Port-based'' tunnels
In this model, an OpenFlow port represents one
tunnel: it matches a particular type of tunnel
traffic between two IP endpoints, with a particular
tunnel key (if keys are in use). In this situation,
in_port suffices to distinguish one tunnel from
another, so the tunnel header fields have little
importance for OpenFlow processing. (They are still
populated and may be used if it is convenient.) The
tunnel header fields play no role in sending
packets out such an OpenFlow port, either, because
the OpenFlow port itself fully specifies the tunnel
headers.
The following Open vSwitch commands create a bridge
br-int, add port tap0 to the bridge as OpenFlow
port 1, establish a port-based GRE tunnel between
the local host and remote IP 192.168.1.1 using GRE
key 5001 as OpenFlow port 2, and arranges to
forward all traffic from tap0 to the tunnel and
vice versa:
ovs-vsctl add-br br-int
ovs-vsctl add-port br-int tap0 -- set interface tap0 ofport_request=1
ovs-vsctl add-port br-int gre0 -- \
set interface gre0 ofport_request=2 type=gre \
options:remote_ip=192.168.1.1 options:key=5001
ovs-ofctl add-flow br-int in_port=1,actions=2
ovs-ofctl add-flow br-int in_port=2,actions=1
``Flow-based'' tunnels
In this model, one OpenFlow port represents all
possible tunnels of a given type with an endpoint
on the current host, for example, all GRE tunnels.
In this situation, in_port only indicates that
traffic was received on the particular kind of
tunnel. This is where the tunnel header fields are
most important: they allow the OpenFlow tables to
discriminate among tunnels based on their IP
endpoints or keys. Tunnel header fields also
determine the IP endpoints and keys of packets sent
out such a tunnel port.
The following Open vSwitch commands create a bridge
br-int, add port tap0 to the bridge as OpenFlow
port 1, establish a flow-based GRE tunnel port 3,
and arranges to forward all traffic from tap0 to
remote IP 192.168.1.1 over a GRE tunnel with key
5001 and vice versa:
ovs-vsctl add-br br-int
ovs-vsctl add-port br-int tap0 -- set interface tap0 ofport_request=1
ovs-vsctl add-port br-int allgre -- \
set interface allgre ofport_request=3 type=gre \
options:remote_ip=flow options:key=flow
ovs-ofctl add-flow br-int \
'in_port=1 actions=set_tunnel:5001,set_field:192.168.1.1->tun_dst,3'
ovs-ofctl add-flow br-int 'in_port=3,tun_src=192.168.1.1,tun_id=5001 actions=1'
Mixed models.
One may define both flow-based and port-based
tunnels at the same time. For example, it is valid
and possibly useful to create and configure both
gre0 and allgre tunnel ports described above.
Traffic is attributed on ingress to the most
specific matching tunnel. For example, gre0 is more
specific than allgre. Therefore, if both exist,
then gre0 will be the ingress port for any GRE
traffic received from 192.168.1.1 with key 5001.
On egress, traffic may be directed to any
appropriate tunnel port. If both gre0 and allgre
are configured as already described, then the
actions 2 and
set_tunnel:5001,set_field:192.168.1.1->tun_dst,3
send the same tunnel traffic.
Intermediate models.
Ports may be configured as partially flow-based.
For example, one may define an OpenFlow port that
represents tunnels between a pair of endpoints but
leaves the flow table to discriminate on the flow
key.
ovs-vswitchd.conf.db(5) describes all the details of tunnel
configuration.
These fields do not have any prerequisites, which means that a
flow may match on any or all of them, in any combination.
These fields are zeros for packets that did not arrive on a
tunnel.
Tunnel ID Field
Name: tun_id (aka tunnel_id)
Width: 64 bits
Format: hexadecimal
Masking: arbitrary bitwise masks
Prerequisites: none
Access: read/write
OpenFlow 1.0: not supported
OpenFlow 1.1: not supported
OXM: OXM_OF_TUNNEL_ID (38) since OpenFlow 1.3 and
Open vSwitch 1.10
NXM: NXM_NX_TUN_ID (16) since Open vSwitch 1.1
Many kinds of tunnels support a tunnel ID:
• VXLAN and Geneve have a 24-bit virtual network
identifier (VNI).
• LISP has a 24-bit instance ID.
• GRE has an optional 32-bit key.
• STT has a 64-bit key.
• ERSPAN has a 10-bit key (Session ID).
• GTPU has a 32-bit key (Tunnel Endpoint ID).
When a packet is received from a tunnel, this field holds the
tunnel ID in its least significant bits, zero-extended to fit.
This field is zero if the tunnel does not support an ID, or if no
ID is in use for a tunnel type that has an optional ID, or if an
ID of zero received, or if the packet was not received over a
tunnel.
When a packet is output to a tunnel port, the tunnel
configuration determines whether the tunnel ID is taken from this
field or bound to a fixed value. See the earlier description of
``port-based'' and ``flow-based'' tunnels for more information.
The following diagram shows the origin of this field in a typical
keyed GRE tunnel:
Ethernet IPv4 GRE Ethernet
<-----------> <---------------> <------------> <---------->
48 48 16 8 32 32 16 16 32 48 48 16
+---+---+-----+ +---+-----+---+---+ +---+------+---+ +---+---+----+
|dst|src|type | |...|proto|src|dst| |...| type |key| |dst|src|type| ...
+---+---+-----+ +---+-----+---+---+ +---+------+---+ +---+---+----+
0x800 47 0x6558
Tunnel IPv4 Source Field
Name: tun_src
Width: 32 bits
Format: IPv4
Masking: arbitrary bitwise masks
Prerequisites: none
Access: read/write
OpenFlow 1.0: not supported
OpenFlow 1.1: not supported
OXM: none
NXM: NXM_NX_TUN_IPV4_SRC (31) since Open vSwitch 2.0
When a packet is received from a tunnel, this field is the source
address in the outer IP header of the tunneled packet. This field
is zero if the packet was not received over a tunnel.
When a packet is output to a flow-based tunnel port, this field
influences the IPv4 source address used to send the packet. If it
is zero, then the kernel chooses an appropriate IP address based
using the routing table.
The following diagram shows the origin of this field in a typical
keyed GRE tunnel:
Ethernet IPv4 GRE Ethernet
<-----------> <---------------> <------------> <---------->
48 48 16 8 32 32 16 16 32 48 48 16
+---+---+-----+ +---+-----+---+---+ +---+------+---+ +---+---+----+
|dst|src|type | |...|proto|src|dst| |...| type |key| |dst|src|type| ...
+---+---+-----+ +---+-----+---+---+ +---+------+---+ +---+---+----+
0x800 47 0x6558
Tunnel IPv4 Destination Field
Name: tun_dst
Width: 32 bits
Format: IPv4
Masking: arbitrary bitwise masks
Prerequisites: none
Access: read/write
OpenFlow 1.0: not supported
OpenFlow 1.1: not supported
OXM: none
NXM: NXM_NX_TUN_IPV4_DST (32) since Open vSwitch 2.0
When a packet is received from a tunnel, this field is the
destination address in the outer IP header of the tunneled
packet. This field is zero if the packet was not received over a
tunnel.
When a packet is output to a flow-based tunnel port, this field
specifies the destination to which the tunnel packet is sent.
The following diagram shows the origin of this field in a typical
keyed GRE tunnel:
Ethernet IPv4 GRE Ethernet
<-----------> <---------------> <------------> <---------->
48 48 16 8 32 32 16 16 32 48 48 16
+---+---+-----+ +---+-----+---+---+ +---+------+---+ +---+---+----+
|dst|src|type | |...|proto|src|dst| |...| type |key| |dst|src|type| ...
+---+---+-----+ +---+-----+---+---+ +---+------+---+ +---+---+----+
0x800 47 0x6558
Tunnel IPv6 Source Field
Name: tun_ipv6_src
Width: 128 bits
Format: IPv6
Masking: arbitrary bitwise masks
Prerequisites: none
Access: read/write
OpenFlow 1.0: not supported
OpenFlow 1.1: not supported
OXM: none
NXM: NXM_NX_TUN_IPV6_SRC (109) since Open vSwitch 2.5
Similar to tun_src, but for tunnels over IPv6.
Tunnel IPv6 Destination Field
Name: tun_ipv6_dst
Width: 128 bits
Format: IPv6
Masking: arbitrary bitwise masks
Prerequisites: none
Access: read/write
OpenFlow 1.0: not supported
OpenFlow 1.1: not supported
OXM: none
NXM: NXM_NX_TUN_IPV6_DST (110) since Open vSwitch 2.5
Similar to tun_dst, but for tunnels over IPv6.
VXLAN Group-Based Policy Fields
The VXLAN header is defined as follows [RFC 7348], where the I
bit must be set to 1, unlabeled bits or those labeled reserved
must be set to 0, and Open vSwitch makes the VNI available via
tun_id:
VXLAN flags
<------------->
1 1 1 1 1 1 1 1 24 24 8
+-+-+-+-+-+-+-+-+--------+---+--------+
| | | | |I| | | |reserved|VNI|reserved|
+-+-+-+-+-+-+-+-+--------+---+--------+
VXLAN Group-Based Policy [VXLAN Group Policy Option] adds new
interpretations to existing bits in the VXLAN header,
reinterpreting it as follows, with changes highlighted:
GBP flags
<------------->
1 1 1 1 1 1 1 1 24 24 8
+-+-+-+-+-+-+-+-+---------------+---+--------+
| |D| | |A| | | |group policy ID|VNI|reserved|
+-+-+-+-+-+-+-+-+---------------+---+--------+
Open vSwitch makes GBP fields and flags available through the
following fields. Only packets that arrive over a VXLAN tunnel
with the GBP extension enabled have these fields set. In other
packets they are zero on receive and ignored on transmit.
VXLAN Group-Based Policy ID Field
Name: tun_gbp_id
Width: 16 bits
Format: decimal
Masking: arbitrary bitwise masks
Prerequisites: none
Access: read/write
OpenFlow 1.0: not supported
OpenFlow 1.1: not supported
OXM: none
NXM: NXM_NX_TUN_GBP_ID (38) since Open vSwitch 2.4
For a packet tunneled over VXLAN with the Group-Based Policy
(GBP) extension, this field represents the GBP policy ID, as
shown above.
VXLAN Group-Based Policy Flags Field
Name: tun_gbp_flags
Width: 8 bits
Format: hexadecimal
Masking: arbitrary bitwise masks
Prerequisites: none
Access: read/write
OpenFlow 1.0: not supported
OpenFlow 1.1: not supported
OXM: none
NXM: NXM_NX_TUN_GBP_FLAGS (39) since Open vSwitch 2.4
For a packet tunneled over VXLAN with the Group-Based Policy
(GBP) extension, this field represents the GBP policy flags, as
shown above.
The field has the format shown below:
GBP Flags
<------------->
1 1 1 1 1 1 1 1
+-+-+-+-+-+-+-+-+
| |D| | |A| | | |
+-+-+-+-+-+-+-+-+
Unlabeled bits are reserved and must be transmitted as 0. The
VXLAN GBP draft defines the other bits' meanings as:
D (Don't Learn)
When set, this bit indicates that the egress tunnel
endpoint must not learn the source address of the
encapsulated frame.
A (Applied)
When set, indicates that the group policy has
already been applied to this packet. Devices must
not apply policies when the A bit is set.
ERSPAN Metadata Fields
These fields provide access to features in the ERSPAN tunneling
protocol [ERSPAN], which has two major versions: version 1 (aka
type II) and version 2 (aka type III).
Regardless of version, ERSPAN is encapsulated within a fixed
8-byte GRE header that consists of a 4-byte GRE base header and a
4-byte sequence number. The ERSPAN version 1 header format is:
GRE ERSPAN v1 Ethernet
<------------> <---------------------> <---------->
16 16 32 4 18 10 12 20 48 48 16
+---+------+---+ +---+---+-------+---+---+ +---+---+----+
|...| type |seq| |ver|...|session|...|idx| |dst|src|type| ...
+---+------+---+ +---+---+-------+---+---+ +---+---+----+
0x88be 1 tun_id
The ERSPAN version 2 header format is:
GRE ERSPAN v2 Ethernet
<------------> <----------------------------------------> <---------->
16 16 32 4 18 10 32 22 6 1 3 48 48 16
+---+------+---+ +---+---+-------+---------+---+----+---+---+ +---+---+----+
|...| type |seq| |ver|...|session|timestamp|...|hwid|dir|...| |dst|src|type| ...
+---+------+---+ +---+---+-------+---------+---+----+---+---+ +---+---+----+
0x22eb 2 tun_id 0/1
ERSPAN Version Field
Name: tun_erspan_ver
Width: 8 bits (only the least-significant 4 bits may be nonzero)
Format: decimal
Masking: arbitrary bitwise masks
Prerequisites: none
Access: read/write
OpenFlow 1.0: not supported
OpenFlow 1.1: not supported
OXM: none
NXM: NXOXM_ET_ERSPAN_VER (12) since Open vSwitch 2.10
ERSPAN version number: 1 for version 1, or 2 for version 2.
ERSPAN Index Field
Name: tun_erspan_idx
Width: 32 bits (only the least-significant 20 bits may be nonzero)
Format: hexadecimal
Masking: arbitrary bitwise masks
Prerequisites: none
Access: read/write
OpenFlow 1.0: not supported
OpenFlow 1.1: not supported
OXM: none
NXM: NXOXM_ET_ERSPAN_IDX (11) since Open vSwitch 2.10
This field is a 20-bit index/port number associated with the
ERSPAN traffic's source port and direction (ingress/egress). This
field is platform dependent.
ERSPAN Direction Field
Name: tun_erspan_dir
Width: 8 bits (only the least-significant 1 bits may be nonzero)
Format: decimal
Masking: arbitrary bitwise masks
Prerequisites: none
Access: read/write
OpenFlow 1.0: not supported
OpenFlow 1.1: not supported
OXM: none
NXM: NXOXM_ET_ERSPAN_DIR (13) since Open vSwitch 2.10
For ERSPAN v2, the mirrored traffic's direction: 0 for ingress
traffic, 1 for egress traffic.
ERSPAN Hardware ID Field
Name: tun_erspan_hwid
Width: 8 bits (only the least-significant 6 bits may be nonzero)
Format: hexadecimal
Masking: arbitrary bitwise masks
Prerequisites: none
Access: read/write
OpenFlow 1.0: not supported
OpenFlow 1.1: not supported
OXM: none
NXM: NXOXM_ET_ERSPAN_HWID (14) since Open vSwitch 2.10
A 6-bit unique identifier of an ERSPAN v2 engine within a system.
GTP-U Metadata Fields
These fields provide access to set-up GPRS Tunnelling Protocol
for User Plane (GTPv1-U), based on 3GPP TS 29.281. A GTP-U header
has the following format:
8 8 16 32
+-----+--------+------+----+
|flags|msg type|length|TEID| ...
+-----+--------+------+----+
The flags and message type have the Open vSwitch GTP-U specific
fields described below. Open vSwitch makes the TEID (Tunnel
Endpoint Identifier), which identifies a tunnel endpoint in the
receiving GTP-U protocol entity, available via tun_id.
GTP-U Flags Field
Name: tun_gtpu_flags
Width: 8 bits
Format: hexadecimal
Masking: arbitrary bitwise masks
Prerequisites: none
Access: read-only
OpenFlow 1.0: not supported
OpenFlow 1.1: not supported
OXM: none
NXM: NXOXM_ET_GTPU_FLAGS (15) since Open vSwitch 2.13
This field holds the 8-bit GTP-U flags, encoded as:
GTP-U Tunnel Flags
<------------------->
3 1 1 1 1 1
+-------+--+---+-+-+--+
|version|PT|rsv|E|S|PN|
+-------+--+---+-+-+--+
1 0
The flags are:
version
Used to determine the version of the GTP-U
protocol, which should be set to 1.
PT Protocol type, used as a protocol discriminator
between GTP (1) and GTP' (0).
rsv Reserved. Must be zero.
E If 1, indicates the presence of a meaningful value
of the Next Extension Header field.
S If 1, indicates the presence of a meaningful value
of the Sequence Number field.
PN If 1, indicates the presence of a meaningful value
of the N-PDU Number field.
GTP-U Message Type Field
Name: tun_gtpu_msgtype
Width: 8 bits
Format: decimal
Masking: arbitrary bitwise masks
Prerequisites: none
Access: read-only
OpenFlow 1.0: not supported
OpenFlow 1.1: not supported
OXM: none
NXM: NXOXM_ET_GTPU_MSGTYPE (16) since Open vSwitch
2.13
This field indicates whether it's a signalling message used for
path management, or a user plane message which carries the
original packet. The complete range of message types can be
referred to [3GPP TS 29.281].
Geneve Fields
These fields provide access to additional features in the Geneve
tunneling protocol [Geneve]. Their names are somewhat generic in
the hope that the same fields could be reused for other protocols
in the future; for example, the NSH protocol [NSH] supports TLV
options whose form is identical to that for Geneve options.
Generic Tunnel Option 0 Field
Name: tun_metadata0
Width: 992 bits (124 bytes)
Format: hexadecimal
Masking: arbitrary bitwise masks
Prerequisites: none
Access: read/write
OpenFlow 1.0: not supported
OpenFlow 1.1: not supported
OXM: none
NXM: NXM_NX_TUN_METADATA0 (40) since Open vSwitch 2.5
The above information specifically covers generic tunnel option
0, but Open vSwitch supports 64 options, numbered 0 through 63,
whose NXM field numbers are 40 through 103.
These fields provide OpenFlow access to the generic type-length-
value options defined by the Geneve tunneling protocol or other
protocols with options in the same TLV format as Geneve options.
Each of these options has the following wire format:
header body
<-------------------> <------------------>
16 8 3 5 4×(length - 1) bytes
+-----+----+---+------+--------------------+
|class|type|res|length| value |
+-----+----+---+------+--------------------+
0
Taken together, the class and type in the option format mean that
there are about 16 million distinct kinds of TLV options, too
many to give individual OXM code points. Thus, Open vSwitch
requires the user to define the TLV options of interest, by
binding up to 64 TLV options to generic tunnel option NXM code
points. Each option may have up to 124 bytes in its body, the
maximum allowed by the TLV format, but bound options may total at
most 252 bytes of body.
Open vSwitch extensions to the OpenFlow protocol bind TLV options
to NXM code points. The ovs-ofctl(8) program offers one way to
use these extensions, e.g. to configure a mapping from a TLV
option with class 0xffff, type 0, and a body length of 4 bytes:
ovs-ofctl add-tlv-map br0 "{class=0xffff,type=0,len=4}->tun_metadata0"
Once a TLV option is properly bound, it can be accessed and
modified like any other field, e.g. to send packets that have
value 1234 for the option described above to the controller:
ovs-ofctl add-flow br0 tun_metadata0=1234,actions=controller
An option not received or not bound is matched as all zeros.
Tunnel Flags Field
Name: tun_flags
Width: 16 bits (only the least-significant 1 bits may be nonzero)
Format: tunnel flags
Masking: arbitrary bitwise masks
Prerequisites: none
Access: read/write
OpenFlow 1.0: not supported
OpenFlow 1.1: not supported
OXM: none
NXM: NXM_NX_TUN_FLAGS (104) since Open vSwitch 2.5
Flags indicating various aspects of the tunnel encapsulation.
Matches on this field are most conveniently written in terms of
symbolic names (given in the diagram below), each preceded by
either + for a flag that must be set, or - for a flag that must
be unset, without any other delimiters between the flags. Flags
not mentioned are wildcarded. For example, tun_flags=+oam matches
only OAM packets. Matches can also be written as flags/mask,
where flags and mask are 16-bit numbers in decimal or in
hexadecimal prefixed by 0x.
Currently, only one flag is defined:
oam The tunnel protocol indicated that this is an OAM
(Operations and Management) control packet.
The switch may reject matches against unknown flags.
Newer versions of Open vSwitch may introduce additional flags
with new meanings. It is therefore not recommended to use an
exact match on this field since the behavior of these new flags
is unknown and should be ignored.
For non-tunneled packets, the value is 0.
