`ovs-fields` ( 7 )

поля заголовка протокола в OpenFlow и Open vSwitch (protocol header fields in OpenFlow and Open vSwitch)

TUNNEL FIELDS

Формат

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:

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:

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:

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:

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.

Исходный текст на man7.org

ovs-fields ( 7 )

TUNNEL FIELDS

`ovs-fields` ( 7 )