2
0
mirror of https://github.com/openvswitch/ovs synced 2025-08-22 18:07:40 +00:00
ovs/lib/flow.c

3740 lines
126 KiB
C
Raw Normal View History

/*
flow: Avoid unsafe comparison of minimasks. The following, run inside the OVS sandbox, caused OVS to abort when Address Sanitizer was used: ovs-vsctl add-br br-int ovs-ofctl add-flow br-int "table=0,cookie=0x1234,priority=10000,icmp,actions=drop" ovs-ofctl --strict del-flows br-int "table=0,cookie=0x1234/-1,priority=10000" Sample report from Address Sanitizer: ==3029==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x603000043260 at pc 0x7f6b09c2459b bp 0x7ffcb67e7540 sp 0x7ffcb67e6cf0 READ of size 40 at 0x603000043260 thread T0 #0 0x7f6b09c2459a (/lib/x86_64-linux-gnu/libasan.so.5+0xb859a) #1 0x565110a748a5 in minimask_equal ../lib/flow.c:3510 #2 0x565110a9ea41 in minimatch_equal ../lib/match.c:1821 #3 0x56511091e864 in collect_rules_strict ../ofproto/ofproto.c:4516 #4 0x56511093d526 in delete_flow_start_strict ../ofproto/ofproto.c:5959 #5 0x56511093d526 in ofproto_flow_mod_start ../ofproto/ofproto.c:7949 #6 0x56511093d77b in handle_flow_mod__ ../ofproto/ofproto.c:6122 #7 0x56511093db71 in handle_flow_mod ../ofproto/ofproto.c:6099 #8 0x5651109407f6 in handle_single_part_openflow ../ofproto/ofproto.c:8406 #9 0x5651109407f6 in handle_openflow ../ofproto/ofproto.c:8587 #10 0x5651109e40da in ofconn_run ../ofproto/connmgr.c:1318 #11 0x5651109e40da in connmgr_run ../ofproto/connmgr.c:355 #12 0x56511092b129 in ofproto_run ../ofproto/ofproto.c:1826 #13 0x5651108f23cd in bridge_run__ ../vswitchd/bridge.c:2965 #14 0x565110904887 in bridge_run ../vswitchd/bridge.c:3023 #15 0x5651108e659c in main ../vswitchd/ovs-vswitchd.c:127 #16 0x7f6b093b709a in __libc_start_main ../csu/libc-start.c:308 #17 0x5651108e9009 in _start (/home/blp/nicira/ovs/_build/vswitchd/ovs-vswitchd+0x11d009) This fixes the problem, which although largely theoretical could crop up with odd implementations of memcmp(), perhaps ones optimized in various "clever" ways. All in all, it seems best to avoid the theoretical problem. Acked-by: Dumitru Ceara <dceara@redhat.com> Signed-off-by: Ben Pfaff <blp@ovn.org>
2019-07-17 10:55:16 -07:00
* Copyright (c) 2008, 2009, 2010, 2011, 2012, 2013, 2014, 2015, 2017, 2019 Nicira, Inc.
*
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at:
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an "AS IS" BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*/
#include <config.h>
#include <sys/types.h>
#include "flow.h"
#include <errno.h>
#include <inttypes.h>
#include <limits.h>
#include <net/if.h>
#include <netinet/in.h>
#include <netinet/icmp6.h>
#include <netinet/ip6.h>
#include <stdint.h>
#include <stdlib.h>
#include <string.h>
#include "byte-order.h"
#include "colors.h"
#include "coverage.h"
#include "csum.h"
#include "openvswitch/dynamic-string.h"
#include "hash.h"
#include "jhash.h"
#include "openvswitch/match.h"
#include "dp-packet.h"
#include "openflow/openflow.h"
#include "packets.h"
#include "odp-util.h"
#include "random.h"
#include "unaligned.h"
#include "util.h"
#include "openvswitch/nsh.h"
#include "ovs-router.h"
#include "lib/netdev-provider.h"
#include "openvswitch/vlog.h"
VLOG_DEFINE_THIS_MODULE(flow);
COVERAGE_DEFINE(flow_extract);
COVERAGE_DEFINE(miniflow_extract_ipv4_pkt_len_error);
COVERAGE_DEFINE(miniflow_extract_ipv4_pkt_too_short);
COVERAGE_DEFINE(miniflow_extract_ipv6_pkt_len_error);
COVERAGE_DEFINE(miniflow_extract_ipv6_pkt_too_short);
COVERAGE_DEFINE(miniflow_malloc);
/* U64 indices for segmented flow classification. */
const uint8_t flow_segment_u64s[4] = {
FLOW_SEGMENT_1_ENDS_AT / sizeof(uint64_t),
FLOW_SEGMENT_2_ENDS_AT / sizeof(uint64_t),
FLOW_SEGMENT_3_ENDS_AT / sizeof(uint64_t),
FLOW_U64S
};
int flow_vlan_limit = FLOW_MAX_VLAN_HEADERS;
/* Asserts that field 'f1' follows immediately after 'f0' in struct flow,
* without any intervening padding. */
#define ASSERT_SEQUENTIAL(f0, f1) \
BUILD_ASSERT_DECL(offsetof(struct flow, f0) \
+ MEMBER_SIZEOF(struct flow, f0) \
== offsetof(struct flow, f1))
/* Asserts that fields 'f0' and 'f1' are in the same 32-bit aligned word within
* struct flow. */
#define ASSERT_SAME_WORD(f0, f1) \
BUILD_ASSERT_DECL(offsetof(struct flow, f0) / 4 \
== offsetof(struct flow, f1) / 4)
/* Asserts that 'f0' and 'f1' are both sequential and within the same 32-bit
* aligned word in struct flow. */
#define ASSERT_SEQUENTIAL_SAME_WORD(f0, f1) \
ASSERT_SEQUENTIAL(f0, f1); \
ASSERT_SAME_WORD(f0, f1)
/* miniflow_extract() assumes the following to be true to optimize the
* extraction process. */
ASSERT_SEQUENTIAL_SAME_WORD(nw_frag, nw_tos);
ASSERT_SEQUENTIAL_SAME_WORD(nw_tos, nw_ttl);
ASSERT_SEQUENTIAL_SAME_WORD(nw_ttl, nw_proto);
/* TCP flags in the middle of a BE64, zeroes in the other half. */
BUILD_ASSERT_DECL(offsetof(struct flow, tcp_flags) % 8 == 4);
#if WORDS_BIGENDIAN
#define TCP_FLAGS_BE32(tcp_ctl) ((OVS_FORCE ovs_be32)TCP_FLAGS_BE16(tcp_ctl) \
<< 16)
#else
#define TCP_FLAGS_BE32(tcp_ctl) ((OVS_FORCE ovs_be32)TCP_FLAGS_BE16(tcp_ctl))
#endif
ASSERT_SEQUENTIAL_SAME_WORD(tp_src, tp_dst);
/* Removes 'size' bytes from the head end of '*datap', of size '*sizep', which
* must contain at least 'size' bytes of data. Returns the first byte of data
* removed. */
static inline const void *
data_pull(const void **datap, size_t *sizep, size_t size)
{
const char *data = *datap;
*datap = data + size;
*sizep -= size;
return data;
}
/* If '*datap' has at least 'size' bytes of data, removes that many bytes from
* the head end of '*datap' and returns the first byte removed. Otherwise,
* returns a null pointer without modifying '*datap'. */
static inline const void *
data_try_pull(const void **datap, size_t *sizep, size_t size)
{
return OVS_LIKELY(*sizep >= size) ? data_pull(datap, sizep, size) : NULL;
}
/* Context for pushing data to a miniflow. */
struct mf_ctx {
struct flowmap map;
uint64_t *data;
uint64_t * const end;
};
/* miniflow_push_* macros allow filling in a miniflow data values in order.
* Assertions are needed only when the layout of the struct flow is modified.
* 'ofs' is a compile-time constant, which allows most of the code be optimized
* away. Some GCC versions gave warnings on ALWAYS_INLINE, so these are
* defined as macros. */
#if (FLOW_WC_SEQ != 42)
#define MINIFLOW_ASSERT(X) ovs_assert(X)
BUILD_MESSAGE("FLOW_WC_SEQ changed: miniflow_extract() will have runtime "
"assertions enabled. Consider updating FLOW_WC_SEQ after "
"testing")
#else
#define MINIFLOW_ASSERT(X)
#endif
/* True if 'IDX' and higher bits are not set. */
#define ASSERT_FLOWMAP_NOT_SET(FM, IDX) \
{ \
MINIFLOW_ASSERT(!((FM)->bits[(IDX) / MAP_T_BITS] & \
(MAP_MAX << ((IDX) % MAP_T_BITS)))); \
for (size_t i = (IDX) / MAP_T_BITS + 1; i < FLOWMAP_UNITS; i++) { \
MINIFLOW_ASSERT(!(FM)->bits[i]); \
} \
}
#define miniflow_set_map(MF, OFS) \
{ \
ASSERT_FLOWMAP_NOT_SET(&MF.map, (OFS)); \
flowmap_set(&MF.map, (OFS), 1); \
}
#define miniflow_assert_in_map(MF, OFS) \
MINIFLOW_ASSERT(flowmap_is_set(&MF.map, (OFS))); \
ASSERT_FLOWMAP_NOT_SET(&MF.map, (OFS) + 1)
#define miniflow_push_uint64_(MF, OFS, VALUE) \
{ \
MINIFLOW_ASSERT(MF.data < MF.end && (OFS) % 8 == 0); \
*MF.data++ = VALUE; \
miniflow_set_map(MF, OFS / 8); \
}
#define miniflow_push_be64_(MF, OFS, VALUE) \
miniflow_push_uint64_(MF, OFS, (OVS_FORCE uint64_t)(VALUE))
#define miniflow_push_uint32_(MF, OFS, VALUE) \
{ \
MINIFLOW_ASSERT(MF.data < MF.end); \
\
if ((OFS) % 8 == 0) { \
miniflow_set_map(MF, OFS / 8); \
*(uint32_t *)MF.data = VALUE; \
} else if ((OFS) % 8 == 4) { \
miniflow_assert_in_map(MF, OFS / 8); \
*((uint32_t *)MF.data + 1) = VALUE; \
MF.data++; \
} \
}
#define miniflow_push_be32_(MF, OFS, VALUE) \
miniflow_push_uint32_(MF, OFS, (OVS_FORCE uint32_t)(VALUE))
#define miniflow_push_uint16_(MF, OFS, VALUE) \
{ \
MINIFLOW_ASSERT(MF.data < MF.end); \
\
if ((OFS) % 8 == 0) { \
miniflow_set_map(MF, OFS / 8); \
*(uint16_t *)MF.data = VALUE; \
} else if ((OFS) % 8 == 2) { \
miniflow_assert_in_map(MF, OFS / 8); \
*((uint16_t *)MF.data + 1) = VALUE; \
} else if ((OFS) % 8 == 4) { \
miniflow_assert_in_map(MF, OFS / 8); \
*((uint16_t *)MF.data + 2) = VALUE; \
} else if ((OFS) % 8 == 6) { \
miniflow_assert_in_map(MF, OFS / 8); \
*((uint16_t *)MF.data + 3) = VALUE; \
MF.data++; \
} \
}
#define miniflow_push_uint8_(MF, OFS, VALUE) \
{ \
MINIFLOW_ASSERT(MF.data < MF.end); \
\
if ((OFS) % 8 == 0) { \
miniflow_set_map(MF, OFS / 8); \
*(uint8_t *)MF.data = VALUE; \
} else if ((OFS) % 8 == 7) { \
miniflow_assert_in_map(MF, OFS / 8); \
*((uint8_t *)MF.data + 7) = VALUE; \
MF.data++; \
} else { \
miniflow_assert_in_map(MF, OFS / 8); \
*((uint8_t *)MF.data + ((OFS) % 8)) = VALUE; \
} \
}
#define miniflow_pad_to_64_(MF, OFS) \
{ \
MINIFLOW_ASSERT((OFS) % 8 != 0); \
miniflow_assert_in_map(MF, OFS / 8); \
\
memset((uint8_t *)MF.data + (OFS) % 8, 0, 8 - (OFS) % 8); \
MF.data++; \
}
#define miniflow_pad_from_64_(MF, OFS) \
{ \
MINIFLOW_ASSERT(MF.data < MF.end); \
\
MINIFLOW_ASSERT((OFS) % 8 != 0); \
miniflow_set_map(MF, OFS / 8); \
\
memset((uint8_t *)MF.data, 0, (OFS) % 8); \
}
#define miniflow_push_be16_(MF, OFS, VALUE) \
miniflow_push_uint16_(MF, OFS, (OVS_FORCE uint16_t)VALUE);
#define miniflow_push_be8_(MF, OFS, VALUE) \
miniflow_push_uint8_(MF, OFS, (OVS_FORCE uint8_t)VALUE);
#define miniflow_set_maps(MF, OFS, N_WORDS) \
{ \
size_t ofs = (OFS); \
size_t n_words = (N_WORDS); \
\
MINIFLOW_ASSERT(n_words && MF.data + n_words <= MF.end); \
ASSERT_FLOWMAP_NOT_SET(&MF.map, ofs); \
flowmap_set(&MF.map, ofs, n_words); \
}
/* Data at 'valuep' may be unaligned. */
#define miniflow_push_words_(MF, OFS, VALUEP, N_WORDS) \
{ \
MINIFLOW_ASSERT((OFS) % 8 == 0); \
miniflow_set_maps(MF, (OFS) / 8, (N_WORDS)); \
memcpy(MF.data, (VALUEP), (N_WORDS) * sizeof *MF.data); \
MF.data += (N_WORDS); \
}
/* Push 32-bit words padded to 64-bits. */
#define miniflow_push_words_32_(MF, OFS, VALUEP, N_WORDS) \
{ \
miniflow_set_maps(MF, (OFS) / 8, DIV_ROUND_UP(N_WORDS, 2)); \
memcpy(MF.data, (VALUEP), (N_WORDS) * sizeof(uint32_t)); \
MF.data += DIV_ROUND_UP(N_WORDS, 2); \
if ((N_WORDS) & 1) { \
*((uint32_t *)MF.data - 1) = 0; \
} \
}
datapath: Fix handling of 802.1Q and SNAP headers. The kernel and user datapaths have code that assumes that 802.1Q headers are used only inside Ethernet II frames, not inside SNAP-encapsulated frames. But the kernel and user flow_extract() implementations would interpret 802.1Q headers inside SNAP headers as being valid VLANs. This would cause packet corruption if any VLAN-related actions were to be taken, so change the two flow_extract() implementations only to accept 802.1Q as an Ethernet II frame type, not as a SNAP-encoded frame type. 802.1Q-2005 says that this is correct anyhow: Where the ISS instance used to transmit and receive tagged frames is provided by a media access control method that can support Ethernet Type encoding directly (e.g., is an IEEE 802.3 or IEEE 802.11 MAC) or is media access method independent (e.g., 6.6), the TPID is Ethernet Type encoded, i.e., is two octets in length and comprises solely the assigned Ethernet Type value. Where the ISS instance is provided by a media access method that cannot directly support Ethernet Type encoding (e.g., is an IEEE 802.5 or FDDI MAC), the TPID is encoded according to the rule for a Subnetwork Access Protocol (Clause 10 of IEEE Std 802) that encapsulates Ethernet frames over LLC, and comprises the SNAP header (AA-AA-03) followed by the SNAP PID (00-00-00) followed by the two octets of the assigned Ethernet Type value. All of the media that OVS handles supports Ethernet Type fields, so to me that means that we don't have to handle 802.1Q-inside-SNAP. On the other hand, we *do* have to handle SNAP-inside-802.1Q, because this is actually allowed by the standards. So this commit also adds that support. I verified that, with this change, both SNAP and Ethernet packets are properly recognized both with and without 802.1Q encapsulation. I was a bit surprised to find out that Linux does not accept SNAP-encapsulated IP frames on Ethernet. Here's a summary of how frames are handled before and after this commit: Common cases ------------ Ethernet +------------+ 1. |dst|src|TYPE| +------------+ Ethernet LLC SNAP +------------+ +--------+ +-----------+ 2. |dst|src| len| |aa|aa|03| |000000|TYPE| +------------+ +--------+ +-----------+ Ethernet 802.1Q +------------+ +---------+ 3. |dst|src|8100| |VLAN|TYPE| +------------+ +---------+ Ethernet 802.1Q LLC SNAP +------------+ +---------+ +--------+ +-----------+ 4. |dst|src|8100| |VLAN| LEN| |aa|aa|03| |000000|TYPE| +------------+ +---------+ +--------+ +-----------+ Unusual cases ------------- Ethernet LLC SNAP 802.1Q +------------+ +--------+ +-----------+ +---------+ 5. |dst|src| len| |aa|aa|03| |000000|8100| |VLAN|TYPE| +------------+ +--------+ +-----------+ +---------+ Ethernet LLC +------------+ +--------+ 6. |dst|src| len| |xx|xx|xx| +------------+ +--------+ Ethernet LLC SNAP +------------+ +--------+ +-----------+ 7. |dst|src| len| |aa|aa|03| |xxxxxx|xxxx| +------------+ +--------+ +-----------+ Ethernet 802.1Q LLC +------------+ +---------+ +--------+ 8. |dst|src|8100| |VLAN| LEN| |xx|xx|xx| +------------+ +---------+ +--------+ Ethernet 802.1Q LLC SNAP +------------+ +---------+ +--------+ +-----------+ 9. |dst|src|8100| |VLAN| LEN| |aa|aa|03| |xxxxxx|xxxx| +------------+ +---------+ +--------+ +-----------+ Behavior -------- --------------- --------------- ------------------------------------- Before After this commit this commit dl_type dl_vlan dl_type dl_vlan Notes ------- ------- ------- ------- ------------------------------------- 1. TYPE ffff TYPE ffff no change 2. TYPE ffff TYPE ffff no change 3. TYPE VLAN TYPE VLAN no change 4. LEN VLAN TYPE VLAN proposal fixes behavior 5. TYPE VLAN 8100 ffff 802.1Q says this is invalid framing 6. 05ff ffff 05ff ffff no change 7. 05ff ffff 05ff ffff no change 8. LEN VLAN 05ff VLAN proposal fixes behavior 9. LEN VLAN 05ff VLAN proposal fixes behavior Signed-off-by: Ben Pfaff <blp@nicira.com>
2010-08-10 11:35:46 -07:00
/* Data at 'valuep' may be unaligned. */
/* MACs start 64-aligned, and must be followed by other data or padding. */
#define miniflow_push_macs_(MF, OFS, VALUEP) \
{ \
miniflow_set_maps(MF, (OFS) / 8, 2); \
memcpy(MF.data, (VALUEP), 2 * ETH_ADDR_LEN); \
MF.data += 1; /* First word only. */ \
}
datapath: Fix handling of 802.1Q and SNAP headers. The kernel and user datapaths have code that assumes that 802.1Q headers are used only inside Ethernet II frames, not inside SNAP-encapsulated frames. But the kernel and user flow_extract() implementations would interpret 802.1Q headers inside SNAP headers as being valid VLANs. This would cause packet corruption if any VLAN-related actions were to be taken, so change the two flow_extract() implementations only to accept 802.1Q as an Ethernet II frame type, not as a SNAP-encoded frame type. 802.1Q-2005 says that this is correct anyhow: Where the ISS instance used to transmit and receive tagged frames is provided by a media access control method that can support Ethernet Type encoding directly (e.g., is an IEEE 802.3 or IEEE 802.11 MAC) or is media access method independent (e.g., 6.6), the TPID is Ethernet Type encoded, i.e., is two octets in length and comprises solely the assigned Ethernet Type value. Where the ISS instance is provided by a media access method that cannot directly support Ethernet Type encoding (e.g., is an IEEE 802.5 or FDDI MAC), the TPID is encoded according to the rule for a Subnetwork Access Protocol (Clause 10 of IEEE Std 802) that encapsulates Ethernet frames over LLC, and comprises the SNAP header (AA-AA-03) followed by the SNAP PID (00-00-00) followed by the two octets of the assigned Ethernet Type value. All of the media that OVS handles supports Ethernet Type fields, so to me that means that we don't have to handle 802.1Q-inside-SNAP. On the other hand, we *do* have to handle SNAP-inside-802.1Q, because this is actually allowed by the standards. So this commit also adds that support. I verified that, with this change, both SNAP and Ethernet packets are properly recognized both with and without 802.1Q encapsulation. I was a bit surprised to find out that Linux does not accept SNAP-encapsulated IP frames on Ethernet. Here's a summary of how frames are handled before and after this commit: Common cases ------------ Ethernet +------------+ 1. |dst|src|TYPE| +------------+ Ethernet LLC SNAP +------------+ +--------+ +-----------+ 2. |dst|src| len| |aa|aa|03| |000000|TYPE| +------------+ +--------+ +-----------+ Ethernet 802.1Q +------------+ +---------+ 3. |dst|src|8100| |VLAN|TYPE| +------------+ +---------+ Ethernet 802.1Q LLC SNAP +------------+ +---------+ +--------+ +-----------+ 4. |dst|src|8100| |VLAN| LEN| |aa|aa|03| |000000|TYPE| +------------+ +---------+ +--------+ +-----------+ Unusual cases ------------- Ethernet LLC SNAP 802.1Q +------------+ +--------+ +-----------+ +---------+ 5. |dst|src| len| |aa|aa|03| |000000|8100| |VLAN|TYPE| +------------+ +--------+ +-----------+ +---------+ Ethernet LLC +------------+ +--------+ 6. |dst|src| len| |xx|xx|xx| +------------+ +--------+ Ethernet LLC SNAP +------------+ +--------+ +-----------+ 7. |dst|src| len| |aa|aa|03| |xxxxxx|xxxx| +------------+ +--------+ +-----------+ Ethernet 802.1Q LLC +------------+ +---------+ +--------+ 8. |dst|src|8100| |VLAN| LEN| |xx|xx|xx| +------------+ +---------+ +--------+ Ethernet 802.1Q LLC SNAP +------------+ +---------+ +--------+ +-----------+ 9. |dst|src|8100| |VLAN| LEN| |aa|aa|03| |xxxxxx|xxxx| +------------+ +---------+ +--------+ +-----------+ Behavior -------- --------------- --------------- ------------------------------------- Before After this commit this commit dl_type dl_vlan dl_type dl_vlan Notes ------- ------- ------- ------- ------------------------------------- 1. TYPE ffff TYPE ffff no change 2. TYPE ffff TYPE ffff no change 3. TYPE VLAN TYPE VLAN no change 4. LEN VLAN TYPE VLAN proposal fixes behavior 5. TYPE VLAN 8100 ffff 802.1Q says this is invalid framing 6. 05ff ffff 05ff ffff no change 7. 05ff ffff 05ff ffff no change 8. LEN VLAN 05ff VLAN proposal fixes behavior 9. LEN VLAN 05ff VLAN proposal fixes behavior Signed-off-by: Ben Pfaff <blp@nicira.com>
2010-08-10 11:35:46 -07:00
#define miniflow_push_uint32(MF, FIELD, VALUE) \
miniflow_push_uint32_(MF, offsetof(struct flow, FIELD), VALUE)
datapath: Fix handling of 802.1Q and SNAP headers. The kernel and user datapaths have code that assumes that 802.1Q headers are used only inside Ethernet II frames, not inside SNAP-encapsulated frames. But the kernel and user flow_extract() implementations would interpret 802.1Q headers inside SNAP headers as being valid VLANs. This would cause packet corruption if any VLAN-related actions were to be taken, so change the two flow_extract() implementations only to accept 802.1Q as an Ethernet II frame type, not as a SNAP-encoded frame type. 802.1Q-2005 says that this is correct anyhow: Where the ISS instance used to transmit and receive tagged frames is provided by a media access control method that can support Ethernet Type encoding directly (e.g., is an IEEE 802.3 or IEEE 802.11 MAC) or is media access method independent (e.g., 6.6), the TPID is Ethernet Type encoded, i.e., is two octets in length and comprises solely the assigned Ethernet Type value. Where the ISS instance is provided by a media access method that cannot directly support Ethernet Type encoding (e.g., is an IEEE 802.5 or FDDI MAC), the TPID is encoded according to the rule for a Subnetwork Access Protocol (Clause 10 of IEEE Std 802) that encapsulates Ethernet frames over LLC, and comprises the SNAP header (AA-AA-03) followed by the SNAP PID (00-00-00) followed by the two octets of the assigned Ethernet Type value. All of the media that OVS handles supports Ethernet Type fields, so to me that means that we don't have to handle 802.1Q-inside-SNAP. On the other hand, we *do* have to handle SNAP-inside-802.1Q, because this is actually allowed by the standards. So this commit also adds that support. I verified that, with this change, both SNAP and Ethernet packets are properly recognized both with and without 802.1Q encapsulation. I was a bit surprised to find out that Linux does not accept SNAP-encapsulated IP frames on Ethernet. Here's a summary of how frames are handled before and after this commit: Common cases ------------ Ethernet +------------+ 1. |dst|src|TYPE| +------------+ Ethernet LLC SNAP +------------+ +--------+ +-----------+ 2. |dst|src| len| |aa|aa|03| |000000|TYPE| +------------+ +--------+ +-----------+ Ethernet 802.1Q +------------+ +---------+ 3. |dst|src|8100| |VLAN|TYPE| +------------+ +---------+ Ethernet 802.1Q LLC SNAP +------------+ +---------+ +--------+ +-----------+ 4. |dst|src|8100| |VLAN| LEN| |aa|aa|03| |000000|TYPE| +------------+ +---------+ +--------+ +-----------+ Unusual cases ------------- Ethernet LLC SNAP 802.1Q +------------+ +--------+ +-----------+ +---------+ 5. |dst|src| len| |aa|aa|03| |000000|8100| |VLAN|TYPE| +------------+ +--------+ +-----------+ +---------+ Ethernet LLC +------------+ +--------+ 6. |dst|src| len| |xx|xx|xx| +------------+ +--------+ Ethernet LLC SNAP +------------+ +--------+ +-----------+ 7. |dst|src| len| |aa|aa|03| |xxxxxx|xxxx| +------------+ +--------+ +-----------+ Ethernet 802.1Q LLC +------------+ +---------+ +--------+ 8. |dst|src|8100| |VLAN| LEN| |xx|xx|xx| +------------+ +---------+ +--------+ Ethernet 802.1Q LLC SNAP +------------+ +---------+ +--------+ +-----------+ 9. |dst|src|8100| |VLAN| LEN| |aa|aa|03| |xxxxxx|xxxx| +------------+ +---------+ +--------+ +-----------+ Behavior -------- --------------- --------------- ------------------------------------- Before After this commit this commit dl_type dl_vlan dl_type dl_vlan Notes ------- ------- ------- ------- ------------------------------------- 1. TYPE ffff TYPE ffff no change 2. TYPE ffff TYPE ffff no change 3. TYPE VLAN TYPE VLAN no change 4. LEN VLAN TYPE VLAN proposal fixes behavior 5. TYPE VLAN 8100 ffff 802.1Q says this is invalid framing 6. 05ff ffff 05ff ffff no change 7. 05ff ffff 05ff ffff no change 8. LEN VLAN 05ff VLAN proposal fixes behavior 9. LEN VLAN 05ff VLAN proposal fixes behavior Signed-off-by: Ben Pfaff <blp@nicira.com>
2010-08-10 11:35:46 -07:00
#define miniflow_push_be32(MF, FIELD, VALUE) \
miniflow_push_be32_(MF, offsetof(struct flow, FIELD), VALUE)
datapath: Fix handling of 802.1Q and SNAP headers. The kernel and user datapaths have code that assumes that 802.1Q headers are used only inside Ethernet II frames, not inside SNAP-encapsulated frames. But the kernel and user flow_extract() implementations would interpret 802.1Q headers inside SNAP headers as being valid VLANs. This would cause packet corruption if any VLAN-related actions were to be taken, so change the two flow_extract() implementations only to accept 802.1Q as an Ethernet II frame type, not as a SNAP-encoded frame type. 802.1Q-2005 says that this is correct anyhow: Where the ISS instance used to transmit and receive tagged frames is provided by a media access control method that can support Ethernet Type encoding directly (e.g., is an IEEE 802.3 or IEEE 802.11 MAC) or is media access method independent (e.g., 6.6), the TPID is Ethernet Type encoded, i.e., is two octets in length and comprises solely the assigned Ethernet Type value. Where the ISS instance is provided by a media access method that cannot directly support Ethernet Type encoding (e.g., is an IEEE 802.5 or FDDI MAC), the TPID is encoded according to the rule for a Subnetwork Access Protocol (Clause 10 of IEEE Std 802) that encapsulates Ethernet frames over LLC, and comprises the SNAP header (AA-AA-03) followed by the SNAP PID (00-00-00) followed by the two octets of the assigned Ethernet Type value. All of the media that OVS handles supports Ethernet Type fields, so to me that means that we don't have to handle 802.1Q-inside-SNAP. On the other hand, we *do* have to handle SNAP-inside-802.1Q, because this is actually allowed by the standards. So this commit also adds that support. I verified that, with this change, both SNAP and Ethernet packets are properly recognized both with and without 802.1Q encapsulation. I was a bit surprised to find out that Linux does not accept SNAP-encapsulated IP frames on Ethernet. Here's a summary of how frames are handled before and after this commit: Common cases ------------ Ethernet +------------+ 1. |dst|src|TYPE| +------------+ Ethernet LLC SNAP +------------+ +--------+ +-----------+ 2. |dst|src| len| |aa|aa|03| |000000|TYPE| +------------+ +--------+ +-----------+ Ethernet 802.1Q +------------+ +---------+ 3. |dst|src|8100| |VLAN|TYPE| +------------+ +---------+ Ethernet 802.1Q LLC SNAP +------------+ +---------+ +--------+ +-----------+ 4. |dst|src|8100| |VLAN| LEN| |aa|aa|03| |000000|TYPE| +------------+ +---------+ +--------+ +-----------+ Unusual cases ------------- Ethernet LLC SNAP 802.1Q +------------+ +--------+ +-----------+ +---------+ 5. |dst|src| len| |aa|aa|03| |000000|8100| |VLAN|TYPE| +------------+ +--------+ +-----------+ +---------+ Ethernet LLC +------------+ +--------+ 6. |dst|src| len| |xx|xx|xx| +------------+ +--------+ Ethernet LLC SNAP +------------+ +--------+ +-----------+ 7. |dst|src| len| |aa|aa|03| |xxxxxx|xxxx| +------------+ +--------+ +-----------+ Ethernet 802.1Q LLC +------------+ +---------+ +--------+ 8. |dst|src|8100| |VLAN| LEN| |xx|xx|xx| +------------+ +---------+ +--------+ Ethernet 802.1Q LLC SNAP +------------+ +---------+ +--------+ +-----------+ 9. |dst|src|8100| |VLAN| LEN| |aa|aa|03| |xxxxxx|xxxx| +------------+ +---------+ +--------+ +-----------+ Behavior -------- --------------- --------------- ------------------------------------- Before After this commit this commit dl_type dl_vlan dl_type dl_vlan Notes ------- ------- ------- ------- ------------------------------------- 1. TYPE ffff TYPE ffff no change 2. TYPE ffff TYPE ffff no change 3. TYPE VLAN TYPE VLAN no change 4. LEN VLAN TYPE VLAN proposal fixes behavior 5. TYPE VLAN 8100 ffff 802.1Q says this is invalid framing 6. 05ff ffff 05ff ffff no change 7. 05ff ffff 05ff ffff no change 8. LEN VLAN 05ff VLAN proposal fixes behavior 9. LEN VLAN 05ff VLAN proposal fixes behavior Signed-off-by: Ben Pfaff <blp@nicira.com>
2010-08-10 11:35:46 -07:00
#define miniflow_push_uint16(MF, FIELD, VALUE) \
miniflow_push_uint16_(MF, offsetof(struct flow, FIELD), VALUE)
#define miniflow_push_be16(MF, FIELD, VALUE) \
miniflow_push_be16_(MF, offsetof(struct flow, FIELD), VALUE)
#define miniflow_push_uint8(MF, FIELD, VALUE) \
miniflow_push_uint8_(MF, offsetof(struct flow, FIELD), VALUE)
#define miniflow_pad_to_64(MF, FIELD) \
miniflow_pad_to_64_(MF, OFFSETOFEND(struct flow, FIELD))
#define miniflow_pad_from_64(MF, FIELD) \
miniflow_pad_from_64_(MF, offsetof(struct flow, FIELD))
#define miniflow_push_words(MF, FIELD, VALUEP, N_WORDS) \
miniflow_push_words_(MF, offsetof(struct flow, FIELD), VALUEP, N_WORDS)
#define miniflow_push_words_32(MF, FIELD, VALUEP, N_WORDS) \
miniflow_push_words_32_(MF, offsetof(struct flow, FIELD), VALUEP, N_WORDS)
#define miniflow_push_macs(MF, FIELD, VALUEP) \
miniflow_push_macs_(MF, offsetof(struct flow, FIELD), VALUEP)
/* Return the pointer to the miniflow data when called BEFORE the corresponding
* push. */
#define miniflow_pointer(MF, FIELD) \
(void *)((uint8_t *)MF.data + ((offsetof(struct flow, FIELD)) % 8))
/* Pulls the MPLS headers at '*datap' and returns the count of them. */
static inline int
parse_mpls(const void **datap, size_t *sizep)
{
const struct mpls_hdr *mh;
int count = 0;
while ((mh = data_try_pull(datap, sizep, sizeof *mh))) {
count++;
if (mh->mpls_lse.lo & htons(1 << MPLS_BOS_SHIFT)) {
break;
}
}
return MIN(count, FLOW_MAX_MPLS_LABELS);
}
/* passed vlan_hdrs arg must be at least size FLOW_MAX_VLAN_HEADERS. */
static inline ALWAYS_INLINE size_t
parse_vlan(const void **datap, size_t *sizep, union flow_vlan_hdr *vlan_hdrs)
{
const ovs_be16 *eth_type;
data_pull(datap, sizep, ETH_ADDR_LEN * 2);
eth_type = *datap;
size_t n;
for (n = 0; eth_type_vlan(*eth_type) && n < flow_vlan_limit; n++) {
if (OVS_UNLIKELY(*sizep < sizeof(ovs_be32) + sizeof(ovs_be16))) {
break;
}
memset(vlan_hdrs + n, 0, sizeof(union flow_vlan_hdr));
const ovs_16aligned_be32 *qp = data_pull(datap, sizep, sizeof *qp);
vlan_hdrs[n].qtag = get_16aligned_be32(qp);
vlan_hdrs[n].tci |= htons(VLAN_CFI);
eth_type = *datap;
}
return n;
}
static inline ALWAYS_INLINE ovs_be16
parse_ethertype(const void **datap, size_t *sizep)
{
const struct llc_snap_header *llc;
ovs_be16 proto;
proto = *(ovs_be16 *) data_pull(datap, sizep, sizeof proto);
if (OVS_LIKELY(ntohs(proto) >= ETH_TYPE_MIN)) {
return proto;
}
if (OVS_UNLIKELY(*sizep < sizeof *llc)) {
return htons(FLOW_DL_TYPE_NONE);
}
llc = *datap;
if (OVS_UNLIKELY(llc->llc.llc_dsap != LLC_DSAP_SNAP
|| llc->llc.llc_ssap != LLC_SSAP_SNAP
|| llc->llc.llc_cntl != LLC_CNTL_SNAP
|| memcmp(llc->snap.snap_org, SNAP_ORG_ETHERNET,
sizeof llc->snap.snap_org))) {
return htons(FLOW_DL_TYPE_NONE);
}
data_pull(datap, sizep, sizeof *llc);
if (OVS_LIKELY(ntohs(llc->snap.snap_type) >= ETH_TYPE_MIN)) {
return llc->snap.snap_type;
}
return htons(FLOW_DL_TYPE_NONE);
}
static inline bool
icmp6_is_nd(const struct icmp6_data_header *icmp6)
{
return (icmp6->icmp6_base.icmp6_code == 0 &&
(icmp6->icmp6_base.icmp6_type == ND_NEIGHBOR_SOLICIT ||
icmp6->icmp6_base.icmp6_type == ND_NEIGHBOR_ADVERT));
}
/* Returns 'true' if the packet is an ND packet. In that case the '*nd_target'
* and 'arp_buf[]' are filled in. If the packet is not an ND packet, 'false'
* is returned and no values are filled in on '*nd_target' or 'arp_buf[]'. */
static inline bool
parse_icmpv6(const void **datap, size_t *sizep,
const struct icmp6_data_header *icmp6,
flow: Fix unaligned access to the ND target in miniflow_extract. The data in the buffer are aligned to 2 bytes, however 'struct in6_addr' is aligned to 4 bytes. Use the 2 bytes aligned equivalent 'union ovs_16aligned_in6_addr' instead. This was caught by one of the OVN tests: lib/flow.c:1133:25: runtime error: load of misaligned address 0x51400009cc92 for type 'const struct in6_addr *', which requires 4 byte alignment 0x51400009cc92: note: pointer points here 00 00 00 00 10 00 00 00 00 00 00 00 00 00 00 00 00 00 ^ 0 0x8255b2 in miniflow_extract lib/flow.c:1133:25 1 0x81d921 in flow_extract lib/flow.c:671:5 2 0xa966d4 in ofp_packet_to_string lib/ofp-print.c:82:5 3 0xa76de2 in ofputil_packet_in_private_format lib/ofp-packet.c:1037:24 4 0xa99817 in ofp_print_packet_in lib/ofp-print.c:132:9 5 0xa97f46 in ofp_to_string__ lib/ofp-print.c 6 0xa97f46 in ofp_to_string lib/ofp-print.c:1264:21 7 0xc338f4 in do_send lib/vconn.c:687:19 8 0xb7f678 in try_send lib/rconn.c:1128:14 9 0xb7d725 in rconn_send__ lib/rconn.c:760:13 10 0xb7d8e7 in rconn_send_with_limit lib/rconn.c:816:17 11 0x6f70de in do_send_packet_ins ofproto/connmgr.c:1697:13 12 0x6f691f in connmgr_send_async_msg ofproto/connmgr.c:1682:9 13 0x5c2d23 in run ofproto/ofproto-dpif.c:1877:13 14 0x56737f in ofproto_run ofproto/ofproto.c:1906:13 15 0x50d4fc in bridge_run__ vswitchd/bridge.c:3287:9 16 0x50a764 in bridge_run vswitchd/bridge.c:3346:5 17 0x53eed7 in main vswitchd/ovs-vswitchd.c:130:9 Acked-by: Simon Horman <horms@ovn.org> Signed-off-by: Ales Musil <amusil@redhat.com> Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
2024-07-16 13:45:53 +02:00
ovs_be32 *rso_flags,
const union ovs_16aligned_in6_addr **nd_target,
struct eth_addr arp_buf[2], uint8_t *opt_type)
{
if (!icmp6_is_nd(icmp6)) {
return false;
}
arp_buf[0] = eth_addr_zero;
arp_buf[1] = eth_addr_zero;
*opt_type = 0;
*rso_flags = get_16aligned_be32(icmp6->icmp6_data.be32);
*nd_target = data_try_pull(datap, sizep, sizeof **nd_target);
if (OVS_UNLIKELY(!*nd_target)) {
return true;
}
while (*sizep >= 8) {
/* The minimum size of an option is 8 bytes, which also is
* the size of Ethernet link-layer options. */
const struct ovs_nd_lla_opt *lla_opt = *datap;
int opt_len = lla_opt->len * ND_LLA_OPT_LEN;
if (!opt_len || opt_len > *sizep) {
return true;
}
/* Store the link layer address if the appropriate option is
* provided. It is considered an error if the same link
* layer option is specified twice. */
if (lla_opt->type == ND_OPT_SOURCE_LINKADDR && opt_len == 8) {
if (OVS_LIKELY(eth_addr_is_zero(arp_buf[0]))) {
arp_buf[0] = lla_opt->mac;
/* We use only first option type present in ND packet. */
if (*opt_type == 0) {
*opt_type = lla_opt->type;
}
} else {
goto invalid;
}
} else if (lla_opt->type == ND_OPT_TARGET_LINKADDR && opt_len == 8) {
if (OVS_LIKELY(eth_addr_is_zero(arp_buf[1]))) {
arp_buf[1] = lla_opt->mac;
/* We use only first option type present in ND packet. */
if (*opt_type == 0) {
*opt_type = lla_opt->type;
}
} else {
goto invalid;
}
}
if (OVS_UNLIKELY(!data_try_pull(datap, sizep, opt_len))) {
return true;
}
}
return true;
invalid:
*nd_target = NULL;
arp_buf[0] = eth_addr_zero;
arp_buf[1] = eth_addr_zero;
return true;
}
static inline bool
parse_ipv6_ext_hdrs__(const void **datap, size_t *sizep, uint8_t *nw_proto,
uint8_t *nw_frag,
const struct ovs_16aligned_ip6_frag **frag_hdr,
const struct ip6_rt_hdr **rt_hdr)
{
if (frag_hdr) {
*frag_hdr = NULL;
}
if (rt_hdr) {
*rt_hdr = NULL;
}
while (1) {
if (OVS_LIKELY((*nw_proto != IPPROTO_HOPOPTS)
&& (*nw_proto != IPPROTO_ROUTING)
&& (*nw_proto != IPPROTO_DSTOPTS)
&& (*nw_proto != IPPROTO_AH)
&& (*nw_proto != IPPROTO_FRAGMENT))) {
/* It's either a terminal header (e.g., TCP, UDP) or one we
* don't understand. In either case, we're done with the
* packet, so use it to fill in 'nw_proto'. */
return true;
}
/* We only verify that at least 8 bytes of the next header are
* available, but many of these headers are longer. Ensure that
* accesses within the extension header are within those first 8
* bytes. All extension headers are required to be at least 8
* bytes. */
if (OVS_UNLIKELY(*sizep < 8)) {
return false;
}
if ((*nw_proto == IPPROTO_HOPOPTS)
|| (*nw_proto == IPPROTO_DSTOPTS)) {
/* These headers, while different, have the fields we care
* about in the same location and with the same
* interpretation. */
const struct ip6_ext *ext_hdr = *datap;
*nw_proto = ext_hdr->ip6e_nxt;
if (OVS_UNLIKELY(!data_try_pull(datap, sizep,
(ext_hdr->ip6e_len + 1) * 8))) {
return false;
}
} else if (*nw_proto == IPPROTO_ROUTING) {
const struct ip6_rt_hdr *tmp;
if (!rt_hdr) {
rt_hdr = &tmp;
}
*rt_hdr = *datap;
*nw_proto = (*rt_hdr)->nexthdr;
if (OVS_UNLIKELY(!data_try_pull(datap, sizep,
((*rt_hdr)->hdrlen + 1) * 8))) {
return false;
}
} else if (*nw_proto == IPPROTO_AH) {
/* A standard AH definition isn't available, but the fields
* we care about are in the same location as the generic
* option header--only the header length is calculated
* differently. */
const struct ip6_ext *ext_hdr = *datap;
*nw_proto = ext_hdr->ip6e_nxt;
if (OVS_UNLIKELY(!data_try_pull(datap, sizep,
(ext_hdr->ip6e_len + 2) * 4))) {
return false;
}
} else if (*nw_proto == IPPROTO_FRAGMENT) {
const struct ovs_16aligned_ip6_frag *tmp;
if (!frag_hdr) {
frag_hdr = &tmp;
}
*frag_hdr = *datap;
*nw_proto = (*frag_hdr)->ip6f_nxt;
if (!data_try_pull(datap, sizep, sizeof **frag_hdr)) {
return false;
}
/* We only process the first fragment. */
if ((*frag_hdr)->ip6f_offlg != htons(0)) {
*nw_frag = FLOW_NW_FRAG_ANY;
if (((*frag_hdr)->ip6f_offlg & IP6F_OFF_MASK) != htons(0)) {
*nw_frag |= FLOW_NW_FRAG_LATER;
*nw_proto = IPPROTO_FRAGMENT;
return true;
}
}
}
}
}
/* Parses IPv6 extension headers until a terminal header (or header we
* don't understand) is found. 'datap' points to the first extension
* header and advances as parsing occurs; 'sizep' is the remaining size
* and is decreased accordingly. 'nw_proto' starts as the first
* extension header to process and is updated as the extension headers
* are parsed.
*
* If a fragment header is found, '*frag_hdr' is set to the fragment
* header and otherwise set to NULL. If it is the first fragment,
* extension header parsing otherwise continues as usual. If it's not
* the first fragment, 'nw_proto' is set to IPPROTO_FRAGMENT and 'nw_frag'
* has FLOW_NW_FRAG_LATER set. Both first and later fragments have
* FLOW_NW_FRAG_ANY set in 'nw_frag'.
*
* If a routing header is found, '*rt_hdr' is set to the routing
* header and otherwise set to NULL.
*
* A return value of false indicates that there was a problem parsing
* the extension headers.*/
bool
parse_ipv6_ext_hdrs(const void **datap, size_t *sizep, uint8_t *nw_proto,
uint8_t *nw_frag,
const struct ovs_16aligned_ip6_frag **frag_hdr,
const struct ip6_rt_hdr **rt_hdr)
{
return parse_ipv6_ext_hdrs__(datap, sizep, nw_proto, nw_frag,
frag_hdr, rt_hdr);
}
bool
parse_nsh(const void **datap, size_t *sizep, struct ovs_key_nsh *key)
{
const struct nsh_hdr *nsh = (const struct nsh_hdr *) *datap;
uint8_t version, length, flags, ttl;
/* Check if it is long enough for NSH header, doesn't support
* MD type 2 yet
*/
if (OVS_UNLIKELY(*sizep < NSH_BASE_HDR_LEN)) {
return false;
}
version = nsh_get_ver(nsh);
flags = nsh_get_flags(nsh);
length = nsh_hdr_len(nsh);
ttl = nsh_get_ttl(nsh);
if (OVS_UNLIKELY(length > *sizep || version != 0)) {
return false;
}
key->flags = flags;
key->ttl = ttl;
key->mdtype = nsh->md_type;
key->np = nsh->next_proto;
key->path_hdr = nsh_get_path_hdr(nsh);
switch (key->mdtype) {
case NSH_M_TYPE1:
if (length != NSH_M_TYPE1_LEN) {
return false;
}
for (size_t i = 0; i < 4; i++) {
key->context[i] = get_16aligned_be32(&nsh->md1.context[i]);
}
break;
case NSH_M_TYPE2:
/* Don't support MD type 2 metedata parsing yet */
if (length < NSH_BASE_HDR_LEN) {
return false;
}
memset(key->context, 0, sizeof(key->context));
break;
default:
/* We don't parse other context headers yet. */
memset(key->context, 0, sizeof(key->context));
break;
}
data_pull(datap, sizep, length);
return true;
}
/* This does the same thing as miniflow_extract() with a full-size 'flow' as
* the destination. */
Implement new fragment handling policy. Until now, OVS has handled IP fragments more awkwardly than necessary. It has not been possible to match on L4 headers, even in fragments with offset 0 where they are actually present. This means that there was no way to implement ACLs that treat, say, different TCP ports differently, on fragmented traffic; instead, all decisions for fragment forwarding had to be made on the basis of L2 and L3 headers alone. This commit improves the situation significantly. It is still not possible to match on L4 headers in fragments with nonzero offset, because that information is simply not present in such fragments, but this commit adds the ability to match on L4 headers for fragments with zero offset. This means that it becomes possible to implement ACLs that drop such "first fragments" on the basis of L4 headers. In practice, that effectively blocks even fragmented traffic on an L4 basis, because the receiving IP stack cannot reassemble a full packet when the first fragment is missing. This commit works by adding a new "fragment type" to the kernel flow match and making it available through OpenFlow as a new NXM field named NXM_NX_IP_FRAG. Because OpenFlow 1.0 explicitly says that the L4 fields are always 0 for IP fragments, it adds a new OpenFlow fragment handling mode that fills in the L4 fields for "first fragments". It also enhances ovs-ofctl to allow users to configure this new fragment handling mode and to parse the new field. Signed-off-by: Ben Pfaff <blp@nicira.com> Bug #7557.
2011-10-19 21:33:44 -07:00
void
flow_extract(struct dp_packet *packet, struct flow *flow)
{
struct {
struct miniflow mf;
uint64_t buf[FLOW_U64S];
} m;
COVERAGE_INC(flow_extract);
miniflow_extract(packet, &m.mf);
miniflow_expand(&m.mf, flow);
}
static inline bool
ipv4_sanity_check(const struct ip_header *nh, size_t size,
int *ip_lenp, uint16_t *tot_lenp)
{
int ip_len;
uint16_t tot_len;
if (OVS_UNLIKELY(size < IP_HEADER_LEN)) {
COVERAGE_INC(miniflow_extract_ipv4_pkt_too_short);
return false;
}
ip_len = IP_IHL(nh->ip_ihl_ver) * 4;
if (OVS_UNLIKELY(ip_len < IP_HEADER_LEN || size < ip_len)) {
COVERAGE_INC(miniflow_extract_ipv4_pkt_len_error);
return false;
}
tot_len = ntohs(nh->ip_tot_len);
if (OVS_UNLIKELY(tot_len > size || ip_len > tot_len ||
size - tot_len > UINT16_MAX)) {
COVERAGE_INC(miniflow_extract_ipv4_pkt_len_error);
return false;
}
*ip_lenp = ip_len;
*tot_lenp = tot_len;
return true;
}
static inline uint8_t
ipv4_get_nw_frag(const struct ip_header *nh)
{
uint8_t nw_frag = 0;
if (OVS_UNLIKELY(IP_IS_FRAGMENT(nh->ip_frag_off))) {
nw_frag = FLOW_NW_FRAG_ANY;
if (nh->ip_frag_off & htons(IP_FRAG_OFF_MASK)) {
nw_frag |= FLOW_NW_FRAG_LATER;
}
}
return nw_frag;
}
static inline bool
ipv6_sanity_check(const struct ovs_16aligned_ip6_hdr *nh, size_t size)
{
uint16_t plen;
if (OVS_UNLIKELY(size < sizeof *nh)) {
COVERAGE_INC(miniflow_extract_ipv6_pkt_too_short);
return false;
}
plen = ntohs(nh->ip6_plen);
if (OVS_UNLIKELY(plen + IPV6_HEADER_LEN > size)) {
COVERAGE_INC(miniflow_extract_ipv6_pkt_len_error);
return false;
}
if (OVS_UNLIKELY(size - (plen + IPV6_HEADER_LEN) > UINT16_MAX)) {
COVERAGE_INC(miniflow_extract_ipv6_pkt_len_error);
return false;
}
return true;
}
static void
dump_invalid_packet(struct dp_packet *packet, const char *reason)
{
static struct vlog_rate_limit rl = VLOG_RATE_LIMIT_INIT(1, 5);
struct ds ds = DS_EMPTY_INITIALIZER;
size_t size;
if (VLOG_DROP_DBG(&rl)) {
return;
}
size = dp_packet_size(packet);
ds_put_hex_dump(&ds, dp_packet_data(packet), size, 0, false);
VLOG_DBG("invalid packet for %s: port %"PRIu32", size %"PRIuSIZE"\n%s",
reason, packet->md.in_port.odp_port, size, ds_cstr(&ds));
ds_destroy(&ds);
}
/* Initializes 'dst' from 'packet' and 'md', taking the packet type into
* account. 'dst' must have enough space for FLOW_U64S * 8 bytes.
*
* Initializes the layer offsets as follows:
*
* - packet->l2_5_ofs to the
* * the start of the MPLS shim header. Can be zero, if the
* packet is of type (OFPHTN_ETHERTYPE, ETH_TYPE_MPLS).
* * UINT16_MAX when there is no MPLS shim header.
*
* - packet->l3_ofs is set to
* * zero if the packet_type is in name space OFPHTN_ETHERTYPE
* and there is no MPLS shim header.
* * just past the Ethernet header, or just past the vlan_header if
* one is present, to the first byte of the payload of the
* Ethernet frame if the packet type is Ethernet and there is
* no MPLS shim header.
* * just past the MPLS label stack to the first byte of the MPLS
* payload if there is at least one MPLS shim header.
* * UINT16_MAX if the packet type is Ethernet and the frame is
* too short to contain an Ethernet header.
*
* - packet->l4_ofs is set to just past the IPv4 or IPv6 header, if one is
* present and the packet has at least the content used for the fields
* of interest for the flow, otherwise UINT16_MAX.
*/
void
miniflow_extract(struct dp_packet *packet, struct miniflow *dst)
{
/* Add code to this function (or its callees) to extract new fields. */
BUILD_ASSERT_DECL(FLOW_WC_SEQ == 42);
const struct pkt_metadata *md = &packet->md;
const void *data = dp_packet_data(packet);
size_t size = dp_packet_size(packet);
userspace: Add packet_type in dp_packet and flow This commit adds a packet_type attribute to the structs dp_packet and flow to explicitly carry the type of the packet as prepration for the introduction of the so-called packet type-aware pipeline (PTAP) in OVS. The packet_type is a big-endian 32 bit integer with the encoding as specified in OpenFlow verion 1.5. The upper 16 bits contain the packet type name space. Pre-defined values are defined in openflow-common.h: enum ofp_header_type_namespaces { OFPHTN_ONF = 0, /* ONF namespace. */ OFPHTN_ETHERTYPE = 1, /* ns_type is an Ethertype. */ OFPHTN_IP_PROTO = 2, /* ns_type is a IP protocol number. */ OFPHTN_UDP_TCP_PORT = 3, /* ns_type is a TCP or UDP port. */ OFPHTN_IPV4_OPTION = 4, /* ns_type is an IPv4 option number. */ }; The lower 16 bits specify the actual type in the context of the name space. Only name spaces 0 and 1 will be supported for now. For name space OFPHTN_ONF the relevant packet type is 0 (Ethernet). This is the default packet_type in OVS and the only one supported so far. Packets of type (OFPHTN_ONF, 0) are called Ethernet packets. In name space OFPHTN_ETHERTYPE the type is the Ethertype of the packet. A packet of type (OFPHTN_ETHERTYPE, <Ethertype>) is a standard L2 packet whith the Ethernet header (and any VLAN tags) removed to expose the L3 (or L2.5) payload of the packet. These will simply be called L3 packets. The Ethernet address fields dl_src and dl_dst in struct flow are not applicable for an L3 packet and must be zero. However, to maintain compatibility with the large code base, we have chosen to copy the Ethertype of an L3 packet into the the dl_type field of struct flow. This does not mean that it will be possible to match on dl_type for L3 packets with PTAP later on. Matching must be done on packet_type instead. New dp_packets are initialized with packet_type Ethernet. Ports that receive L3 packets will have to explicitly adjust the packet_type. Signed-off-by: Jean Tourrilhes <jt@labs.hpe.com> Signed-off-by: Jan Scheurich <jan.scheurich@ericsson.com> Co-authored-by: Zoltan Balogh <zoltan.balogh@ericsson.com> Signed-off-by: Ben Pfaff <blp@ovn.org>
2017-04-25 16:29:59 +00:00
ovs_be32 packet_type = packet->packet_type;
uint64_t *values = miniflow_values(dst);
struct mf_ctx mf = { FLOWMAP_EMPTY_INITIALIZER, values,
values + FLOW_U64S };
userspace: Add packet_type in dp_packet and flow This commit adds a packet_type attribute to the structs dp_packet and flow to explicitly carry the type of the packet as prepration for the introduction of the so-called packet type-aware pipeline (PTAP) in OVS. The packet_type is a big-endian 32 bit integer with the encoding as specified in OpenFlow verion 1.5. The upper 16 bits contain the packet type name space. Pre-defined values are defined in openflow-common.h: enum ofp_header_type_namespaces { OFPHTN_ONF = 0, /* ONF namespace. */ OFPHTN_ETHERTYPE = 1, /* ns_type is an Ethertype. */ OFPHTN_IP_PROTO = 2, /* ns_type is a IP protocol number. */ OFPHTN_UDP_TCP_PORT = 3, /* ns_type is a TCP or UDP port. */ OFPHTN_IPV4_OPTION = 4, /* ns_type is an IPv4 option number. */ }; The lower 16 bits specify the actual type in the context of the name space. Only name spaces 0 and 1 will be supported for now. For name space OFPHTN_ONF the relevant packet type is 0 (Ethernet). This is the default packet_type in OVS and the only one supported so far. Packets of type (OFPHTN_ONF, 0) are called Ethernet packets. In name space OFPHTN_ETHERTYPE the type is the Ethertype of the packet. A packet of type (OFPHTN_ETHERTYPE, <Ethertype>) is a standard L2 packet whith the Ethernet header (and any VLAN tags) removed to expose the L3 (or L2.5) payload of the packet. These will simply be called L3 packets. The Ethernet address fields dl_src and dl_dst in struct flow are not applicable for an L3 packet and must be zero. However, to maintain compatibility with the large code base, we have chosen to copy the Ethertype of an L3 packet into the the dl_type field of struct flow. This does not mean that it will be possible to match on dl_type for L3 packets with PTAP later on. Matching must be done on packet_type instead. New dp_packets are initialized with packet_type Ethernet. Ports that receive L3 packets will have to explicitly adjust the packet_type. Signed-off-by: Jean Tourrilhes <jt@labs.hpe.com> Signed-off-by: Jan Scheurich <jan.scheurich@ericsson.com> Co-authored-by: Zoltan Balogh <zoltan.balogh@ericsson.com> Signed-off-by: Ben Pfaff <blp@ovn.org>
2017-04-25 16:29:59 +00:00
const char *frame;
ovs_be16 dl_type = OVS_BE16_MAX;
uint8_t nw_frag, nw_tos, nw_ttl, nw_proto;
uint8_t *ct_nw_proto_p = NULL;
ovs_be16 ct_tp_src = 0, ct_tp_dst = 0;
/* Metadata. */
if (flow_tnl_dst_is_set(&md->tunnel)) {
miniflow_push_words(mf, tunnel, &md->tunnel,
offsetof(struct flow_tnl, metadata) /
sizeof(uint64_t));
dpif-netdev: Translate Geneve options per-flow, not per-packet. The kernel implementation of Geneve options stores the TLV option data in the flow exactly as received, without any further parsing. This is then translated to known options for the purposes of matching on flow setup (which will then install a datapath flow in the form the kernel is expecting). The userspace implementation behaves a little bit differently - it looks up known options as each packet is received. The reason for this is there is a much tighter coupling between datapath and flow translation and the representation is generally expected to be the same. This works but it incurs work on a per-packet basis that could be done per-flow instead. This introduces a small translation step for Geneve packets between datapath and flow lookup for the userspace datapath in order to allow the same kind of processing that the kernel does. A side effect of this is that unknown options are now shown when flows dumped via ovs-appctl dpif/dump-flows, similar to the kernel. There is a second benefit to this as well: for some operations it is preferable to keep the options exactly as they were received on the wire, which this enables. One example is that for packets that are executed from ofproto-dpif-upcall to the datapath, this avoids the translation of Geneve metadata. Since this conversion is potentially lossy (for unknown options), keeping everything in the same format removes the possibility of dropping options if the packet comes back up to userspace and the Geneve option translation table has changed. To help with these types of operations, most functions can understand both formats of data and seamlessly do the right thing. Signed-off-by: Jesse Gross <jesse@nicira.com> Acked-by: Jarno Rajahalme <jrajahalme@nicira.com>
2015-06-29 18:01:59 -07:00
if (!(md->tunnel.flags & FLOW_TNL_F_UDPIF)) {
if (md->tunnel.metadata.present.map) {
miniflow_push_words(mf, tunnel.metadata, &md->tunnel.metadata,
sizeof md->tunnel.metadata /
sizeof(uint64_t));
}
} else {
if (md->tunnel.metadata.present.len) {
miniflow_push_words(mf, tunnel.metadata.present,
&md->tunnel.metadata.present, 1);
miniflow_push_words(mf, tunnel.metadata.opts.gnv,
md->tunnel.metadata.opts.gnv,
DIV_ROUND_UP(md->tunnel.metadata.present.len,
sizeof(uint64_t)));
}
}
}
if (md->skb_priority || md->pkt_mark) {
miniflow_push_uint32(mf, skb_priority, md->skb_priority);
miniflow_push_uint32(mf, pkt_mark, md->pkt_mark);
}
miniflow_push_uint32(mf, dp_hash, md->dp_hash);
miniflow_push_uint32(mf, in_port, odp_to_u32(md->in_port.odp_port));
if (md->ct_state) {
miniflow_push_uint32(mf, recirc_id, md->recirc_id);
miniflow_push_uint8(mf, ct_state, md->ct_state);
ct_nw_proto_p = miniflow_pointer(mf, ct_nw_proto);
miniflow_push_uint8(mf, ct_nw_proto, 0);
Add support for connection tracking. This patch adds a new action and fields to OVS that allow connection tracking to be performed. This support works in conjunction with the Linux kernel support merged into the Linux-4.3 development cycle. Packets have two possible states with respect to connection tracking: Untracked packets have not previously passed through the connection tracker, while tracked packets have previously been through the connection tracker. For OpenFlow pipeline processing, untracked packets can become tracked, and they will remain tracked until the end of the pipeline. Tracked packets cannot become untracked. Connections can be unknown, uncommitted, or committed. Packets which are untracked have unknown connection state. To know the connection state, the packet must become tracked. Uncommitted connections have no connection state stored about them, so it is only possible for the connection tracker to identify whether they are a new connection or whether they are invalid. Committed connections have connection state stored beyond the lifetime of the packet, which allows later packets in the same connection to be identified as part of the same established connection, or related to an existing connection - for instance ICMP error responses. The new 'ct' action transitions the packet from "untracked" to "tracked" by sending this flow through the connection tracker. The following parameters are supported initally: - "commit": When commit is executed, the connection moves from uncommitted state to committed state. This signals that information about the connection should be stored beyond the lifetime of the packet within the pipeline. This allows future packets in the same connection to be recognized as part of the same "established" (est) connection, as well as identifying packets in the reply (rpl) direction, or packets related to an existing connection (rel). - "zone=[u16|NXM]": Perform connection tracking in the zone specified. Each zone is an independent connection tracking context. When the "commit" parameter is used, the connection will only be committed in the specified zone, and not in other zones. This is 0 by default. - "table=NUMBER": Fork pipeline processing in two. The original instance of the packet will continue processing the current actions list as an untracked packet. An additional instance of the packet will be sent to the connection tracker, which will be re-injected into the OpenFlow pipeline to resume processing in the specified table, with the ct_state and other ct match fields set. If the table is not specified, then the packet is submitted to the connection tracker, but the pipeline does not fork and the ct match fields are not populated. It is strongly recommended to specify a table later than the current table to prevent loops. When the "table" option is used, the packet that continues processing in the specified table will have the ct_state populated. The ct_state may have any of the following flags set: - Tracked (trk): Connection tracking has occurred. - Reply (rpl): The flow is in the reply direction. - Invalid (inv): The connection tracker couldn't identify the connection. - New (new): This is the beginning of a new connection. - Established (est): This is part of an already existing connection. - Related (rel): This connection is related to an existing connection. For more information, consult the ovs-ofctl(8) man pages. Below is a simple example flow table to allow outbound TCP traffic from port 1 and drop traffic from port 2 that was not initiated by port 1: table=0,priority=1,action=drop table=0,arp,action=normal table=0,in_port=1,tcp,ct_state=-trk,action=ct(commit,zone=9),2 table=0,in_port=2,tcp,ct_state=-trk,action=ct(zone=9,table=1) table=1,in_port=2,ct_state=+trk+est,tcp,action=1 table=1,in_port=2,ct_state=+trk+new,tcp,action=drop Based on original design by Justin Pettit, contributions from Thomas Graf and Daniele Di Proietto. Signed-off-by: Joe Stringer <joestringer@nicira.com> Acked-by: Jarno Rajahalme <jrajahalme@nicira.com> Acked-by: Ben Pfaff <blp@nicira.com>
2015-08-11 10:56:09 -07:00
miniflow_push_uint16(mf, ct_zone, md->ct_zone);
miniflow_push_uint32(mf, ct_mark, md->ct_mark);
userspace: Add packet_type in dp_packet and flow This commit adds a packet_type attribute to the structs dp_packet and flow to explicitly carry the type of the packet as prepration for the introduction of the so-called packet type-aware pipeline (PTAP) in OVS. The packet_type is a big-endian 32 bit integer with the encoding as specified in OpenFlow verion 1.5. The upper 16 bits contain the packet type name space. Pre-defined values are defined in openflow-common.h: enum ofp_header_type_namespaces { OFPHTN_ONF = 0, /* ONF namespace. */ OFPHTN_ETHERTYPE = 1, /* ns_type is an Ethertype. */ OFPHTN_IP_PROTO = 2, /* ns_type is a IP protocol number. */ OFPHTN_UDP_TCP_PORT = 3, /* ns_type is a TCP or UDP port. */ OFPHTN_IPV4_OPTION = 4, /* ns_type is an IPv4 option number. */ }; The lower 16 bits specify the actual type in the context of the name space. Only name spaces 0 and 1 will be supported for now. For name space OFPHTN_ONF the relevant packet type is 0 (Ethernet). This is the default packet_type in OVS and the only one supported so far. Packets of type (OFPHTN_ONF, 0) are called Ethernet packets. In name space OFPHTN_ETHERTYPE the type is the Ethertype of the packet. A packet of type (OFPHTN_ETHERTYPE, <Ethertype>) is a standard L2 packet whith the Ethernet header (and any VLAN tags) removed to expose the L3 (or L2.5) payload of the packet. These will simply be called L3 packets. The Ethernet address fields dl_src and dl_dst in struct flow are not applicable for an L3 packet and must be zero. However, to maintain compatibility with the large code base, we have chosen to copy the Ethertype of an L3 packet into the the dl_type field of struct flow. This does not mean that it will be possible to match on dl_type for L3 packets with PTAP later on. Matching must be done on packet_type instead. New dp_packets are initialized with packet_type Ethernet. Ports that receive L3 packets will have to explicitly adjust the packet_type. Signed-off-by: Jean Tourrilhes <jt@labs.hpe.com> Signed-off-by: Jan Scheurich <jan.scheurich@ericsson.com> Co-authored-by: Zoltan Balogh <zoltan.balogh@ericsson.com> Signed-off-by: Ben Pfaff <blp@ovn.org>
2017-04-25 16:29:59 +00:00
miniflow_push_be32(mf, packet_type, packet_type);
if (!ovs_u128_is_zero(md->ct_label)) {
miniflow_push_words(mf, ct_label, &md->ct_label,
sizeof md->ct_label / sizeof(uint64_t));
}
userspace: Add packet_type in dp_packet and flow This commit adds a packet_type attribute to the structs dp_packet and flow to explicitly carry the type of the packet as prepration for the introduction of the so-called packet type-aware pipeline (PTAP) in OVS. The packet_type is a big-endian 32 bit integer with the encoding as specified in OpenFlow verion 1.5. The upper 16 bits contain the packet type name space. Pre-defined values are defined in openflow-common.h: enum ofp_header_type_namespaces { OFPHTN_ONF = 0, /* ONF namespace. */ OFPHTN_ETHERTYPE = 1, /* ns_type is an Ethertype. */ OFPHTN_IP_PROTO = 2, /* ns_type is a IP protocol number. */ OFPHTN_UDP_TCP_PORT = 3, /* ns_type is a TCP or UDP port. */ OFPHTN_IPV4_OPTION = 4, /* ns_type is an IPv4 option number. */ }; The lower 16 bits specify the actual type in the context of the name space. Only name spaces 0 and 1 will be supported for now. For name space OFPHTN_ONF the relevant packet type is 0 (Ethernet). This is the default packet_type in OVS and the only one supported so far. Packets of type (OFPHTN_ONF, 0) are called Ethernet packets. In name space OFPHTN_ETHERTYPE the type is the Ethertype of the packet. A packet of type (OFPHTN_ETHERTYPE, <Ethertype>) is a standard L2 packet whith the Ethernet header (and any VLAN tags) removed to expose the L3 (or L2.5) payload of the packet. These will simply be called L3 packets. The Ethernet address fields dl_src and dl_dst in struct flow are not applicable for an L3 packet and must be zero. However, to maintain compatibility with the large code base, we have chosen to copy the Ethertype of an L3 packet into the the dl_type field of struct flow. This does not mean that it will be possible to match on dl_type for L3 packets with PTAP later on. Matching must be done on packet_type instead. New dp_packets are initialized with packet_type Ethernet. Ports that receive L3 packets will have to explicitly adjust the packet_type. Signed-off-by: Jean Tourrilhes <jt@labs.hpe.com> Signed-off-by: Jan Scheurich <jan.scheurich@ericsson.com> Co-authored-by: Zoltan Balogh <zoltan.balogh@ericsson.com> Signed-off-by: Ben Pfaff <blp@ovn.org>
2017-04-25 16:29:59 +00:00
} else {
if (md->recirc_id) {
miniflow_push_uint32(mf, recirc_id, md->recirc_id);
miniflow_pad_to_64(mf, recirc_id);
}
userspace: Add packet_type in dp_packet and flow This commit adds a packet_type attribute to the structs dp_packet and flow to explicitly carry the type of the packet as prepration for the introduction of the so-called packet type-aware pipeline (PTAP) in OVS. The packet_type is a big-endian 32 bit integer with the encoding as specified in OpenFlow verion 1.5. The upper 16 bits contain the packet type name space. Pre-defined values are defined in openflow-common.h: enum ofp_header_type_namespaces { OFPHTN_ONF = 0, /* ONF namespace. */ OFPHTN_ETHERTYPE = 1, /* ns_type is an Ethertype. */ OFPHTN_IP_PROTO = 2, /* ns_type is a IP protocol number. */ OFPHTN_UDP_TCP_PORT = 3, /* ns_type is a TCP or UDP port. */ OFPHTN_IPV4_OPTION = 4, /* ns_type is an IPv4 option number. */ }; The lower 16 bits specify the actual type in the context of the name space. Only name spaces 0 and 1 will be supported for now. For name space OFPHTN_ONF the relevant packet type is 0 (Ethernet). This is the default packet_type in OVS and the only one supported so far. Packets of type (OFPHTN_ONF, 0) are called Ethernet packets. In name space OFPHTN_ETHERTYPE the type is the Ethertype of the packet. A packet of type (OFPHTN_ETHERTYPE, <Ethertype>) is a standard L2 packet whith the Ethernet header (and any VLAN tags) removed to expose the L3 (or L2.5) payload of the packet. These will simply be called L3 packets. The Ethernet address fields dl_src and dl_dst in struct flow are not applicable for an L3 packet and must be zero. However, to maintain compatibility with the large code base, we have chosen to copy the Ethertype of an L3 packet into the the dl_type field of struct flow. This does not mean that it will be possible to match on dl_type for L3 packets with PTAP later on. Matching must be done on packet_type instead. New dp_packets are initialized with packet_type Ethernet. Ports that receive L3 packets will have to explicitly adjust the packet_type. Signed-off-by: Jean Tourrilhes <jt@labs.hpe.com> Signed-off-by: Jan Scheurich <jan.scheurich@ericsson.com> Co-authored-by: Zoltan Balogh <zoltan.balogh@ericsson.com> Signed-off-by: Ben Pfaff <blp@ovn.org>
2017-04-25 16:29:59 +00:00
miniflow_pad_from_64(mf, packet_type);
miniflow_push_be32(mf, packet_type, packet_type);
}
/* Initialize packet's layer pointer and offsets. */
userspace: Add packet_type in dp_packet and flow This commit adds a packet_type attribute to the structs dp_packet and flow to explicitly carry the type of the packet as prepration for the introduction of the so-called packet type-aware pipeline (PTAP) in OVS. The packet_type is a big-endian 32 bit integer with the encoding as specified in OpenFlow verion 1.5. The upper 16 bits contain the packet type name space. Pre-defined values are defined in openflow-common.h: enum ofp_header_type_namespaces { OFPHTN_ONF = 0, /* ONF namespace. */ OFPHTN_ETHERTYPE = 1, /* ns_type is an Ethertype. */ OFPHTN_IP_PROTO = 2, /* ns_type is a IP protocol number. */ OFPHTN_UDP_TCP_PORT = 3, /* ns_type is a TCP or UDP port. */ OFPHTN_IPV4_OPTION = 4, /* ns_type is an IPv4 option number. */ }; The lower 16 bits specify the actual type in the context of the name space. Only name spaces 0 and 1 will be supported for now. For name space OFPHTN_ONF the relevant packet type is 0 (Ethernet). This is the default packet_type in OVS and the only one supported so far. Packets of type (OFPHTN_ONF, 0) are called Ethernet packets. In name space OFPHTN_ETHERTYPE the type is the Ethertype of the packet. A packet of type (OFPHTN_ETHERTYPE, <Ethertype>) is a standard L2 packet whith the Ethernet header (and any VLAN tags) removed to expose the L3 (or L2.5) payload of the packet. These will simply be called L3 packets. The Ethernet address fields dl_src and dl_dst in struct flow are not applicable for an L3 packet and must be zero. However, to maintain compatibility with the large code base, we have chosen to copy the Ethertype of an L3 packet into the the dl_type field of struct flow. This does not mean that it will be possible to match on dl_type for L3 packets with PTAP later on. Matching must be done on packet_type instead. New dp_packets are initialized with packet_type Ethernet. Ports that receive L3 packets will have to explicitly adjust the packet_type. Signed-off-by: Jean Tourrilhes <jt@labs.hpe.com> Signed-off-by: Jan Scheurich <jan.scheurich@ericsson.com> Co-authored-by: Zoltan Balogh <zoltan.balogh@ericsson.com> Signed-off-by: Ben Pfaff <blp@ovn.org>
2017-04-25 16:29:59 +00:00
frame = data;
if (dp_packet_tunnel(packet)) {
/* Preserve inner offsets from previous circulation. */
dp_packet_reset_outer_offsets(packet);
} else {
dp_packet_reset_offsets(packet);
}
userspace: Add packet_type in dp_packet and flow This commit adds a packet_type attribute to the structs dp_packet and flow to explicitly carry the type of the packet as prepration for the introduction of the so-called packet type-aware pipeline (PTAP) in OVS. The packet_type is a big-endian 32 bit integer with the encoding as specified in OpenFlow verion 1.5. The upper 16 bits contain the packet type name space. Pre-defined values are defined in openflow-common.h: enum ofp_header_type_namespaces { OFPHTN_ONF = 0, /* ONF namespace. */ OFPHTN_ETHERTYPE = 1, /* ns_type is an Ethertype. */ OFPHTN_IP_PROTO = 2, /* ns_type is a IP protocol number. */ OFPHTN_UDP_TCP_PORT = 3, /* ns_type is a TCP or UDP port. */ OFPHTN_IPV4_OPTION = 4, /* ns_type is an IPv4 option number. */ }; The lower 16 bits specify the actual type in the context of the name space. Only name spaces 0 and 1 will be supported for now. For name space OFPHTN_ONF the relevant packet type is 0 (Ethernet). This is the default packet_type in OVS and the only one supported so far. Packets of type (OFPHTN_ONF, 0) are called Ethernet packets. In name space OFPHTN_ETHERTYPE the type is the Ethertype of the packet. A packet of type (OFPHTN_ETHERTYPE, <Ethertype>) is a standard L2 packet whith the Ethernet header (and any VLAN tags) removed to expose the L3 (or L2.5) payload of the packet. These will simply be called L3 packets. The Ethernet address fields dl_src and dl_dst in struct flow are not applicable for an L3 packet and must be zero. However, to maintain compatibility with the large code base, we have chosen to copy the Ethertype of an L3 packet into the the dl_type field of struct flow. This does not mean that it will be possible to match on dl_type for L3 packets with PTAP later on. Matching must be done on packet_type instead. New dp_packets are initialized with packet_type Ethernet. Ports that receive L3 packets will have to explicitly adjust the packet_type. Signed-off-by: Jean Tourrilhes <jt@labs.hpe.com> Signed-off-by: Jan Scheurich <jan.scheurich@ericsson.com> Co-authored-by: Zoltan Balogh <zoltan.balogh@ericsson.com> Signed-off-by: Ben Pfaff <blp@ovn.org>
2017-04-25 16:29:59 +00:00
if (packet_type == htonl(PT_ETH)) {
/* Must have full Ethernet header to proceed. */
if (OVS_UNLIKELY(size < sizeof(struct eth_header))) {
goto out;
} else {
/* Link layer. */
ASSERT_SEQUENTIAL(dl_dst, dl_src);
miniflow_push_macs(mf, dl_dst, data);
/* VLAN */
union flow_vlan_hdr vlans[FLOW_MAX_VLAN_HEADERS];
size_t num_vlans = parse_vlan(&data, &size, vlans);
dl_type = parse_ethertype(&data, &size);
miniflow_push_be16(mf, dl_type, dl_type);
miniflow_pad_to_64(mf, dl_type);
if (num_vlans > 0) {
miniflow_push_words_32(mf, vlans, vlans, num_vlans);
}
userspace: Add packet_type in dp_packet and flow This commit adds a packet_type attribute to the structs dp_packet and flow to explicitly carry the type of the packet as prepration for the introduction of the so-called packet type-aware pipeline (PTAP) in OVS. The packet_type is a big-endian 32 bit integer with the encoding as specified in OpenFlow verion 1.5. The upper 16 bits contain the packet type name space. Pre-defined values are defined in openflow-common.h: enum ofp_header_type_namespaces { OFPHTN_ONF = 0, /* ONF namespace. */ OFPHTN_ETHERTYPE = 1, /* ns_type is an Ethertype. */ OFPHTN_IP_PROTO = 2, /* ns_type is a IP protocol number. */ OFPHTN_UDP_TCP_PORT = 3, /* ns_type is a TCP or UDP port. */ OFPHTN_IPV4_OPTION = 4, /* ns_type is an IPv4 option number. */ }; The lower 16 bits specify the actual type in the context of the name space. Only name spaces 0 and 1 will be supported for now. For name space OFPHTN_ONF the relevant packet type is 0 (Ethernet). This is the default packet_type in OVS and the only one supported so far. Packets of type (OFPHTN_ONF, 0) are called Ethernet packets. In name space OFPHTN_ETHERTYPE the type is the Ethertype of the packet. A packet of type (OFPHTN_ETHERTYPE, <Ethertype>) is a standard L2 packet whith the Ethernet header (and any VLAN tags) removed to expose the L3 (or L2.5) payload of the packet. These will simply be called L3 packets. The Ethernet address fields dl_src and dl_dst in struct flow are not applicable for an L3 packet and must be zero. However, to maintain compatibility with the large code base, we have chosen to copy the Ethertype of an L3 packet into the the dl_type field of struct flow. This does not mean that it will be possible to match on dl_type for L3 packets with PTAP later on. Matching must be done on packet_type instead. New dp_packets are initialized with packet_type Ethernet. Ports that receive L3 packets will have to explicitly adjust the packet_type. Signed-off-by: Jean Tourrilhes <jt@labs.hpe.com> Signed-off-by: Jan Scheurich <jan.scheurich@ericsson.com> Co-authored-by: Zoltan Balogh <zoltan.balogh@ericsson.com> Signed-off-by: Ben Pfaff <blp@ovn.org>
2017-04-25 16:29:59 +00:00
}
} else {
/* Take dl_type from packet_type. */
dl_type = pt_ns_type_be(packet_type);
miniflow_pad_from_64(mf, dl_type);
miniflow_push_be16(mf, dl_type, dl_type);
userspace: Add packet_type in dp_packet and flow This commit adds a packet_type attribute to the structs dp_packet and flow to explicitly carry the type of the packet as prepration for the introduction of the so-called packet type-aware pipeline (PTAP) in OVS. The packet_type is a big-endian 32 bit integer with the encoding as specified in OpenFlow verion 1.5. The upper 16 bits contain the packet type name space. Pre-defined values are defined in openflow-common.h: enum ofp_header_type_namespaces { OFPHTN_ONF = 0, /* ONF namespace. */ OFPHTN_ETHERTYPE = 1, /* ns_type is an Ethertype. */ OFPHTN_IP_PROTO = 2, /* ns_type is a IP protocol number. */ OFPHTN_UDP_TCP_PORT = 3, /* ns_type is a TCP or UDP port. */ OFPHTN_IPV4_OPTION = 4, /* ns_type is an IPv4 option number. */ }; The lower 16 bits specify the actual type in the context of the name space. Only name spaces 0 and 1 will be supported for now. For name space OFPHTN_ONF the relevant packet type is 0 (Ethernet). This is the default packet_type in OVS and the only one supported so far. Packets of type (OFPHTN_ONF, 0) are called Ethernet packets. In name space OFPHTN_ETHERTYPE the type is the Ethertype of the packet. A packet of type (OFPHTN_ETHERTYPE, <Ethertype>) is a standard L2 packet whith the Ethernet header (and any VLAN tags) removed to expose the L3 (or L2.5) payload of the packet. These will simply be called L3 packets. The Ethernet address fields dl_src and dl_dst in struct flow are not applicable for an L3 packet and must be zero. However, to maintain compatibility with the large code base, we have chosen to copy the Ethertype of an L3 packet into the the dl_type field of struct flow. This does not mean that it will be possible to match on dl_type for L3 packets with PTAP later on. Matching must be done on packet_type instead. New dp_packets are initialized with packet_type Ethernet. Ports that receive L3 packets will have to explicitly adjust the packet_type. Signed-off-by: Jean Tourrilhes <jt@labs.hpe.com> Signed-off-by: Jan Scheurich <jan.scheurich@ericsson.com> Co-authored-by: Zoltan Balogh <zoltan.balogh@ericsson.com> Signed-off-by: Ben Pfaff <blp@ovn.org>
2017-04-25 16:29:59 +00:00
/* Do not push vlan_tci, pad instead */
miniflow_pad_to_64(mf, dl_type);
datapath: Fix handling of 802.1Q and SNAP headers. The kernel and user datapaths have code that assumes that 802.1Q headers are used only inside Ethernet II frames, not inside SNAP-encapsulated frames. But the kernel and user flow_extract() implementations would interpret 802.1Q headers inside SNAP headers as being valid VLANs. This would cause packet corruption if any VLAN-related actions were to be taken, so change the two flow_extract() implementations only to accept 802.1Q as an Ethernet II frame type, not as a SNAP-encoded frame type. 802.1Q-2005 says that this is correct anyhow: Where the ISS instance used to transmit and receive tagged frames is provided by a media access control method that can support Ethernet Type encoding directly (e.g., is an IEEE 802.3 or IEEE 802.11 MAC) or is media access method independent (e.g., 6.6), the TPID is Ethernet Type encoded, i.e., is two octets in length and comprises solely the assigned Ethernet Type value. Where the ISS instance is provided by a media access method that cannot directly support Ethernet Type encoding (e.g., is an IEEE 802.5 or FDDI MAC), the TPID is encoded according to the rule for a Subnetwork Access Protocol (Clause 10 of IEEE Std 802) that encapsulates Ethernet frames over LLC, and comprises the SNAP header (AA-AA-03) followed by the SNAP PID (00-00-00) followed by the two octets of the assigned Ethernet Type value. All of the media that OVS handles supports Ethernet Type fields, so to me that means that we don't have to handle 802.1Q-inside-SNAP. On the other hand, we *do* have to handle SNAP-inside-802.1Q, because this is actually allowed by the standards. So this commit also adds that support. I verified that, with this change, both SNAP and Ethernet packets are properly recognized both with and without 802.1Q encapsulation. I was a bit surprised to find out that Linux does not accept SNAP-encapsulated IP frames on Ethernet. Here's a summary of how frames are handled before and after this commit: Common cases ------------ Ethernet +------------+ 1. |dst|src|TYPE| +------------+ Ethernet LLC SNAP +------------+ +--------+ +-----------+ 2. |dst|src| len| |aa|aa|03| |000000|TYPE| +------------+ +--------+ +-----------+ Ethernet 802.1Q +------------+ +---------+ 3. |dst|src|8100| |VLAN|TYPE| +------------+ +---------+ Ethernet 802.1Q LLC SNAP +------------+ +---------+ +--------+ +-----------+ 4. |dst|src|8100| |VLAN| LEN| |aa|aa|03| |000000|TYPE| +------------+ +---------+ +--------+ +-----------+ Unusual cases ------------- Ethernet LLC SNAP 802.1Q +------------+ +--------+ +-----------+ +---------+ 5. |dst|src| len| |aa|aa|03| |000000|8100| |VLAN|TYPE| +------------+ +--------+ +-----------+ +---------+ Ethernet LLC +------------+ +--------+ 6. |dst|src| len| |xx|xx|xx| +------------+ +--------+ Ethernet LLC SNAP +------------+ +--------+ +-----------+ 7. |dst|src| len| |aa|aa|03| |xxxxxx|xxxx| +------------+ +--------+ +-----------+ Ethernet 802.1Q LLC +------------+ +---------+ +--------+ 8. |dst|src|8100| |VLAN| LEN| |xx|xx|xx| +------------+ +---------+ +--------+ Ethernet 802.1Q LLC SNAP +------------+ +---------+ +--------+ +-----------+ 9. |dst|src|8100| |VLAN| LEN| |aa|aa|03| |xxxxxx|xxxx| +------------+ +---------+ +--------+ +-----------+ Behavior -------- --------------- --------------- ------------------------------------- Before After this commit this commit dl_type dl_vlan dl_type dl_vlan Notes ------- ------- ------- ------- ------------------------------------- 1. TYPE ffff TYPE ffff no change 2. TYPE ffff TYPE ffff no change 3. TYPE VLAN TYPE VLAN no change 4. LEN VLAN TYPE VLAN proposal fixes behavior 5. TYPE VLAN 8100 ffff 802.1Q says this is invalid framing 6. 05ff ffff 05ff ffff no change 7. 05ff ffff 05ff ffff no change 8. LEN VLAN 05ff VLAN proposal fixes behavior 9. LEN VLAN 05ff VLAN proposal fixes behavior Signed-off-by: Ben Pfaff <blp@nicira.com>
2010-08-10 11:35:46 -07:00
}
/* Parse mpls. */
if (OVS_UNLIKELY(eth_type_mpls(dl_type))) {
int count;
const void *mpls = data;
userspace: Add packet_type in dp_packet and flow This commit adds a packet_type attribute to the structs dp_packet and flow to explicitly carry the type of the packet as prepration for the introduction of the so-called packet type-aware pipeline (PTAP) in OVS. The packet_type is a big-endian 32 bit integer with the encoding as specified in OpenFlow verion 1.5. The upper 16 bits contain the packet type name space. Pre-defined values are defined in openflow-common.h: enum ofp_header_type_namespaces { OFPHTN_ONF = 0, /* ONF namespace. */ OFPHTN_ETHERTYPE = 1, /* ns_type is an Ethertype. */ OFPHTN_IP_PROTO = 2, /* ns_type is a IP protocol number. */ OFPHTN_UDP_TCP_PORT = 3, /* ns_type is a TCP or UDP port. */ OFPHTN_IPV4_OPTION = 4, /* ns_type is an IPv4 option number. */ }; The lower 16 bits specify the actual type in the context of the name space. Only name spaces 0 and 1 will be supported for now. For name space OFPHTN_ONF the relevant packet type is 0 (Ethernet). This is the default packet_type in OVS and the only one supported so far. Packets of type (OFPHTN_ONF, 0) are called Ethernet packets. In name space OFPHTN_ETHERTYPE the type is the Ethertype of the packet. A packet of type (OFPHTN_ETHERTYPE, <Ethertype>) is a standard L2 packet whith the Ethernet header (and any VLAN tags) removed to expose the L3 (or L2.5) payload of the packet. These will simply be called L3 packets. The Ethernet address fields dl_src and dl_dst in struct flow are not applicable for an L3 packet and must be zero. However, to maintain compatibility with the large code base, we have chosen to copy the Ethertype of an L3 packet into the the dl_type field of struct flow. This does not mean that it will be possible to match on dl_type for L3 packets with PTAP later on. Matching must be done on packet_type instead. New dp_packets are initialized with packet_type Ethernet. Ports that receive L3 packets will have to explicitly adjust the packet_type. Signed-off-by: Jean Tourrilhes <jt@labs.hpe.com> Signed-off-by: Jan Scheurich <jan.scheurich@ericsson.com> Co-authored-by: Zoltan Balogh <zoltan.balogh@ericsson.com> Signed-off-by: Ben Pfaff <blp@ovn.org>
2017-04-25 16:29:59 +00:00
packet->l2_5_ofs = (char *)data - frame;
count = parse_mpls(&data, &size);
miniflow_push_words_32(mf, mpls_lse, mpls, count);
}
/* Network layer. */
userspace: Add packet_type in dp_packet and flow This commit adds a packet_type attribute to the structs dp_packet and flow to explicitly carry the type of the packet as prepration for the introduction of the so-called packet type-aware pipeline (PTAP) in OVS. The packet_type is a big-endian 32 bit integer with the encoding as specified in OpenFlow verion 1.5. The upper 16 bits contain the packet type name space. Pre-defined values are defined in openflow-common.h: enum ofp_header_type_namespaces { OFPHTN_ONF = 0, /* ONF namespace. */ OFPHTN_ETHERTYPE = 1, /* ns_type is an Ethertype. */ OFPHTN_IP_PROTO = 2, /* ns_type is a IP protocol number. */ OFPHTN_UDP_TCP_PORT = 3, /* ns_type is a TCP or UDP port. */ OFPHTN_IPV4_OPTION = 4, /* ns_type is an IPv4 option number. */ }; The lower 16 bits specify the actual type in the context of the name space. Only name spaces 0 and 1 will be supported for now. For name space OFPHTN_ONF the relevant packet type is 0 (Ethernet). This is the default packet_type in OVS and the only one supported so far. Packets of type (OFPHTN_ONF, 0) are called Ethernet packets. In name space OFPHTN_ETHERTYPE the type is the Ethertype of the packet. A packet of type (OFPHTN_ETHERTYPE, <Ethertype>) is a standard L2 packet whith the Ethernet header (and any VLAN tags) removed to expose the L3 (or L2.5) payload of the packet. These will simply be called L3 packets. The Ethernet address fields dl_src and dl_dst in struct flow are not applicable for an L3 packet and must be zero. However, to maintain compatibility with the large code base, we have chosen to copy the Ethertype of an L3 packet into the the dl_type field of struct flow. This does not mean that it will be possible to match on dl_type for L3 packets with PTAP later on. Matching must be done on packet_type instead. New dp_packets are initialized with packet_type Ethernet. Ports that receive L3 packets will have to explicitly adjust the packet_type. Signed-off-by: Jean Tourrilhes <jt@labs.hpe.com> Signed-off-by: Jan Scheurich <jan.scheurich@ericsson.com> Co-authored-by: Zoltan Balogh <zoltan.balogh@ericsson.com> Signed-off-by: Ben Pfaff <blp@ovn.org>
2017-04-25 16:29:59 +00:00
packet->l3_ofs = (char *)data - frame;
nw_frag = 0;
if (OVS_LIKELY(dl_type == htons(ETH_TYPE_IP))) {
const struct ip_header *nh = data;
int ip_len;
uint16_t tot_len;
if (OVS_UNLIKELY(!ipv4_sanity_check(nh, size, &ip_len, &tot_len))) {
if (OVS_UNLIKELY(VLOG_IS_DBG_ENABLED())) {
dump_invalid_packet(packet, "ipv4_sanity_check");
}
goto out;
}
dp_packet_set_l2_pad_size(packet, size - tot_len);
size = tot_len; /* Never pull padding. */
/* Push both source and destination address at once. */
miniflow_push_words(mf, nw_src, &nh->ip_src, 1);
if (ct_nw_proto_p && !md->ct_orig_tuple_ipv6) {
*ct_nw_proto_p = md->ct_orig_tuple.ipv4.ipv4_proto;
if (*ct_nw_proto_p) {
miniflow_push_words(mf, ct_nw_src,
&md->ct_orig_tuple.ipv4.ipv4_src, 1);
ct_tp_src = md->ct_orig_tuple.ipv4.src_port;
ct_tp_dst = md->ct_orig_tuple.ipv4.dst_port;
}
}
miniflow_push_be32(mf, ipv6_label, 0); /* Padding for IPv4. */
nw_tos = nh->ip_tos;
nw_ttl = nh->ip_ttl;
nw_proto = nh->ip_proto;
nw_frag = ipv4_get_nw_frag(nh);
data_pull(&data, &size, ip_len);
} else if (dl_type == htons(ETH_TYPE_IPV6)) {
const struct ovs_16aligned_ip6_hdr *nh = data;
ovs_be32 tc_flow;
uint16_t plen;
if (OVS_UNLIKELY(!ipv6_sanity_check(nh, size))) {
if (OVS_UNLIKELY(VLOG_IS_DBG_ENABLED())) {
dump_invalid_packet(packet, "ipv6_sanity_check");
}
goto out;
}
data_pull(&data, &size, sizeof *nh);
plen = ntohs(nh->ip6_plen);
dp_packet_set_l2_pad_size(packet, size - plen);
size = plen; /* Never pull padding. */
miniflow_push_words(mf, ipv6_src, &nh->ip6_src,
sizeof nh->ip6_src / 8);
miniflow_push_words(mf, ipv6_dst, &nh->ip6_dst,
sizeof nh->ip6_dst / 8);
if (ct_nw_proto_p && md->ct_orig_tuple_ipv6) {
*ct_nw_proto_p = md->ct_orig_tuple.ipv6.ipv6_proto;
if (*ct_nw_proto_p) {
miniflow_push_words(mf, ct_ipv6_src,
&md->ct_orig_tuple.ipv6.ipv6_src,
2 *
sizeof md->ct_orig_tuple.ipv6.ipv6_src / 8);
ct_tp_src = md->ct_orig_tuple.ipv6.src_port;
ct_tp_dst = md->ct_orig_tuple.ipv6.dst_port;
}
}
tc_flow = get_16aligned_be32(&nh->ip6_flow);
nw_tos = ntohl(tc_flow) >> 20;
nw_ttl = nh->ip6_hlim;
nw_proto = nh->ip6_nxt;
if (!parse_ipv6_ext_hdrs(&data, &size, &nw_proto, &nw_frag,
NULL, NULL)) {
goto out;
datapath: Fix handling of 802.1Q and SNAP headers. The kernel and user datapaths have code that assumes that 802.1Q headers are used only inside Ethernet II frames, not inside SNAP-encapsulated frames. But the kernel and user flow_extract() implementations would interpret 802.1Q headers inside SNAP headers as being valid VLANs. This would cause packet corruption if any VLAN-related actions were to be taken, so change the two flow_extract() implementations only to accept 802.1Q as an Ethernet II frame type, not as a SNAP-encoded frame type. 802.1Q-2005 says that this is correct anyhow: Where the ISS instance used to transmit and receive tagged frames is provided by a media access control method that can support Ethernet Type encoding directly (e.g., is an IEEE 802.3 or IEEE 802.11 MAC) or is media access method independent (e.g., 6.6), the TPID is Ethernet Type encoded, i.e., is two octets in length and comprises solely the assigned Ethernet Type value. Where the ISS instance is provided by a media access method that cannot directly support Ethernet Type encoding (e.g., is an IEEE 802.5 or FDDI MAC), the TPID is encoded according to the rule for a Subnetwork Access Protocol (Clause 10 of IEEE Std 802) that encapsulates Ethernet frames over LLC, and comprises the SNAP header (AA-AA-03) followed by the SNAP PID (00-00-00) followed by the two octets of the assigned Ethernet Type value. All of the media that OVS handles supports Ethernet Type fields, so to me that means that we don't have to handle 802.1Q-inside-SNAP. On the other hand, we *do* have to handle SNAP-inside-802.1Q, because this is actually allowed by the standards. So this commit also adds that support. I verified that, with this change, both SNAP and Ethernet packets are properly recognized both with and without 802.1Q encapsulation. I was a bit surprised to find out that Linux does not accept SNAP-encapsulated IP frames on Ethernet. Here's a summary of how frames are handled before and after this commit: Common cases ------------ Ethernet +------------+ 1. |dst|src|TYPE| +------------+ Ethernet LLC SNAP +------------+ +--------+ +-----------+ 2. |dst|src| len| |aa|aa|03| |000000|TYPE| +------------+ +--------+ +-----------+ Ethernet 802.1Q +------------+ +---------+ 3. |dst|src|8100| |VLAN|TYPE| +------------+ +---------+ Ethernet 802.1Q LLC SNAP +------------+ +---------+ +--------+ +-----------+ 4. |dst|src|8100| |VLAN| LEN| |aa|aa|03| |000000|TYPE| +------------+ +---------+ +--------+ +-----------+ Unusual cases ------------- Ethernet LLC SNAP 802.1Q +------------+ +--------+ +-----------+ +---------+ 5. |dst|src| len| |aa|aa|03| |000000|8100| |VLAN|TYPE| +------------+ +--------+ +-----------+ +---------+ Ethernet LLC +------------+ +--------+ 6. |dst|src| len| |xx|xx|xx| +------------+ +--------+ Ethernet LLC SNAP +------------+ +--------+ +-----------+ 7. |dst|src| len| |aa|aa|03| |xxxxxx|xxxx| +------------+ +--------+ +-----------+ Ethernet 802.1Q LLC +------------+ +---------+ +--------+ 8. |dst|src|8100| |VLAN| LEN| |xx|xx|xx| +------------+ +---------+ +--------+ Ethernet 802.1Q LLC SNAP +------------+ +---------+ +--------+ +-----------+ 9. |dst|src|8100| |VLAN| LEN| |aa|aa|03| |xxxxxx|xxxx| +------------+ +---------+ +--------+ +-----------+ Behavior -------- --------------- --------------- ------------------------------------- Before After this commit this commit dl_type dl_vlan dl_type dl_vlan Notes ------- ------- ------- ------- ------------------------------------- 1. TYPE ffff TYPE ffff no change 2. TYPE ffff TYPE ffff no change 3. TYPE VLAN TYPE VLAN no change 4. LEN VLAN TYPE VLAN proposal fixes behavior 5. TYPE VLAN 8100 ffff 802.1Q says this is invalid framing 6. 05ff ffff 05ff ffff no change 7. 05ff ffff 05ff ffff no change 8. LEN VLAN 05ff VLAN proposal fixes behavior 9. LEN VLAN 05ff VLAN proposal fixes behavior Signed-off-by: Ben Pfaff <blp@nicira.com>
2010-08-10 11:35:46 -07:00
}
/* This needs to be after the parse_ipv6_ext_hdrs__() call because it
* leaves the nw_frag word uninitialized. */
ASSERT_SEQUENTIAL(ipv6_label, nw_frag);
ovs_be32 label = tc_flow & htonl(IPV6_LABEL_MASK);
miniflow_push_be32(mf, ipv6_label, label);
} else {
if (dl_type == htons(ETH_TYPE_ARP) ||
dl_type == htons(ETH_TYPE_RARP)) {
struct eth_addr arp_buf[2];
const struct arp_eth_header *arp = (const struct arp_eth_header *)
data_try_pull(&data, &size, ARP_ETH_HEADER_LEN);
if (OVS_LIKELY(arp) && OVS_LIKELY(arp->ar_hrd == htons(1))
&& OVS_LIKELY(arp->ar_pro == htons(ETH_TYPE_IP))
&& OVS_LIKELY(arp->ar_hln == ETH_ADDR_LEN)
&& OVS_LIKELY(arp->ar_pln == 4)) {
miniflow_push_be32(mf, nw_src,
get_16aligned_be32(&arp->ar_spa));
miniflow_push_be32(mf, nw_dst,
get_16aligned_be32(&arp->ar_tpa));
/* We only match on the lower 8 bits of the opcode. */
if (OVS_LIKELY(ntohs(arp->ar_op) <= 0xff)) {
miniflow_push_be32(mf, ipv6_label, 0); /* Pad with ARP. */
miniflow_push_be32(mf, nw_frag, htonl(ntohs(arp->ar_op)));
}
/* Must be adjacent. */
ASSERT_SEQUENTIAL(arp_sha, arp_tha);
arp_buf[0] = arp->ar_sha;
arp_buf[1] = arp->ar_tha;
miniflow_push_macs(mf, arp_sha, arp_buf);
miniflow_pad_to_64(mf, arp_tha);
}
} else if (dl_type == htons(ETH_TYPE_NSH)) {
struct ovs_key_nsh nsh;
if (OVS_LIKELY(parse_nsh(&data, &size, &nsh))) {
miniflow_push_words(mf, nsh, &nsh,
sizeof(struct ovs_key_nsh) /
sizeof(uint64_t));
}
}
goto out;
}
userspace: Add packet_type in dp_packet and flow This commit adds a packet_type attribute to the structs dp_packet and flow to explicitly carry the type of the packet as prepration for the introduction of the so-called packet type-aware pipeline (PTAP) in OVS. The packet_type is a big-endian 32 bit integer with the encoding as specified in OpenFlow verion 1.5. The upper 16 bits contain the packet type name space. Pre-defined values are defined in openflow-common.h: enum ofp_header_type_namespaces { OFPHTN_ONF = 0, /* ONF namespace. */ OFPHTN_ETHERTYPE = 1, /* ns_type is an Ethertype. */ OFPHTN_IP_PROTO = 2, /* ns_type is a IP protocol number. */ OFPHTN_UDP_TCP_PORT = 3, /* ns_type is a TCP or UDP port. */ OFPHTN_IPV4_OPTION = 4, /* ns_type is an IPv4 option number. */ }; The lower 16 bits specify the actual type in the context of the name space. Only name spaces 0 and 1 will be supported for now. For name space OFPHTN_ONF the relevant packet type is 0 (Ethernet). This is the default packet_type in OVS and the only one supported so far. Packets of type (OFPHTN_ONF, 0) are called Ethernet packets. In name space OFPHTN_ETHERTYPE the type is the Ethertype of the packet. A packet of type (OFPHTN_ETHERTYPE, <Ethertype>) is a standard L2 packet whith the Ethernet header (and any VLAN tags) removed to expose the L3 (or L2.5) payload of the packet. These will simply be called L3 packets. The Ethernet address fields dl_src and dl_dst in struct flow are not applicable for an L3 packet and must be zero. However, to maintain compatibility with the large code base, we have chosen to copy the Ethertype of an L3 packet into the the dl_type field of struct flow. This does not mean that it will be possible to match on dl_type for L3 packets with PTAP later on. Matching must be done on packet_type instead. New dp_packets are initialized with packet_type Ethernet. Ports that receive L3 packets will have to explicitly adjust the packet_type. Signed-off-by: Jean Tourrilhes <jt@labs.hpe.com> Signed-off-by: Jan Scheurich <jan.scheurich@ericsson.com> Co-authored-by: Zoltan Balogh <zoltan.balogh@ericsson.com> Signed-off-by: Ben Pfaff <blp@ovn.org>
2017-04-25 16:29:59 +00:00
packet->l4_ofs = (char *)data - frame;
miniflow_push_be32(mf, nw_frag,
bytes_to_be32(nw_frag, nw_tos, nw_ttl, nw_proto));
if (OVS_LIKELY(!(nw_frag & FLOW_NW_FRAG_LATER))) {
if (OVS_LIKELY(nw_proto == IPPROTO_TCP)) {
if (OVS_LIKELY(size >= TCP_HEADER_LEN)) {
const struct tcp_header *tcp = data;
size_t tcp_hdr_len = TCP_OFFSET(tcp->tcp_ctl) * 4;
if (OVS_LIKELY(tcp_hdr_len >= TCP_HEADER_LEN)
&& OVS_LIKELY(size >= tcp_hdr_len)) {
/* tcp_flags are not at the beginning of the block. */
miniflow_pad_from_64(mf, tcp_flags);
miniflow_push_be32(mf, tcp_flags,
TCP_FLAGS_BE32(tcp->tcp_ctl));
miniflow_push_be16(mf, tp_src, tcp->tcp_src);
miniflow_push_be16(mf, tp_dst, tcp->tcp_dst);
miniflow_push_be16(mf, ct_tp_src, ct_tp_src);
miniflow_push_be16(mf, ct_tp_dst, ct_tp_dst);
if (dl_type == htons(ETH_TYPE_IP)) {
dp_packet_update_rss_hash_ipv4_tcp_udp(packet);
} else if (dl_type == htons(ETH_TYPE_IPV6)) {
dp_packet_update_rss_hash_ipv6_tcp_udp(packet);
}
dp_packet_l4_proto_set_tcp(packet);
}
}
} else if (OVS_LIKELY(nw_proto == IPPROTO_UDP)) {
if (OVS_LIKELY(size >= UDP_HEADER_LEN)) {
const struct udp_header *udp = data;
miniflow_push_be16(mf, tp_src, udp->udp_src);
miniflow_push_be16(mf, tp_dst, udp->udp_dst);
miniflow_push_be16(mf, ct_tp_src, ct_tp_src);
miniflow_push_be16(mf, ct_tp_dst, ct_tp_dst);
if (dl_type == htons(ETH_TYPE_IP)) {
dp_packet_update_rss_hash_ipv4_tcp_udp(packet);
} else if (dl_type == htons(ETH_TYPE_IPV6)) {
dp_packet_update_rss_hash_ipv6_tcp_udp(packet);
}
dp_packet_l4_proto_set_udp(packet);
}
} else if (OVS_LIKELY(nw_proto == IPPROTO_SCTP)) {
if (OVS_LIKELY(size >= SCTP_HEADER_LEN)) {
const struct sctp_header *sctp = data;
miniflow_push_be16(mf, tp_src, sctp->sctp_src);
miniflow_push_be16(mf, tp_dst, sctp->sctp_dst);
miniflow_push_be16(mf, ct_tp_src, ct_tp_src);
miniflow_push_be16(mf, ct_tp_dst, ct_tp_dst);
dp_packet_l4_proto_set_sctp(packet);
}
} else if (OVS_LIKELY(nw_proto == IPPROTO_ICMP)) {
if (OVS_LIKELY(size >= ICMP_HEADER_LEN)) {
const struct icmp_header *icmp = data;
miniflow_push_be16(mf, tp_src, htons(icmp->icmp_type));
miniflow_push_be16(mf, tp_dst, htons(icmp->icmp_code));
miniflow_push_be16(mf, ct_tp_src, ct_tp_src);
miniflow_push_be16(mf, ct_tp_dst, ct_tp_dst);
}
} else if (OVS_LIKELY(nw_proto == IPPROTO_IGMP)) {
if (OVS_LIKELY(size >= IGMP_HEADER_LEN)) {
const struct igmp_header *igmp = data;
miniflow_push_be16(mf, tp_src, htons(igmp->igmp_type));
miniflow_push_be16(mf, tp_dst, htons(igmp->igmp_code));
/* ct_tp_src/dst are not extracted for IGMP. */
miniflow_pad_to_64(mf, tp_dst);
miniflow_push_be32(mf, igmp_group_ip4,
get_16aligned_be32(&igmp->group));
miniflow_pad_to_64(mf, igmp_group_ip4);
}
} else if (OVS_LIKELY(nw_proto == IPPROTO_ICMPV6)) {
if (OVS_LIKELY(size >= sizeof(struct icmp6_data_header))) {
flow: Fix unaligned access to the ND target in miniflow_extract. The data in the buffer are aligned to 2 bytes, however 'struct in6_addr' is aligned to 4 bytes. Use the 2 bytes aligned equivalent 'union ovs_16aligned_in6_addr' instead. This was caught by one of the OVN tests: lib/flow.c:1133:25: runtime error: load of misaligned address 0x51400009cc92 for type 'const struct in6_addr *', which requires 4 byte alignment 0x51400009cc92: note: pointer points here 00 00 00 00 10 00 00 00 00 00 00 00 00 00 00 00 00 00 ^ 0 0x8255b2 in miniflow_extract lib/flow.c:1133:25 1 0x81d921 in flow_extract lib/flow.c:671:5 2 0xa966d4 in ofp_packet_to_string lib/ofp-print.c:82:5 3 0xa76de2 in ofputil_packet_in_private_format lib/ofp-packet.c:1037:24 4 0xa99817 in ofp_print_packet_in lib/ofp-print.c:132:9 5 0xa97f46 in ofp_to_string__ lib/ofp-print.c 6 0xa97f46 in ofp_to_string lib/ofp-print.c:1264:21 7 0xc338f4 in do_send lib/vconn.c:687:19 8 0xb7f678 in try_send lib/rconn.c:1128:14 9 0xb7d725 in rconn_send__ lib/rconn.c:760:13 10 0xb7d8e7 in rconn_send_with_limit lib/rconn.c:816:17 11 0x6f70de in do_send_packet_ins ofproto/connmgr.c:1697:13 12 0x6f691f in connmgr_send_async_msg ofproto/connmgr.c:1682:9 13 0x5c2d23 in run ofproto/ofproto-dpif.c:1877:13 14 0x56737f in ofproto_run ofproto/ofproto.c:1906:13 15 0x50d4fc in bridge_run__ vswitchd/bridge.c:3287:9 16 0x50a764 in bridge_run vswitchd/bridge.c:3346:5 17 0x53eed7 in main vswitchd/ovs-vswitchd.c:130:9 Acked-by: Simon Horman <horms@ovn.org> Signed-off-by: Ales Musil <amusil@redhat.com> Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
2024-07-16 13:45:53 +02:00
const union ovs_16aligned_in6_addr *nd_target;
struct eth_addr arp_buf[2];
/* This will populate whether we received Option 1
* or Option 2. */
uint8_t opt_type;
/* This holds the ND Reserved field. */
ovs_be32 rso_flags;
const struct icmp6_data_header *icmp6;
icmp6 = data_pull(&data, &size, sizeof *icmp6);
if (parse_icmpv6(&data, &size, icmp6,
&rso_flags, &nd_target, arp_buf, &opt_type)) {
if (nd_target) {
miniflow_push_words(mf, nd_target, nd_target,
sizeof *nd_target / sizeof(uint64_t));
}
miniflow_push_macs(mf, arp_sha, arp_buf);
/* Populate options field and set the padding
* accordingly. */
if (opt_type != 0) {
miniflow_push_be16(mf, tcp_flags, htons(opt_type));
/* Pad to align with 64 bits.
* This will zero out the pad3 field. */
miniflow_pad_to_64(mf, tcp_flags);
} else {
/* Pad to align with 64 bits.
* This will zero out the tcp_flags & pad3 field. */
miniflow_pad_to_64(mf, arp_tha);
}
miniflow_push_be16(mf, tp_src,
htons(icmp6->icmp6_base.icmp6_type));
miniflow_push_be16(mf, tp_dst,
htons(icmp6->icmp6_base.icmp6_code));
miniflow_pad_to_64(mf, tp_dst);
/* Fill ND reserved field. */
miniflow_push_be32(mf, igmp_group_ip4, rso_flags);
miniflow_pad_to_64(mf, igmp_group_ip4);
} else {
/* ICMPv6 but not ND. */
miniflow_push_be16(mf, tp_src,
htons(icmp6->icmp6_base.icmp6_type));
miniflow_push_be16(mf, tp_dst,
htons(icmp6->icmp6_base.icmp6_code));
miniflow_push_be16(mf, ct_tp_src, ct_tp_src);
miniflow_push_be16(mf, ct_tp_dst, ct_tp_dst);
}
}
}
} else if (ct_nw_proto_p &&
(*ct_nw_proto_p == IPPROTO_TCP ||
*ct_nw_proto_p == IPPROTO_UDP ||
*ct_nw_proto_p == IPPROTO_SCTP ||
*ct_nw_proto_p == IPPROTO_ICMP ||
(*ct_nw_proto_p == IPPROTO_ICMPV6 && !icmp6_is_nd(data)))) {
miniflow_pad_from_64(mf, ct_tp_src);
miniflow_push_be16(mf, ct_tp_src, ct_tp_src);
miniflow_push_be16(mf, ct_tp_dst, ct_tp_dst);
}
out:
dst->map = mf.map;
}
flow: Fix crash on vlan packets with partial offloading. parse_tcp_flags() does not care about vlan tags in a packet thus not able to parse them. As a result, if partial offloading is enabled in userspace datapath vlan packets are not parsed, i.e. has no initialized offsets. This causes OVS crash on any attempt to access/modify packet header fields. For example, having the flow with following actions: in_port=1,ip,actions=mod_nw_src:192.168.0.7,output:IN_PORT will lead to OVS crash on vlan packet handling: Process terminating with default action of signal 11 (SIGSEGV) Invalid read of size 4 at 0x785657: get_16aligned_be32 (unaligned.h:249) by 0x785657: odp_set_ipv4 (odp-execute.c:82) by 0x785657: odp_execute_masked_set_action (odp-execute.c:527) by 0x785657: odp_execute_actions (odp-execute.c:894) by 0x74CDA9: dp_netdev_execute_actions (dpif-netdev.c:7355) by 0x74CDA9: packet_batch_per_flow_execute (dpif-netdev.c:6339) by 0x74CDA9: dp_netdev_input__ (dpif-netdev.c:6845) by 0x74DB6E: dp_netdev_input (dpif-netdev.c:6854) by 0x74DB6E: dp_netdev_process_rxq_port (dpif-netdev.c:4287) by 0x74E863: dpif_netdev_run (dpif-netdev.c:5264) by 0x703F57: type_run (ofproto-dpif.c:370) by 0x6EC8B8: ofproto_type_run (ofproto.c:1760) by 0x6DA52B: bridge_run__ (bridge.c:3188) by 0x6E083F: bridge_run (bridge.c:3252) by 0x1642E4: main (ovs-vswitchd.c:127) Address 0xc is not stack'd, malloc'd or (recently) free'd Fix that by properly parsing vlan tags first. Function 'parse_dl_type' transformed for that purpose as it had no users anyway. Added unit test for packet modification with partial offloading that triggers above crash. Fixes: aab96ec4d81e ("dpif-netdev: retrieve flow directly from the flow mark") Signed-off-by: Ilya Maximets <i.maximets@ovn.org> Acked-by: Ben Pfaff <blp@ovn.org>
2019-10-23 22:26:52 +02:00
static ovs_be16
dpif-netdev: Forwarding optimization for flows with a simple match. There are cases where users might want simple forwarding or drop rules for all packets received from a specific port, e.g :: "in_port=1,actions=2" "in_port=2,actions=IN_PORT" "in_port=3,vlan_tci=0x1234/0x1fff,actions=drop" "in_port=4,actions=push_vlan:0x8100,set_field:4196->vlan_vid,output:3" There are also cases where complex OpenFlow rules can be simplified down to datapath flows with very simple match criteria. In theory, for very simple forwarding, OVS doesn't need to parse packets at all in order to follow these rules. "Simple match" lookup optimization is intended to speed up packet forwarding in these cases. Design: Due to various implementation constraints userspace datapath has following flow fields always in exact match (i.e. it's required to match at least these fields of a packet even if the OF rule doesn't need that): - recirc_id - in_port - packet_type - dl_type - vlan_tci (CFI + VID) - in most cases - nw_frag - for ip packets Not all of these fields are related to packet itself. We already know the current 'recirc_id' and the 'in_port' before starting the packet processing. It also seems safe to assume that we're working with Ethernet packets. So, for the simple OF rule we need to match only on 'dl_type', 'vlan_tci' and 'nw_frag'. 'in_port', 'dl_type', 'nw_frag' and 13 bits of 'vlan_tci' can be combined in a single 64bit integer (mark) that can be used as a hash in hash map. We are using only VID and CFI form the 'vlan_tci', flows that need to match on PCP will not qualify for the optimization. Workaround for matching on non-existence of vlan updated to match on CFI and VID only in order to qualify for the optimization. CFI is always set by OVS if vlan is present in a packet, so there is no need to match on PCP in this case. 'nw_frag' takes 2 bits of PCP inside the simple match mark. New per-PMD flow table 'simple_match_table' introduced to store simple match flows only. 'dp_netdev_flow_add' adds flow to the usual 'flow_table' and to the 'simple_match_table' if the flow meets following constraints: - 'recirc_id' in flow match is 0. - 'packet_type' in flow match is Ethernet. - Flow wildcards contains only minimal set of non-wildcarded fields (listed above). If the number of flows for current 'in_port' in a regular 'flow_table' equals number of flows for current 'in_port' in a 'simple_match_table', we may use simple match optimization, because all the flows we have are simple match flows. This means that we only need to parse 'dl_type', 'vlan_tci' and 'nw_frag' to perform packet matching. Now we make the unique flow mark from the 'in_port', 'dl_type', 'nw_frag' and 'vlan_tci' and looking for it in the 'simple_match_table'. On successful lookup we don't need to run full 'miniflow_extract()'. Unsuccessful lookup technically means that we have no suitable flow in the datapath and upcall will be required. So, in this case EMC and SMC lookups are disabled. We may optimize this path in the future by bypassing the dpcls lookup too. Performance improvement of this solution on a 'simple match' flows should be comparable with partial HW offloading, because it parses same packet fields and uses similar flow lookup scheme. However, unlike partial HW offloading, it works for all port types including virtual ones. Performance results when compared to EMC: Test setup: virtio-user OVS virtio-user Testpmd1 ------------> pmd1 ------------> Testpmd2 (txonly) x<------ pmd2 <------------ (mac swap) Single stream of 64byte packets. Actions: in_port=vhost0,actions=vhost1 in_port=vhost1,actions=vhost0 Stats collected from pmd1 and pmd2, so there are 2 scenarios: Virt-to-Virt : Testpmd1 ------> pmd1 ------> Testpmd2. Virt-to-NoCopy : Testpmd2 ------> pmd2 --->x Testpmd1. Here the packet sent from pmd2 to Testpmd1 is always dropped, because the virtqueue is full since Testpmd1 is in txonly mode and doesn't receive any packets. This should be closer to the performance of a VM-to-Phy scenario. Test performed on machine with Intel Xeon CPU E5-2690 v4 @ 2.60GHz. Table below represents improvement in throughput when compared to EMC. +----------------+------------------------+------------------------+ | | Default (-g -O2) | "-Ofast -march=native" | | Scenario +------------+-----------+------------+-----------+ | | GCC | Clang | GCC | Clang | +----------------+------------+-----------+------------+-----------+ | Virt-to-Virt | +18.9% | +25.5% | +10.8% | +16.7% | | Virt-to-NoCopy | +24.3% | +33.7% | +14.9% | +22.0% | +----------------+------------+-----------+------------+-----------+ For Phy-to-Phy case performance improvement should be even higher, but it's not the main use-case for this functionality. Performance difference for the non-simple flows is within a margin of error. Acked-by: Sriharsha Basavapatna <sriharsha.basavapatna@broadcom.com> Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
2021-08-09 14:57:52 +02:00
parse_dl_type(const void **datap, size_t *sizep, ovs_be16 *first_vlan_tci_p)
{
union flow_vlan_hdr vlans[FLOW_MAX_VLAN_HEADERS];
dpif-netdev: Forwarding optimization for flows with a simple match. There are cases where users might want simple forwarding or drop rules for all packets received from a specific port, e.g :: "in_port=1,actions=2" "in_port=2,actions=IN_PORT" "in_port=3,vlan_tci=0x1234/0x1fff,actions=drop" "in_port=4,actions=push_vlan:0x8100,set_field:4196->vlan_vid,output:3" There are also cases where complex OpenFlow rules can be simplified down to datapath flows with very simple match criteria. In theory, for very simple forwarding, OVS doesn't need to parse packets at all in order to follow these rules. "Simple match" lookup optimization is intended to speed up packet forwarding in these cases. Design: Due to various implementation constraints userspace datapath has following flow fields always in exact match (i.e. it's required to match at least these fields of a packet even if the OF rule doesn't need that): - recirc_id - in_port - packet_type - dl_type - vlan_tci (CFI + VID) - in most cases - nw_frag - for ip packets Not all of these fields are related to packet itself. We already know the current 'recirc_id' and the 'in_port' before starting the packet processing. It also seems safe to assume that we're working with Ethernet packets. So, for the simple OF rule we need to match only on 'dl_type', 'vlan_tci' and 'nw_frag'. 'in_port', 'dl_type', 'nw_frag' and 13 bits of 'vlan_tci' can be combined in a single 64bit integer (mark) that can be used as a hash in hash map. We are using only VID and CFI form the 'vlan_tci', flows that need to match on PCP will not qualify for the optimization. Workaround for matching on non-existence of vlan updated to match on CFI and VID only in order to qualify for the optimization. CFI is always set by OVS if vlan is present in a packet, so there is no need to match on PCP in this case. 'nw_frag' takes 2 bits of PCP inside the simple match mark. New per-PMD flow table 'simple_match_table' introduced to store simple match flows only. 'dp_netdev_flow_add' adds flow to the usual 'flow_table' and to the 'simple_match_table' if the flow meets following constraints: - 'recirc_id' in flow match is 0. - 'packet_type' in flow match is Ethernet. - Flow wildcards contains only minimal set of non-wildcarded fields (listed above). If the number of flows for current 'in_port' in a regular 'flow_table' equals number of flows for current 'in_port' in a 'simple_match_table', we may use simple match optimization, because all the flows we have are simple match flows. This means that we only need to parse 'dl_type', 'vlan_tci' and 'nw_frag' to perform packet matching. Now we make the unique flow mark from the 'in_port', 'dl_type', 'nw_frag' and 'vlan_tci' and looking for it in the 'simple_match_table'. On successful lookup we don't need to run full 'miniflow_extract()'. Unsuccessful lookup technically means that we have no suitable flow in the datapath and upcall will be required. So, in this case EMC and SMC lookups are disabled. We may optimize this path in the future by bypassing the dpcls lookup too. Performance improvement of this solution on a 'simple match' flows should be comparable with partial HW offloading, because it parses same packet fields and uses similar flow lookup scheme. However, unlike partial HW offloading, it works for all port types including virtual ones. Performance results when compared to EMC: Test setup: virtio-user OVS virtio-user Testpmd1 ------------> pmd1 ------------> Testpmd2 (txonly) x<------ pmd2 <------------ (mac swap) Single stream of 64byte packets. Actions: in_port=vhost0,actions=vhost1 in_port=vhost1,actions=vhost0 Stats collected from pmd1 and pmd2, so there are 2 scenarios: Virt-to-Virt : Testpmd1 ------> pmd1 ------> Testpmd2. Virt-to-NoCopy : Testpmd2 ------> pmd2 --->x Testpmd1. Here the packet sent from pmd2 to Testpmd1 is always dropped, because the virtqueue is full since Testpmd1 is in txonly mode and doesn't receive any packets. This should be closer to the performance of a VM-to-Phy scenario. Test performed on machine with Intel Xeon CPU E5-2690 v4 @ 2.60GHz. Table below represents improvement in throughput when compared to EMC. +----------------+------------------------+------------------------+ | | Default (-g -O2) | "-Ofast -march=native" | | Scenario +------------+-----------+------------+-----------+ | | GCC | Clang | GCC | Clang | +----------------+------------+-----------+------------+-----------+ | Virt-to-Virt | +18.9% | +25.5% | +10.8% | +16.7% | | Virt-to-NoCopy | +24.3% | +33.7% | +14.9% | +22.0% | +----------------+------------+-----------+------------+-----------+ For Phy-to-Phy case performance improvement should be even higher, but it's not the main use-case for this functionality. Performance difference for the non-simple flows is within a margin of error. Acked-by: Sriharsha Basavapatna <sriharsha.basavapatna@broadcom.com> Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
2021-08-09 14:57:52 +02:00
if (parse_vlan(datap, sizep, vlans) && first_vlan_tci_p) {
*first_vlan_tci_p = vlans[0].tci;
}
flow: Fix crash on vlan packets with partial offloading. parse_tcp_flags() does not care about vlan tags in a packet thus not able to parse them. As a result, if partial offloading is enabled in userspace datapath vlan packets are not parsed, i.e. has no initialized offsets. This causes OVS crash on any attempt to access/modify packet header fields. For example, having the flow with following actions: in_port=1,ip,actions=mod_nw_src:192.168.0.7,output:IN_PORT will lead to OVS crash on vlan packet handling: Process terminating with default action of signal 11 (SIGSEGV) Invalid read of size 4 at 0x785657: get_16aligned_be32 (unaligned.h:249) by 0x785657: odp_set_ipv4 (odp-execute.c:82) by 0x785657: odp_execute_masked_set_action (odp-execute.c:527) by 0x785657: odp_execute_actions (odp-execute.c:894) by 0x74CDA9: dp_netdev_execute_actions (dpif-netdev.c:7355) by 0x74CDA9: packet_batch_per_flow_execute (dpif-netdev.c:6339) by 0x74CDA9: dp_netdev_input__ (dpif-netdev.c:6845) by 0x74DB6E: dp_netdev_input (dpif-netdev.c:6854) by 0x74DB6E: dp_netdev_process_rxq_port (dpif-netdev.c:4287) by 0x74E863: dpif_netdev_run (dpif-netdev.c:5264) by 0x703F57: type_run (ofproto-dpif.c:370) by 0x6EC8B8: ofproto_type_run (ofproto.c:1760) by 0x6DA52B: bridge_run__ (bridge.c:3188) by 0x6E083F: bridge_run (bridge.c:3252) by 0x1642E4: main (ovs-vswitchd.c:127) Address 0xc is not stack'd, malloc'd or (recently) free'd Fix that by properly parsing vlan tags first. Function 'parse_dl_type' transformed for that purpose as it had no users anyway. Added unit test for packet modification with partial offloading that triggers above crash. Fixes: aab96ec4d81e ("dpif-netdev: retrieve flow directly from the flow mark") Signed-off-by: Ilya Maximets <i.maximets@ovn.org> Acked-by: Ben Pfaff <blp@ovn.org>
2019-10-23 22:26:52 +02:00
return parse_ethertype(datap, sizep);
}
/* Parses and return the TCP flags in 'packet', converted to host byte order.
* If 'packet' is not an Ethernet packet embedding TCP, returns 0.
dpif-netdev: Forwarding optimization for flows with a simple match. There are cases where users might want simple forwarding or drop rules for all packets received from a specific port, e.g :: "in_port=1,actions=2" "in_port=2,actions=IN_PORT" "in_port=3,vlan_tci=0x1234/0x1fff,actions=drop" "in_port=4,actions=push_vlan:0x8100,set_field:4196->vlan_vid,output:3" There are also cases where complex OpenFlow rules can be simplified down to datapath flows with very simple match criteria. In theory, for very simple forwarding, OVS doesn't need to parse packets at all in order to follow these rules. "Simple match" lookup optimization is intended to speed up packet forwarding in these cases. Design: Due to various implementation constraints userspace datapath has following flow fields always in exact match (i.e. it's required to match at least these fields of a packet even if the OF rule doesn't need that): - recirc_id - in_port - packet_type - dl_type - vlan_tci (CFI + VID) - in most cases - nw_frag - for ip packets Not all of these fields are related to packet itself. We already know the current 'recirc_id' and the 'in_port' before starting the packet processing. It also seems safe to assume that we're working with Ethernet packets. So, for the simple OF rule we need to match only on 'dl_type', 'vlan_tci' and 'nw_frag'. 'in_port', 'dl_type', 'nw_frag' and 13 bits of 'vlan_tci' can be combined in a single 64bit integer (mark) that can be used as a hash in hash map. We are using only VID and CFI form the 'vlan_tci', flows that need to match on PCP will not qualify for the optimization. Workaround for matching on non-existence of vlan updated to match on CFI and VID only in order to qualify for the optimization. CFI is always set by OVS if vlan is present in a packet, so there is no need to match on PCP in this case. 'nw_frag' takes 2 bits of PCP inside the simple match mark. New per-PMD flow table 'simple_match_table' introduced to store simple match flows only. 'dp_netdev_flow_add' adds flow to the usual 'flow_table' and to the 'simple_match_table' if the flow meets following constraints: - 'recirc_id' in flow match is 0. - 'packet_type' in flow match is Ethernet. - Flow wildcards contains only minimal set of non-wildcarded fields (listed above). If the number of flows for current 'in_port' in a regular 'flow_table' equals number of flows for current 'in_port' in a 'simple_match_table', we may use simple match optimization, because all the flows we have are simple match flows. This means that we only need to parse 'dl_type', 'vlan_tci' and 'nw_frag' to perform packet matching. Now we make the unique flow mark from the 'in_port', 'dl_type', 'nw_frag' and 'vlan_tci' and looking for it in the 'simple_match_table'. On successful lookup we don't need to run full 'miniflow_extract()'. Unsuccessful lookup technically means that we have no suitable flow in the datapath and upcall will be required. So, in this case EMC and SMC lookups are disabled. We may optimize this path in the future by bypassing the dpcls lookup too. Performance improvement of this solution on a 'simple match' flows should be comparable with partial HW offloading, because it parses same packet fields and uses similar flow lookup scheme. However, unlike partial HW offloading, it works for all port types including virtual ones. Performance results when compared to EMC: Test setup: virtio-user OVS virtio-user Testpmd1 ------------> pmd1 ------------> Testpmd2 (txonly) x<------ pmd2 <------------ (mac swap) Single stream of 64byte packets. Actions: in_port=vhost0,actions=vhost1 in_port=vhost1,actions=vhost0 Stats collected from pmd1 and pmd2, so there are 2 scenarios: Virt-to-Virt : Testpmd1 ------> pmd1 ------> Testpmd2. Virt-to-NoCopy : Testpmd2 ------> pmd2 --->x Testpmd1. Here the packet sent from pmd2 to Testpmd1 is always dropped, because the virtqueue is full since Testpmd1 is in txonly mode and doesn't receive any packets. This should be closer to the performance of a VM-to-Phy scenario. Test performed on machine with Intel Xeon CPU E5-2690 v4 @ 2.60GHz. Table below represents improvement in throughput when compared to EMC. +----------------+------------------------+------------------------+ | | Default (-g -O2) | "-Ofast -march=native" | | Scenario +------------+-----------+------------+-----------+ | | GCC | Clang | GCC | Clang | +----------------+------------+-----------+------------+-----------+ | Virt-to-Virt | +18.9% | +25.5% | +10.8% | +16.7% | | Virt-to-NoCopy | +24.3% | +33.7% | +14.9% | +22.0% | +----------------+------------+-----------+------------+-----------+ For Phy-to-Phy case performance improvement should be even higher, but it's not the main use-case for this functionality. Performance difference for the non-simple flows is within a margin of error. Acked-by: Sriharsha Basavapatna <sriharsha.basavapatna@broadcom.com> Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
2021-08-09 14:57:52 +02:00
* 'dl_type_p' will be set only if the 'packet' is an Ethernet packet.
* 'nw_frag_p' will be set only if the 'packet' is an IP packet.
* 'first_vlan_tci_p' will be set only if the 'packet' contains vlan header.
*
* The caller must ensure that 'packet' is at least ETH_HEADER_LEN bytes
* long.'*/
uint16_t
dpif-netdev: Forwarding optimization for flows with a simple match. There are cases where users might want simple forwarding or drop rules for all packets received from a specific port, e.g :: "in_port=1,actions=2" "in_port=2,actions=IN_PORT" "in_port=3,vlan_tci=0x1234/0x1fff,actions=drop" "in_port=4,actions=push_vlan:0x8100,set_field:4196->vlan_vid,output:3" There are also cases where complex OpenFlow rules can be simplified down to datapath flows with very simple match criteria. In theory, for very simple forwarding, OVS doesn't need to parse packets at all in order to follow these rules. "Simple match" lookup optimization is intended to speed up packet forwarding in these cases. Design: Due to various implementation constraints userspace datapath has following flow fields always in exact match (i.e. it's required to match at least these fields of a packet even if the OF rule doesn't need that): - recirc_id - in_port - packet_type - dl_type - vlan_tci (CFI + VID) - in most cases - nw_frag - for ip packets Not all of these fields are related to packet itself. We already know the current 'recirc_id' and the 'in_port' before starting the packet processing. It also seems safe to assume that we're working with Ethernet packets. So, for the simple OF rule we need to match only on 'dl_type', 'vlan_tci' and 'nw_frag'. 'in_port', 'dl_type', 'nw_frag' and 13 bits of 'vlan_tci' can be combined in a single 64bit integer (mark) that can be used as a hash in hash map. We are using only VID and CFI form the 'vlan_tci', flows that need to match on PCP will not qualify for the optimization. Workaround for matching on non-existence of vlan updated to match on CFI and VID only in order to qualify for the optimization. CFI is always set by OVS if vlan is present in a packet, so there is no need to match on PCP in this case. 'nw_frag' takes 2 bits of PCP inside the simple match mark. New per-PMD flow table 'simple_match_table' introduced to store simple match flows only. 'dp_netdev_flow_add' adds flow to the usual 'flow_table' and to the 'simple_match_table' if the flow meets following constraints: - 'recirc_id' in flow match is 0. - 'packet_type' in flow match is Ethernet. - Flow wildcards contains only minimal set of non-wildcarded fields (listed above). If the number of flows for current 'in_port' in a regular 'flow_table' equals number of flows for current 'in_port' in a 'simple_match_table', we may use simple match optimization, because all the flows we have are simple match flows. This means that we only need to parse 'dl_type', 'vlan_tci' and 'nw_frag' to perform packet matching. Now we make the unique flow mark from the 'in_port', 'dl_type', 'nw_frag' and 'vlan_tci' and looking for it in the 'simple_match_table'. On successful lookup we don't need to run full 'miniflow_extract()'. Unsuccessful lookup technically means that we have no suitable flow in the datapath and upcall will be required. So, in this case EMC and SMC lookups are disabled. We may optimize this path in the future by bypassing the dpcls lookup too. Performance improvement of this solution on a 'simple match' flows should be comparable with partial HW offloading, because it parses same packet fields and uses similar flow lookup scheme. However, unlike partial HW offloading, it works for all port types including virtual ones. Performance results when compared to EMC: Test setup: virtio-user OVS virtio-user Testpmd1 ------------> pmd1 ------------> Testpmd2 (txonly) x<------ pmd2 <------------ (mac swap) Single stream of 64byte packets. Actions: in_port=vhost0,actions=vhost1 in_port=vhost1,actions=vhost0 Stats collected from pmd1 and pmd2, so there are 2 scenarios: Virt-to-Virt : Testpmd1 ------> pmd1 ------> Testpmd2. Virt-to-NoCopy : Testpmd2 ------> pmd2 --->x Testpmd1. Here the packet sent from pmd2 to Testpmd1 is always dropped, because the virtqueue is full since Testpmd1 is in txonly mode and doesn't receive any packets. This should be closer to the performance of a VM-to-Phy scenario. Test performed on machine with Intel Xeon CPU E5-2690 v4 @ 2.60GHz. Table below represents improvement in throughput when compared to EMC. +----------------+------------------------+------------------------+ | | Default (-g -O2) | "-Ofast -march=native" | | Scenario +------------+-----------+------------+-----------+ | | GCC | Clang | GCC | Clang | +----------------+------------+-----------+------------+-----------+ | Virt-to-Virt | +18.9% | +25.5% | +10.8% | +16.7% | | Virt-to-NoCopy | +24.3% | +33.7% | +14.9% | +22.0% | +----------------+------------+-----------+------------+-----------+ For Phy-to-Phy case performance improvement should be even higher, but it's not the main use-case for this functionality. Performance difference for the non-simple flows is within a margin of error. Acked-by: Sriharsha Basavapatna <sriharsha.basavapatna@broadcom.com> Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
2021-08-09 14:57:52 +02:00
parse_tcp_flags(struct dp_packet *packet,
ovs_be16 *dl_type_p, uint8_t *nw_frag_p,
ovs_be16 *first_vlan_tci_p)
{
const void *data = dp_packet_data(packet);
const char *frame = (const char *)data;
size_t size = dp_packet_size(packet);
ovs_be16 dl_type;
uint8_t nw_frag = 0, nw_proto = 0;
if (!dp_packet_is_eth(packet)) {
return 0;
}
dp_packet_reset_offsets(packet);
dpif-netdev: Forwarding optimization for flows with a simple match. There are cases where users might want simple forwarding or drop rules for all packets received from a specific port, e.g :: "in_port=1,actions=2" "in_port=2,actions=IN_PORT" "in_port=3,vlan_tci=0x1234/0x1fff,actions=drop" "in_port=4,actions=push_vlan:0x8100,set_field:4196->vlan_vid,output:3" There are also cases where complex OpenFlow rules can be simplified down to datapath flows with very simple match criteria. In theory, for very simple forwarding, OVS doesn't need to parse packets at all in order to follow these rules. "Simple match" lookup optimization is intended to speed up packet forwarding in these cases. Design: Due to various implementation constraints userspace datapath has following flow fields always in exact match (i.e. it's required to match at least these fields of a packet even if the OF rule doesn't need that): - recirc_id - in_port - packet_type - dl_type - vlan_tci (CFI + VID) - in most cases - nw_frag - for ip packets Not all of these fields are related to packet itself. We already know the current 'recirc_id' and the 'in_port' before starting the packet processing. It also seems safe to assume that we're working with Ethernet packets. So, for the simple OF rule we need to match only on 'dl_type', 'vlan_tci' and 'nw_frag'. 'in_port', 'dl_type', 'nw_frag' and 13 bits of 'vlan_tci' can be combined in a single 64bit integer (mark) that can be used as a hash in hash map. We are using only VID and CFI form the 'vlan_tci', flows that need to match on PCP will not qualify for the optimization. Workaround for matching on non-existence of vlan updated to match on CFI and VID only in order to qualify for the optimization. CFI is always set by OVS if vlan is present in a packet, so there is no need to match on PCP in this case. 'nw_frag' takes 2 bits of PCP inside the simple match mark. New per-PMD flow table 'simple_match_table' introduced to store simple match flows only. 'dp_netdev_flow_add' adds flow to the usual 'flow_table' and to the 'simple_match_table' if the flow meets following constraints: - 'recirc_id' in flow match is 0. - 'packet_type' in flow match is Ethernet. - Flow wildcards contains only minimal set of non-wildcarded fields (listed above). If the number of flows for current 'in_port' in a regular 'flow_table' equals number of flows for current 'in_port' in a 'simple_match_table', we may use simple match optimization, because all the flows we have are simple match flows. This means that we only need to parse 'dl_type', 'vlan_tci' and 'nw_frag' to perform packet matching. Now we make the unique flow mark from the 'in_port', 'dl_type', 'nw_frag' and 'vlan_tci' and looking for it in the 'simple_match_table'. On successful lookup we don't need to run full 'miniflow_extract()'. Unsuccessful lookup technically means that we have no suitable flow in the datapath and upcall will be required. So, in this case EMC and SMC lookups are disabled. We may optimize this path in the future by bypassing the dpcls lookup too. Performance improvement of this solution on a 'simple match' flows should be comparable with partial HW offloading, because it parses same packet fields and uses similar flow lookup scheme. However, unlike partial HW offloading, it works for all port types including virtual ones. Performance results when compared to EMC: Test setup: virtio-user OVS virtio-user Testpmd1 ------------> pmd1 ------------> Testpmd2 (txonly) x<------ pmd2 <------------ (mac swap) Single stream of 64byte packets. Actions: in_port=vhost0,actions=vhost1 in_port=vhost1,actions=vhost0 Stats collected from pmd1 and pmd2, so there are 2 scenarios: Virt-to-Virt : Testpmd1 ------> pmd1 ------> Testpmd2. Virt-to-NoCopy : Testpmd2 ------> pmd2 --->x Testpmd1. Here the packet sent from pmd2 to Testpmd1 is always dropped, because the virtqueue is full since Testpmd1 is in txonly mode and doesn't receive any packets. This should be closer to the performance of a VM-to-Phy scenario. Test performed on machine with Intel Xeon CPU E5-2690 v4 @ 2.60GHz. Table below represents improvement in throughput when compared to EMC. +----------------+------------------------+------------------------+ | | Default (-g -O2) | "-Ofast -march=native" | | Scenario +------------+-----------+------------+-----------+ | | GCC | Clang | GCC | Clang | +----------------+------------+-----------+------------+-----------+ | Virt-to-Virt | +18.9% | +25.5% | +10.8% | +16.7% | | Virt-to-NoCopy | +24.3% | +33.7% | +14.9% | +22.0% | +----------------+------------+-----------+------------+-----------+ For Phy-to-Phy case performance improvement should be even higher, but it's not the main use-case for this functionality. Performance difference for the non-simple flows is within a margin of error. Acked-by: Sriharsha Basavapatna <sriharsha.basavapatna@broadcom.com> Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
2021-08-09 14:57:52 +02:00
dl_type = parse_dl_type(&data, &size, first_vlan_tci_p);
if (dl_type_p) {
*dl_type_p = dl_type;
}
if (OVS_UNLIKELY(eth_type_mpls(dl_type))) {
packet->l2_5_ofs = (char *)data - frame;
}
packet->l3_ofs = (char *)data - frame;
if (OVS_LIKELY(dl_type == htons(ETH_TYPE_IP))) {
const struct ip_header *nh = data;
int ip_len;
uint16_t tot_len;
if (OVS_UNLIKELY(!ipv4_sanity_check(nh, size, &ip_len, &tot_len))) {
if (OVS_UNLIKELY(VLOG_IS_DBG_ENABLED())) {
dump_invalid_packet(packet, "ipv4_sanity_check");
}
return 0;
}
dp_packet_set_l2_pad_size(packet, size - tot_len);
nw_proto = nh->ip_proto;
nw_frag = ipv4_get_nw_frag(nh);
size = tot_len; /* Never pull padding. */
data_pull(&data, &size, ip_len);
} else if (dl_type == htons(ETH_TYPE_IPV6)) {
const struct ovs_16aligned_ip6_hdr *nh = data;
uint16_t plen;
if (OVS_UNLIKELY(!ipv6_sanity_check(nh, size))) {
if (OVS_UNLIKELY(VLOG_IS_DBG_ENABLED())) {
dump_invalid_packet(packet, "ipv6_sanity_check");
}
return 0;
}
data_pull(&data, &size, sizeof *nh);
plen = ntohs(nh->ip6_plen); /* Never pull padding. */
dp_packet_set_l2_pad_size(packet, size - plen);
size = plen;
nw_proto = nh->ip6_nxt;
if (!parse_ipv6_ext_hdrs(&data, &size, &nw_proto, &nw_frag,
NULL, NULL)) {
return 0;
}
} else {
return 0;
}
dpif-netdev: Forwarding optimization for flows with a simple match. There are cases where users might want simple forwarding or drop rules for all packets received from a specific port, e.g :: "in_port=1,actions=2" "in_port=2,actions=IN_PORT" "in_port=3,vlan_tci=0x1234/0x1fff,actions=drop" "in_port=4,actions=push_vlan:0x8100,set_field:4196->vlan_vid,output:3" There are also cases where complex OpenFlow rules can be simplified down to datapath flows with very simple match criteria. In theory, for very simple forwarding, OVS doesn't need to parse packets at all in order to follow these rules. "Simple match" lookup optimization is intended to speed up packet forwarding in these cases. Design: Due to various implementation constraints userspace datapath has following flow fields always in exact match (i.e. it's required to match at least these fields of a packet even if the OF rule doesn't need that): - recirc_id - in_port - packet_type - dl_type - vlan_tci (CFI + VID) - in most cases - nw_frag - for ip packets Not all of these fields are related to packet itself. We already know the current 'recirc_id' and the 'in_port' before starting the packet processing. It also seems safe to assume that we're working with Ethernet packets. So, for the simple OF rule we need to match only on 'dl_type', 'vlan_tci' and 'nw_frag'. 'in_port', 'dl_type', 'nw_frag' and 13 bits of 'vlan_tci' can be combined in a single 64bit integer (mark) that can be used as a hash in hash map. We are using only VID and CFI form the 'vlan_tci', flows that need to match on PCP will not qualify for the optimization. Workaround for matching on non-existence of vlan updated to match on CFI and VID only in order to qualify for the optimization. CFI is always set by OVS if vlan is present in a packet, so there is no need to match on PCP in this case. 'nw_frag' takes 2 bits of PCP inside the simple match mark. New per-PMD flow table 'simple_match_table' introduced to store simple match flows only. 'dp_netdev_flow_add' adds flow to the usual 'flow_table' and to the 'simple_match_table' if the flow meets following constraints: - 'recirc_id' in flow match is 0. - 'packet_type' in flow match is Ethernet. - Flow wildcards contains only minimal set of non-wildcarded fields (listed above). If the number of flows for current 'in_port' in a regular 'flow_table' equals number of flows for current 'in_port' in a 'simple_match_table', we may use simple match optimization, because all the flows we have are simple match flows. This means that we only need to parse 'dl_type', 'vlan_tci' and 'nw_frag' to perform packet matching. Now we make the unique flow mark from the 'in_port', 'dl_type', 'nw_frag' and 'vlan_tci' and looking for it in the 'simple_match_table'. On successful lookup we don't need to run full 'miniflow_extract()'. Unsuccessful lookup technically means that we have no suitable flow in the datapath and upcall will be required. So, in this case EMC and SMC lookups are disabled. We may optimize this path in the future by bypassing the dpcls lookup too. Performance improvement of this solution on a 'simple match' flows should be comparable with partial HW offloading, because it parses same packet fields and uses similar flow lookup scheme. However, unlike partial HW offloading, it works for all port types including virtual ones. Performance results when compared to EMC: Test setup: virtio-user OVS virtio-user Testpmd1 ------------> pmd1 ------------> Testpmd2 (txonly) x<------ pmd2 <------------ (mac swap) Single stream of 64byte packets. Actions: in_port=vhost0,actions=vhost1 in_port=vhost1,actions=vhost0 Stats collected from pmd1 and pmd2, so there are 2 scenarios: Virt-to-Virt : Testpmd1 ------> pmd1 ------> Testpmd2. Virt-to-NoCopy : Testpmd2 ------> pmd2 --->x Testpmd1. Here the packet sent from pmd2 to Testpmd1 is always dropped, because the virtqueue is full since Testpmd1 is in txonly mode and doesn't receive any packets. This should be closer to the performance of a VM-to-Phy scenario. Test performed on machine with Intel Xeon CPU E5-2690 v4 @ 2.60GHz. Table below represents improvement in throughput when compared to EMC. +----------------+------------------------+------------------------+ | | Default (-g -O2) | "-Ofast -march=native" | | Scenario +------------+-----------+------------+-----------+ | | GCC | Clang | GCC | Clang | +----------------+------------+-----------+------------+-----------+ | Virt-to-Virt | +18.9% | +25.5% | +10.8% | +16.7% | | Virt-to-NoCopy | +24.3% | +33.7% | +14.9% | +22.0% | +----------------+------------+-----------+------------+-----------+ For Phy-to-Phy case performance improvement should be even higher, but it's not the main use-case for this functionality. Performance difference for the non-simple flows is within a margin of error. Acked-by: Sriharsha Basavapatna <sriharsha.basavapatna@broadcom.com> Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
2021-08-09 14:57:52 +02:00
if (nw_frag_p) {
*nw_frag_p = nw_frag;
}
packet->l4_ofs = (uint16_t)((char *)data - frame);
if (!(nw_frag & FLOW_NW_FRAG_LATER)) {
if (nw_proto == IPPROTO_TCP && size >= TCP_HEADER_LEN) {
const struct tcp_header *tcp = data;
dp_packet_l4_proto_set_tcp(packet);
return TCP_FLAGS(tcp->tcp_ctl);
} else if (nw_proto == IPPROTO_UDP && size >= UDP_HEADER_LEN) {
dp_packet_l4_proto_set_udp(packet);
} else if (nw_proto == IPPROTO_SCTP && size >= SCTP_HEADER_LEN) {
dp_packet_l4_proto_set_sctp(packet);
}
}
return 0;
}
/* For every bit of a field that is wildcarded in 'wildcards', sets the
* corresponding bit in 'flow' to zero. */
void
flow_zero_wildcards(struct flow *flow, const struct flow_wildcards *wildcards)
{
uint64_t *flow_u64 = (uint64_t *) flow;
const uint64_t *wc_u64 = (const uint64_t *) &wildcards->masks;
size_t i;
for (i = 0; i < FLOW_U64S; i++) {
flow_u64[i] &= wc_u64[i];
}
}
void
flow_unwildcard_tp_ports(const struct flow *flow, struct flow_wildcards *wc)
{
if (flow->nw_proto != IPPROTO_ICMP) {
memset(&wc->masks.tp_src, 0xff, sizeof wc->masks.tp_src);
memset(&wc->masks.tp_dst, 0xff, sizeof wc->masks.tp_dst);
} else {
wc->masks.tp_src = htons(0xff);
wc->masks.tp_dst = htons(0xff);
}
}
/* Initializes 'flow_metadata' with the metadata found in 'flow'. */
void
flow_get_metadata(const struct flow *flow, struct match *flow_metadata)
{
int i;
BUILD_ASSERT_DECL(FLOW_WC_SEQ == 42);
match_init_catchall(flow_metadata);
if (flow->tunnel.tun_id != htonll(0)) {
match_set_tun_id(flow_metadata, flow->tunnel.tun_id);
}
if (flow->tunnel.flags & FLOW_TNL_PUB_F_MASK) {
match_set_tun_flags(flow_metadata,
flow->tunnel.flags & FLOW_TNL_PUB_F_MASK);
}
if (flow->tunnel.ip_src) {
match_set_tun_src(flow_metadata, flow->tunnel.ip_src);
}
if (flow->tunnel.ip_dst) {
match_set_tun_dst(flow_metadata, flow->tunnel.ip_dst);
}
if (ipv6_addr_is_set(&flow->tunnel.ipv6_src)) {
match_set_tun_ipv6_src(flow_metadata, &flow->tunnel.ipv6_src);
}
if (ipv6_addr_is_set(&flow->tunnel.ipv6_dst)) {
match_set_tun_ipv6_dst(flow_metadata, &flow->tunnel.ipv6_dst);
}
if (flow->tunnel.gbp_id != htons(0)) {
match_set_tun_gbp_id(flow_metadata, flow->tunnel.gbp_id);
}
if (flow->tunnel.gbp_flags) {
match_set_tun_gbp_flags(flow_metadata, flow->tunnel.gbp_flags);
}
if (flow->tunnel.erspan_ver) {
match_set_tun_erspan_ver(flow_metadata, flow->tunnel.erspan_ver);
}
if (flow->tunnel.erspan_idx) {
match_set_tun_erspan_idx(flow_metadata, flow->tunnel.erspan_idx);
}
if (flow->tunnel.erspan_dir) {
match_set_tun_erspan_dir(flow_metadata, flow->tunnel.erspan_dir);
}
if (flow->tunnel.erspan_hwid) {
match_set_tun_erspan_hwid(flow_metadata, flow->tunnel.erspan_hwid);
}
if (flow->tunnel.gtpu_flags) {
match_set_tun_gtpu_flags(flow_metadata, flow->tunnel.gtpu_flags);
}
if (flow->tunnel.gtpu_msgtype) {
match_set_tun_gtpu_msgtype(flow_metadata, flow->tunnel.gtpu_msgtype);
}
dpif-netdev: Translate Geneve options per-flow, not per-packet. The kernel implementation of Geneve options stores the TLV option data in the flow exactly as received, without any further parsing. This is then translated to known options for the purposes of matching on flow setup (which will then install a datapath flow in the form the kernel is expecting). The userspace implementation behaves a little bit differently - it looks up known options as each packet is received. The reason for this is there is a much tighter coupling between datapath and flow translation and the representation is generally expected to be the same. This works but it incurs work on a per-packet basis that could be done per-flow instead. This introduces a small translation step for Geneve packets between datapath and flow lookup for the userspace datapath in order to allow the same kind of processing that the kernel does. A side effect of this is that unknown options are now shown when flows dumped via ovs-appctl dpif/dump-flows, similar to the kernel. There is a second benefit to this as well: for some operations it is preferable to keep the options exactly as they were received on the wire, which this enables. One example is that for packets that are executed from ofproto-dpif-upcall to the datapath, this avoids the translation of Geneve metadata. Since this conversion is potentially lossy (for unknown options), keeping everything in the same format removes the possibility of dropping options if the packet comes back up to userspace and the Geneve option translation table has changed. To help with these types of operations, most functions can understand both formats of data and seamlessly do the right thing. Signed-off-by: Jesse Gross <jesse@nicira.com> Acked-by: Jarno Rajahalme <jrajahalme@nicira.com>
2015-06-29 18:01:59 -07:00
tun_metadata_get_fmd(&flow->tunnel, flow_metadata);
if (flow->metadata != htonll(0)) {
match_set_metadata(flow_metadata, flow->metadata);
}
for (i = 0; i < FLOW_N_REGS; i++) {
if (flow->regs[i]) {
match_set_reg(flow_metadata, i, flow->regs[i]);
}
}
if (flow->pkt_mark != 0) {
match_set_pkt_mark(flow_metadata, flow->pkt_mark);
}
match_set_in_port(flow_metadata, flow->in_port.ofp_port);
if (flow->packet_type != htonl(PT_ETH)) {
match_set_packet_type(flow_metadata, flow->packet_type);
}
Add support for connection tracking. This patch adds a new action and fields to OVS that allow connection tracking to be performed. This support works in conjunction with the Linux kernel support merged into the Linux-4.3 development cycle. Packets have two possible states with respect to connection tracking: Untracked packets have not previously passed through the connection tracker, while tracked packets have previously been through the connection tracker. For OpenFlow pipeline processing, untracked packets can become tracked, and they will remain tracked until the end of the pipeline. Tracked packets cannot become untracked. Connections can be unknown, uncommitted, or committed. Packets which are untracked have unknown connection state. To know the connection state, the packet must become tracked. Uncommitted connections have no connection state stored about them, so it is only possible for the connection tracker to identify whether they are a new connection or whether they are invalid. Committed connections have connection state stored beyond the lifetime of the packet, which allows later packets in the same connection to be identified as part of the same established connection, or related to an existing connection - for instance ICMP error responses. The new 'ct' action transitions the packet from "untracked" to "tracked" by sending this flow through the connection tracker. The following parameters are supported initally: - "commit": When commit is executed, the connection moves from uncommitted state to committed state. This signals that information about the connection should be stored beyond the lifetime of the packet within the pipeline. This allows future packets in the same connection to be recognized as part of the same "established" (est) connection, as well as identifying packets in the reply (rpl) direction, or packets related to an existing connection (rel). - "zone=[u16|NXM]": Perform connection tracking in the zone specified. Each zone is an independent connection tracking context. When the "commit" parameter is used, the connection will only be committed in the specified zone, and not in other zones. This is 0 by default. - "table=NUMBER": Fork pipeline processing in two. The original instance of the packet will continue processing the current actions list as an untracked packet. An additional instance of the packet will be sent to the connection tracker, which will be re-injected into the OpenFlow pipeline to resume processing in the specified table, with the ct_state and other ct match fields set. If the table is not specified, then the packet is submitted to the connection tracker, but the pipeline does not fork and the ct match fields are not populated. It is strongly recommended to specify a table later than the current table to prevent loops. When the "table" option is used, the packet that continues processing in the specified table will have the ct_state populated. The ct_state may have any of the following flags set: - Tracked (trk): Connection tracking has occurred. - Reply (rpl): The flow is in the reply direction. - Invalid (inv): The connection tracker couldn't identify the connection. - New (new): This is the beginning of a new connection. - Established (est): This is part of an already existing connection. - Related (rel): This connection is related to an existing connection. For more information, consult the ovs-ofctl(8) man pages. Below is a simple example flow table to allow outbound TCP traffic from port 1 and drop traffic from port 2 that was not initiated by port 1: table=0,priority=1,action=drop table=0,arp,action=normal table=0,in_port=1,tcp,ct_state=-trk,action=ct(commit,zone=9),2 table=0,in_port=2,tcp,ct_state=-trk,action=ct(zone=9,table=1) table=1,in_port=2,ct_state=+trk+est,tcp,action=1 table=1,in_port=2,ct_state=+trk+new,tcp,action=drop Based on original design by Justin Pettit, contributions from Thomas Graf and Daniele Di Proietto. Signed-off-by: Joe Stringer <joestringer@nicira.com> Acked-by: Jarno Rajahalme <jrajahalme@nicira.com> Acked-by: Ben Pfaff <blp@nicira.com>
2015-08-11 10:56:09 -07:00
if (flow->ct_state != 0) {
match_set_ct_state(flow_metadata, flow->ct_state);
/* Match dl_type since it is required for the later interpretation of
* the conntrack metadata. */
match_set_dl_type(flow_metadata, flow->dl_type);
if (is_ct_valid(flow, NULL, NULL) && flow->ct_nw_proto != 0) {
if (flow->dl_type == htons(ETH_TYPE_IP)) {
match_set_ct_nw_src(flow_metadata, flow->ct_nw_src);
match_set_ct_nw_dst(flow_metadata, flow->ct_nw_dst);
match_set_ct_nw_proto(flow_metadata, flow->ct_nw_proto);
match_set_ct_tp_src(flow_metadata, flow->ct_tp_src);
match_set_ct_tp_dst(flow_metadata, flow->ct_tp_dst);
} else if (flow->dl_type == htons(ETH_TYPE_IPV6)) {
match_set_ct_ipv6_src(flow_metadata, &flow->ct_ipv6_src);
match_set_ct_ipv6_dst(flow_metadata, &flow->ct_ipv6_dst);
match_set_ct_nw_proto(flow_metadata, flow->ct_nw_proto);
match_set_ct_tp_src(flow_metadata, flow->ct_tp_src);
match_set_ct_tp_dst(flow_metadata, flow->ct_tp_dst);
}
}
Add support for connection tracking. This patch adds a new action and fields to OVS that allow connection tracking to be performed. This support works in conjunction with the Linux kernel support merged into the Linux-4.3 development cycle. Packets have two possible states with respect to connection tracking: Untracked packets have not previously passed through the connection tracker, while tracked packets have previously been through the connection tracker. For OpenFlow pipeline processing, untracked packets can become tracked, and they will remain tracked until the end of the pipeline. Tracked packets cannot become untracked. Connections can be unknown, uncommitted, or committed. Packets which are untracked have unknown connection state. To know the connection state, the packet must become tracked. Uncommitted connections have no connection state stored about them, so it is only possible for the connection tracker to identify whether they are a new connection or whether they are invalid. Committed connections have connection state stored beyond the lifetime of the packet, which allows later packets in the same connection to be identified as part of the same established connection, or related to an existing connection - for instance ICMP error responses. The new 'ct' action transitions the packet from "untracked" to "tracked" by sending this flow through the connection tracker. The following parameters are supported initally: - "commit": When commit is executed, the connection moves from uncommitted state to committed state. This signals that information about the connection should be stored beyond the lifetime of the packet within the pipeline. This allows future packets in the same connection to be recognized as part of the same "established" (est) connection, as well as identifying packets in the reply (rpl) direction, or packets related to an existing connection (rel). - "zone=[u16|NXM]": Perform connection tracking in the zone specified. Each zone is an independent connection tracking context. When the "commit" parameter is used, the connection will only be committed in the specified zone, and not in other zones. This is 0 by default. - "table=NUMBER": Fork pipeline processing in two. The original instance of the packet will continue processing the current actions list as an untracked packet. An additional instance of the packet will be sent to the connection tracker, which will be re-injected into the OpenFlow pipeline to resume processing in the specified table, with the ct_state and other ct match fields set. If the table is not specified, then the packet is submitted to the connection tracker, but the pipeline does not fork and the ct match fields are not populated. It is strongly recommended to specify a table later than the current table to prevent loops. When the "table" option is used, the packet that continues processing in the specified table will have the ct_state populated. The ct_state may have any of the following flags set: - Tracked (trk): Connection tracking has occurred. - Reply (rpl): The flow is in the reply direction. - Invalid (inv): The connection tracker couldn't identify the connection. - New (new): This is the beginning of a new connection. - Established (est): This is part of an already existing connection. - Related (rel): This connection is related to an existing connection. For more information, consult the ovs-ofctl(8) man pages. Below is a simple example flow table to allow outbound TCP traffic from port 1 and drop traffic from port 2 that was not initiated by port 1: table=0,priority=1,action=drop table=0,arp,action=normal table=0,in_port=1,tcp,ct_state=-trk,action=ct(commit,zone=9),2 table=0,in_port=2,tcp,ct_state=-trk,action=ct(zone=9,table=1) table=1,in_port=2,ct_state=+trk+est,tcp,action=1 table=1,in_port=2,ct_state=+trk+new,tcp,action=drop Based on original design by Justin Pettit, contributions from Thomas Graf and Daniele Di Proietto. Signed-off-by: Joe Stringer <joestringer@nicira.com> Acked-by: Jarno Rajahalme <jrajahalme@nicira.com> Acked-by: Ben Pfaff <blp@nicira.com>
2015-08-11 10:56:09 -07:00
}
if (flow->ct_zone != 0) {
match_set_ct_zone(flow_metadata, flow->ct_zone);
}
if (flow->ct_mark != 0) {
match_set_ct_mark(flow_metadata, flow->ct_mark);
}
if (!ovs_u128_is_zero(flow->ct_label)) {
match_set_ct_label(flow_metadata, flow->ct_label);
}
Add support for connection tracking. This patch adds a new action and fields to OVS that allow connection tracking to be performed. This support works in conjunction with the Linux kernel support merged into the Linux-4.3 development cycle. Packets have two possible states with respect to connection tracking: Untracked packets have not previously passed through the connection tracker, while tracked packets have previously been through the connection tracker. For OpenFlow pipeline processing, untracked packets can become tracked, and they will remain tracked until the end of the pipeline. Tracked packets cannot become untracked. Connections can be unknown, uncommitted, or committed. Packets which are untracked have unknown connection state. To know the connection state, the packet must become tracked. Uncommitted connections have no connection state stored about them, so it is only possible for the connection tracker to identify whether they are a new connection or whether they are invalid. Committed connections have connection state stored beyond the lifetime of the packet, which allows later packets in the same connection to be identified as part of the same established connection, or related to an existing connection - for instance ICMP error responses. The new 'ct' action transitions the packet from "untracked" to "tracked" by sending this flow through the connection tracker. The following parameters are supported initally: - "commit": When commit is executed, the connection moves from uncommitted state to committed state. This signals that information about the connection should be stored beyond the lifetime of the packet within the pipeline. This allows future packets in the same connection to be recognized as part of the same "established" (est) connection, as well as identifying packets in the reply (rpl) direction, or packets related to an existing connection (rel). - "zone=[u16|NXM]": Perform connection tracking in the zone specified. Each zone is an independent connection tracking context. When the "commit" parameter is used, the connection will only be committed in the specified zone, and not in other zones. This is 0 by default. - "table=NUMBER": Fork pipeline processing in two. The original instance of the packet will continue processing the current actions list as an untracked packet. An additional instance of the packet will be sent to the connection tracker, which will be re-injected into the OpenFlow pipeline to resume processing in the specified table, with the ct_state and other ct match fields set. If the table is not specified, then the packet is submitted to the connection tracker, but the pipeline does not fork and the ct match fields are not populated. It is strongly recommended to specify a table later than the current table to prevent loops. When the "table" option is used, the packet that continues processing in the specified table will have the ct_state populated. The ct_state may have any of the following flags set: - Tracked (trk): Connection tracking has occurred. - Reply (rpl): The flow is in the reply direction. - Invalid (inv): The connection tracker couldn't identify the connection. - New (new): This is the beginning of a new connection. - Established (est): This is part of an already existing connection. - Related (rel): This connection is related to an existing connection. For more information, consult the ovs-ofctl(8) man pages. Below is a simple example flow table to allow outbound TCP traffic from port 1 and drop traffic from port 2 that was not initiated by port 1: table=0,priority=1,action=drop table=0,arp,action=normal table=0,in_port=1,tcp,ct_state=-trk,action=ct(commit,zone=9),2 table=0,in_port=2,tcp,ct_state=-trk,action=ct(zone=9,table=1) table=1,in_port=2,ct_state=+trk+est,tcp,action=1 table=1,in_port=2,ct_state=+trk+new,tcp,action=drop Based on original design by Justin Pettit, contributions from Thomas Graf and Daniele Di Proietto. Signed-off-by: Joe Stringer <joestringer@nicira.com> Acked-by: Jarno Rajahalme <jrajahalme@nicira.com> Acked-by: Ben Pfaff <blp@nicira.com>
2015-08-11 10:56:09 -07:00
}
const char *
ct_state_to_string(uint32_t state)
Add support for connection tracking. This patch adds a new action and fields to OVS that allow connection tracking to be performed. This support works in conjunction with the Linux kernel support merged into the Linux-4.3 development cycle. Packets have two possible states with respect to connection tracking: Untracked packets have not previously passed through the connection tracker, while tracked packets have previously been through the connection tracker. For OpenFlow pipeline processing, untracked packets can become tracked, and they will remain tracked until the end of the pipeline. Tracked packets cannot become untracked. Connections can be unknown, uncommitted, or committed. Packets which are untracked have unknown connection state. To know the connection state, the packet must become tracked. Uncommitted connections have no connection state stored about them, so it is only possible for the connection tracker to identify whether they are a new connection or whether they are invalid. Committed connections have connection state stored beyond the lifetime of the packet, which allows later packets in the same connection to be identified as part of the same established connection, or related to an existing connection - for instance ICMP error responses. The new 'ct' action transitions the packet from "untracked" to "tracked" by sending this flow through the connection tracker. The following parameters are supported initally: - "commit": When commit is executed, the connection moves from uncommitted state to committed state. This signals that information about the connection should be stored beyond the lifetime of the packet within the pipeline. This allows future packets in the same connection to be recognized as part of the same "established" (est) connection, as well as identifying packets in the reply (rpl) direction, or packets related to an existing connection (rel). - "zone=[u16|NXM]": Perform connection tracking in the zone specified. Each zone is an independent connection tracking context. When the "commit" parameter is used, the connection will only be committed in the specified zone, and not in other zones. This is 0 by default. - "table=NUMBER": Fork pipeline processing in two. The original instance of the packet will continue processing the current actions list as an untracked packet. An additional instance of the packet will be sent to the connection tracker, which will be re-injected into the OpenFlow pipeline to resume processing in the specified table, with the ct_state and other ct match fields set. If the table is not specified, then the packet is submitted to the connection tracker, but the pipeline does not fork and the ct match fields are not populated. It is strongly recommended to specify a table later than the current table to prevent loops. When the "table" option is used, the packet that continues processing in the specified table will have the ct_state populated. The ct_state may have any of the following flags set: - Tracked (trk): Connection tracking has occurred. - Reply (rpl): The flow is in the reply direction. - Invalid (inv): The connection tracker couldn't identify the connection. - New (new): This is the beginning of a new connection. - Established (est): This is part of an already existing connection. - Related (rel): This connection is related to an existing connection. For more information, consult the ovs-ofctl(8) man pages. Below is a simple example flow table to allow outbound TCP traffic from port 1 and drop traffic from port 2 that was not initiated by port 1: table=0,priority=1,action=drop table=0,arp,action=normal table=0,in_port=1,tcp,ct_state=-trk,action=ct(commit,zone=9),2 table=0,in_port=2,tcp,ct_state=-trk,action=ct(zone=9,table=1) table=1,in_port=2,ct_state=+trk+est,tcp,action=1 table=1,in_port=2,ct_state=+trk+new,tcp,action=drop Based on original design by Justin Pettit, contributions from Thomas Graf and Daniele Di Proietto. Signed-off-by: Joe Stringer <joestringer@nicira.com> Acked-by: Jarno Rajahalme <jrajahalme@nicira.com> Acked-by: Ben Pfaff <blp@nicira.com>
2015-08-11 10:56:09 -07:00
{
switch (state) {
#define CS_STATE(ENUM, INDEX, NAME) case CS_##ENUM: return NAME;
CS_STATES
#undef CS_STATE
Add support for connection tracking. This patch adds a new action and fields to OVS that allow connection tracking to be performed. This support works in conjunction with the Linux kernel support merged into the Linux-4.3 development cycle. Packets have two possible states with respect to connection tracking: Untracked packets have not previously passed through the connection tracker, while tracked packets have previously been through the connection tracker. For OpenFlow pipeline processing, untracked packets can become tracked, and they will remain tracked until the end of the pipeline. Tracked packets cannot become untracked. Connections can be unknown, uncommitted, or committed. Packets which are untracked have unknown connection state. To know the connection state, the packet must become tracked. Uncommitted connections have no connection state stored about them, so it is only possible for the connection tracker to identify whether they are a new connection or whether they are invalid. Committed connections have connection state stored beyond the lifetime of the packet, which allows later packets in the same connection to be identified as part of the same established connection, or related to an existing connection - for instance ICMP error responses. The new 'ct' action transitions the packet from "untracked" to "tracked" by sending this flow through the connection tracker. The following parameters are supported initally: - "commit": When commit is executed, the connection moves from uncommitted state to committed state. This signals that information about the connection should be stored beyond the lifetime of the packet within the pipeline. This allows future packets in the same connection to be recognized as part of the same "established" (est) connection, as well as identifying packets in the reply (rpl) direction, or packets related to an existing connection (rel). - "zone=[u16|NXM]": Perform connection tracking in the zone specified. Each zone is an independent connection tracking context. When the "commit" parameter is used, the connection will only be committed in the specified zone, and not in other zones. This is 0 by default. - "table=NUMBER": Fork pipeline processing in two. The original instance of the packet will continue processing the current actions list as an untracked packet. An additional instance of the packet will be sent to the connection tracker, which will be re-injected into the OpenFlow pipeline to resume processing in the specified table, with the ct_state and other ct match fields set. If the table is not specified, then the packet is submitted to the connection tracker, but the pipeline does not fork and the ct match fields are not populated. It is strongly recommended to specify a table later than the current table to prevent loops. When the "table" option is used, the packet that continues processing in the specified table will have the ct_state populated. The ct_state may have any of the following flags set: - Tracked (trk): Connection tracking has occurred. - Reply (rpl): The flow is in the reply direction. - Invalid (inv): The connection tracker couldn't identify the connection. - New (new): This is the beginning of a new connection. - Established (est): This is part of an already existing connection. - Related (rel): This connection is related to an existing connection. For more information, consult the ovs-ofctl(8) man pages. Below is a simple example flow table to allow outbound TCP traffic from port 1 and drop traffic from port 2 that was not initiated by port 1: table=0,priority=1,action=drop table=0,arp,action=normal table=0,in_port=1,tcp,ct_state=-trk,action=ct(commit,zone=9),2 table=0,in_port=2,tcp,ct_state=-trk,action=ct(zone=9,table=1) table=1,in_port=2,ct_state=+trk+est,tcp,action=1 table=1,in_port=2,ct_state=+trk+new,tcp,action=drop Based on original design by Justin Pettit, contributions from Thomas Graf and Daniele Di Proietto. Signed-off-by: Joe Stringer <joestringer@nicira.com> Acked-by: Jarno Rajahalme <jrajahalme@nicira.com> Acked-by: Ben Pfaff <blp@nicira.com>
2015-08-11 10:56:09 -07:00
default:
return NULL;
}
}
uint32_t
ct_state_from_string(const char *s)
{
#define CS_STATE(ENUM, INDEX, NAME) \
if (!strcmp(s, NAME)) { \
return CS_##ENUM; \
}
CS_STATES
#undef CS_STATE
return 0;
}
/* Parses conntrack state from 'state_str'. If it is parsed successfully,
* stores the parsed ct_state in 'ct_state', and returns true. Otherwise,
* returns false, and reports error message in 'ds'. */
bool
parse_ct_state(const char *state_str, uint32_t default_state,
uint32_t *ct_state, struct ds *ds)
{
uint32_t state = default_state;
char *state_s = xstrdup(state_str);
char *save_ptr = NULL;
for (char *cs = strtok_r(state_s, ", ", &save_ptr); cs;
cs = strtok_r(NULL, ", ", &save_ptr)) {
uint32_t bit = ct_state_from_string(cs);
if (!bit) {
ds_put_format(ds, "%s: unknown connection tracking state flag",
cs);
free(state_s);
return false;
}
state |= bit;
}
*ct_state = state;
free(state_s);
return true;
}
/* Checks the given conntrack state 'state' according to the constraints
* listed in ovs-fields (7). Returns true if it is valid. Otherwise, returns
* false, and reports error in 'ds'. */
bool
validate_ct_state(uint32_t state, struct ds *ds)
{
bool valid_ct_state = true;
struct ds d_str = DS_EMPTY_INITIALIZER;
format_flags(&d_str, ct_state_to_string, state, '|');
if (state && !(state & CS_TRACKED)) {
ds_put_format(ds, "%s: invalid connection state: "
"If \"trk\" is unset, no other flags are set\n",
ds_cstr(&d_str));
valid_ct_state = false;
}
if (state & CS_INVALID && state & ~(CS_TRACKED | CS_INVALID)) {
ds_put_format(ds, "%s: invalid connection state: "
"when \"inv\" is set, only \"trk\" may also be set\n",
ds_cstr(&d_str));
valid_ct_state = false;
}
if (state & CS_NEW && state & CS_ESTABLISHED) {
ds_put_format(ds, "%s: invalid connection state: "
"\"new\" and \"est\" are mutually exclusive\n",
ds_cstr(&d_str));
valid_ct_state = false;
}
if (state & CS_NEW && state & CS_REPLY_DIR) {
ds_put_format(ds, "%s: invalid connection state: "
"\"new\" and \"rpy\" are mutually exclusive\n",
ds_cstr(&d_str));
valid_ct_state = false;
}
ds_destroy(&d_str);
return valid_ct_state;
}
/* Clears the fields in 'flow' associated with connection tracking. */
void
flow_clear_conntrack(struct flow *flow)
{
flow->ct_state = 0;
flow->ct_zone = 0;
flow->ct_mark = 0;
flow->ct_label = OVS_U128_ZERO;
flow->ct_nw_proto = 0;
flow->ct_tp_src = 0;
flow->ct_tp_dst = 0;
if (flow->dl_type == htons(ETH_TYPE_IP)) {
flow->ct_nw_src = 0;
flow->ct_nw_dst = 0;
} else if (flow->dl_type == htons(ETH_TYPE_IPV6)) {
memset(&flow->ct_ipv6_src, 0, sizeof flow->ct_ipv6_src);
memset(&flow->ct_ipv6_dst, 0, sizeof flow->ct_ipv6_dst);
}
}
char *
flow_to_string(const struct flow *flow,
const struct ofputil_port_map *port_map)
{
struct ds ds = DS_EMPTY_INITIALIZER;
flow_format(&ds, flow, port_map);
return ds_cstr(&ds);
}
const char *
flow_tun_flag_to_string(uint32_t flags)
{
switch (flags) {
case FLOW_TNL_F_DONT_FRAGMENT:
return "df";
case FLOW_TNL_F_CSUM:
return "csum";
case FLOW_TNL_F_KEY:
return "key";
case FLOW_TNL_F_OAM:
return "oam";
default:
return NULL;
}
}
void
format_flags(struct ds *ds, const char *(*bit_to_string)(uint32_t),
uint32_t flags, char del)
{
uint32_t bad = 0;
if (!flags) {
ds_put_char(ds, '0');
return;
}
while (flags) {
uint32_t bit = rightmost_1bit(flags);
const char *s;
s = bit_to_string(bit);
if (s) {
ds_put_format(ds, "%s%c", s, del);
} else {
bad |= bit;
}
flags &= ~bit;
}
if (bad) {
ds_put_format(ds, "0x%"PRIx32"%c", bad, del);
}
ds_chomp(ds, del);
}
void
format_flags_masked(struct ds *ds, const char *name,
const char *(*bit_to_string)(uint32_t), uint32_t flags,
uint32_t mask, uint32_t max_mask)
{
if (name) {
ds_put_format(ds, "%s%s=%s", colors.param, name, colors.end);
}
if (mask == max_mask) {
format_flags(ds, bit_to_string, flags, '|');
return;
}
if (!mask) {
ds_put_cstr(ds, "0/0");
return;
}
while (mask) {
uint32_t bit = rightmost_1bit(mask);
const char *s = bit_to_string(bit);
ds_put_format(ds, "%s%s", (flags & bit) ? "+" : "-",
s ? s : "[Unknown]");
mask &= ~bit;
}
}
static void
put_u16_masked(struct ds *s, uint16_t value, uint16_t mask)
{
if (!mask) {
ds_put_char(s, '*');
} else {
if (value > 9) {
ds_put_format(s, "0x%"PRIx16, value);
} else {
ds_put_format(s, "%"PRIu16, value);
}
if (mask != UINT16_MAX) {
ds_put_format(s, "/0x%"PRIx16, mask);
}
}
}
void
format_packet_type_masked(struct ds *s, ovs_be32 value, ovs_be32 mask)
{
if (value == htonl(PT_ETH) && mask == OVS_BE32_MAX) {
ds_put_cstr(s, "eth");
} else {
ds_put_cstr(s, "packet_type=(");
put_u16_masked(s, pt_ns(value), pt_ns(mask));
ds_put_char(s, ',');
put_u16_masked(s, pt_ns_type(value), pt_ns_type(mask));
ds_put_char(s, ')');
}
}
/* Scans a string 's' of flags to determine their numerical value and
* returns the number of characters parsed using 'bit_to_string' to
* lookup flag names. Scanning continues until the character 'end' is
* reached.
*
* In the event of a failure, a negative error code will be returned. In
* addition, if 'res_string' is non-NULL then a descriptive string will
* be returned incorporating the identifying string 'field_name'. This
* error string must be freed by the caller.
*
* Upon success, the flag values will be stored in 'res_flags' and
* optionally 'res_mask', if it is non-NULL (if it is NULL then any masks
* present in the original string will be considered an error). The
* caller may restrict the acceptable set of values through the mask
* 'allowed'. */
int
parse_flags(const char *s, const char *(*bit_to_string)(uint32_t),
char end, const char *field_name, char **res_string,
uint32_t *res_flags, uint32_t allowed, uint32_t *res_mask)
{
uint32_t result = 0;
int n;
/* Parse masked flags in numeric format? */
if (res_mask && ovs_scan(s, "%"SCNi32"/%"SCNi32"%n",
res_flags, res_mask, &n) && n > 0) {
if (*res_flags & ~allowed || *res_mask & ~allowed) {
goto unknown;
}
return n;
}
n = 0;
if (res_mask && (*s == '+' || *s == '-')) {
uint32_t flags = 0, mask = 0;
/* Parse masked flags. */
while (s[0] != end) {
bool set;
uint32_t bit;
size_t len;
if (s[0] == '+') {
set = true;
} else if (s[0] == '-') {
set = false;
} else {
if (res_string) {
*res_string = xasprintf("%s: %s must be preceded by '+' "
"(for SET) or '-' (NOT SET)", s,
field_name);
}
return -EINVAL;
}
s++;
n++;
for (bit = 1; bit; bit <<= 1) {
const char *fname = bit_to_string(bit);
if (!fname) {
continue;
}
len = strlen(fname);
if (strncmp(s, fname, len) ||
(s[len] != '+' && s[len] != '-' && s[len] != end)) {
continue;
}
if (mask & bit) {
/* bit already set. */
if (res_string) {
*res_string = xasprintf("%s: Each %s flag can be "
"specified only once", s,
field_name);
}
return -EINVAL;
}
if (!(bit & allowed)) {
goto unknown;
}
if (set) {
flags |= bit;
}
mask |= bit;
break;
}
if (!bit) {
goto unknown;
}
s += len;
n += len;
}
*res_flags = flags;
*res_mask = mask;
return n;
}
/* Parse unmasked flags. If a flag is present, it is set, otherwise
* it is not set. */
while (s[n] != end) {
unsigned long long int flags;
uint32_t bit;
int n0;
if (ovs_scan(&s[n], "%lli%n", &flags, &n0)) {
if (flags & ~allowed) {
goto unknown;
}
n += n0 + (s[n + n0] == '|');
result |= flags;
continue;
}
for (bit = 1; bit; bit <<= 1) {
const char *name = bit_to_string(bit);
size_t len;
if (!name) {
continue;
}
len = strlen(name);
if (!strncmp(s + n, name, len) &&
(s[n + len] == '|' || s[n + len] == end)) {
if (!(bit & allowed)) {
goto unknown;
}
result |= bit;
n += len + (s[n + len] == '|');
break;
}
}
if (!bit) {
goto unknown;
}
}
*res_flags = result;
if (res_mask) {
*res_mask = UINT32_MAX;
}
if (res_string) {
*res_string = NULL;
}
return n;
unknown:
if (res_string) {
*res_string = xasprintf("%s: unknown %s flag(s)", s, field_name);
}
return -EINVAL;
}
void
flow_format(struct ds *ds,
const struct flow *flow, const struct ofputil_port_map *port_map)
{
struct match match;
struct flow_wildcards *wc = &match.wc;
match_wc_init(&match, flow);
/* As this function is most often used for formatting a packet in a
* packet-in message, skip formatting the packet context fields that are
* all-zeroes to make the print-out easier on the eyes. This means that a
* missing context field implies a zero value for that field. This is
* similar to OpenFlow encoding of these fields, as the specification
* states that all-zeroes context fields should not be encoded in the
* packet-in messages. */
if (!flow->in_port.ofp_port) {
WC_UNMASK_FIELD(wc, in_port);
}
if (!flow->skb_priority) {
WC_UNMASK_FIELD(wc, skb_priority);
}
if (!flow->pkt_mark) {
WC_UNMASK_FIELD(wc, pkt_mark);
}
if (!flow->recirc_id) {
WC_UNMASK_FIELD(wc, recirc_id);
}
if (!flow->dp_hash) {
WC_UNMASK_FIELD(wc, dp_hash);
}
Add support for connection tracking. This patch adds a new action and fields to OVS that allow connection tracking to be performed. This support works in conjunction with the Linux kernel support merged into the Linux-4.3 development cycle. Packets have two possible states with respect to connection tracking: Untracked packets have not previously passed through the connection tracker, while tracked packets have previously been through the connection tracker. For OpenFlow pipeline processing, untracked packets can become tracked, and they will remain tracked until the end of the pipeline. Tracked packets cannot become untracked. Connections can be unknown, uncommitted, or committed. Packets which are untracked have unknown connection state. To know the connection state, the packet must become tracked. Uncommitted connections have no connection state stored about them, so it is only possible for the connection tracker to identify whether they are a new connection or whether they are invalid. Committed connections have connection state stored beyond the lifetime of the packet, which allows later packets in the same connection to be identified as part of the same established connection, or related to an existing connection - for instance ICMP error responses. The new 'ct' action transitions the packet from "untracked" to "tracked" by sending this flow through the connection tracker. The following parameters are supported initally: - "commit": When commit is executed, the connection moves from uncommitted state to committed state. This signals that information about the connection should be stored beyond the lifetime of the packet within the pipeline. This allows future packets in the same connection to be recognized as part of the same "established" (est) connection, as well as identifying packets in the reply (rpl) direction, or packets related to an existing connection (rel). - "zone=[u16|NXM]": Perform connection tracking in the zone specified. Each zone is an independent connection tracking context. When the "commit" parameter is used, the connection will only be committed in the specified zone, and not in other zones. This is 0 by default. - "table=NUMBER": Fork pipeline processing in two. The original instance of the packet will continue processing the current actions list as an untracked packet. An additional instance of the packet will be sent to the connection tracker, which will be re-injected into the OpenFlow pipeline to resume processing in the specified table, with the ct_state and other ct match fields set. If the table is not specified, then the packet is submitted to the connection tracker, but the pipeline does not fork and the ct match fields are not populated. It is strongly recommended to specify a table later than the current table to prevent loops. When the "table" option is used, the packet that continues processing in the specified table will have the ct_state populated. The ct_state may have any of the following flags set: - Tracked (trk): Connection tracking has occurred. - Reply (rpl): The flow is in the reply direction. - Invalid (inv): The connection tracker couldn't identify the connection. - New (new): This is the beginning of a new connection. - Established (est): This is part of an already existing connection. - Related (rel): This connection is related to an existing connection. For more information, consult the ovs-ofctl(8) man pages. Below is a simple example flow table to allow outbound TCP traffic from port 1 and drop traffic from port 2 that was not initiated by port 1: table=0,priority=1,action=drop table=0,arp,action=normal table=0,in_port=1,tcp,ct_state=-trk,action=ct(commit,zone=9),2 table=0,in_port=2,tcp,ct_state=-trk,action=ct(zone=9,table=1) table=1,in_port=2,ct_state=+trk+est,tcp,action=1 table=1,in_port=2,ct_state=+trk+new,tcp,action=drop Based on original design by Justin Pettit, contributions from Thomas Graf and Daniele Di Proietto. Signed-off-by: Joe Stringer <joestringer@nicira.com> Acked-by: Jarno Rajahalme <jrajahalme@nicira.com> Acked-by: Ben Pfaff <blp@nicira.com>
2015-08-11 10:56:09 -07:00
if (!flow->ct_state) {
WC_UNMASK_FIELD(wc, ct_state);
}
if (!flow->ct_zone) {
WC_UNMASK_FIELD(wc, ct_zone);
}
if (!flow->ct_mark) {
WC_UNMASK_FIELD(wc, ct_mark);
}
if (ovs_u128_is_zero(flow->ct_label)) {
WC_UNMASK_FIELD(wc, ct_label);
}
if (!is_ct_valid(flow, &match.wc, NULL) || !flow->ct_nw_proto) {
WC_UNMASK_FIELD(wc, ct_nw_proto);
WC_UNMASK_FIELD(wc, ct_tp_src);
WC_UNMASK_FIELD(wc, ct_tp_dst);
if (flow->dl_type == htons(ETH_TYPE_IP)) {
WC_UNMASK_FIELD(wc, ct_nw_src);
WC_UNMASK_FIELD(wc, ct_nw_dst);
} else if (flow->dl_type == htons(ETH_TYPE_IPV6)) {
WC_UNMASK_FIELD(wc, ct_ipv6_src);
WC_UNMASK_FIELD(wc, ct_ipv6_dst);
}
}
for (int i = 0; i < FLOW_N_REGS; i++) {
if (!flow->regs[i]) {
WC_UNMASK_FIELD(wc, regs[i]);
}
}
if (!flow->metadata) {
WC_UNMASK_FIELD(wc, metadata);
}
match_format(&match, port_map, ds, OFP_DEFAULT_PRIORITY);
}
void
flow_print(FILE *stream,
const struct flow *flow, const struct ofputil_port_map *port_map)
{
char *s = flow_to_string(flow, port_map);
fputs(s, stream);
free(s);
}
/* flow_wildcards functions. */
/* Initializes 'wc' as a set of wildcards that matches every packet. */
void
flow_wildcards_init_catchall(struct flow_wildcards *wc)
{
memset(&wc->masks, 0, sizeof wc->masks);
}
/* Converts a flow into flow wildcards. It sets the wildcard masks based on
* the packet headers extracted to 'flow'. It will not set the mask for fields
* that do not make sense for the packet type. OpenFlow-only metadata is
* wildcarded, but other metadata is unconditionally exact-matched. */
void
flow_wildcards_init_for_packet(struct flow_wildcards *wc,
const struct flow *flow)
{
ovs_be16 dl_type = OVS_BE16_MAX;
memset(&wc->masks, 0x0, sizeof wc->masks);
/* Update this function whenever struct flow changes. */
BUILD_ASSERT_DECL(FLOW_WC_SEQ == 42);
if (flow_tnl_dst_is_set(&flow->tunnel)) {
if (flow->tunnel.flags & FLOW_TNL_F_KEY) {
WC_MASK_FIELD(wc, tunnel.tun_id);
}
WC_MASK_FIELD(wc, tunnel.ip_src);
WC_MASK_FIELD(wc, tunnel.ip_dst);
WC_MASK_FIELD(wc, tunnel.ipv6_src);
WC_MASK_FIELD(wc, tunnel.ipv6_dst);
WC_MASK_FIELD(wc, tunnel.flags);
WC_MASK_FIELD(wc, tunnel.ip_tos);
WC_MASK_FIELD(wc, tunnel.ip_ttl);
WC_MASK_FIELD(wc, tunnel.tp_src);
WC_MASK_FIELD(wc, tunnel.tp_dst);
WC_MASK_FIELD(wc, tunnel.gbp_id);
WC_MASK_FIELD(wc, tunnel.gbp_flags);
WC_MASK_FIELD(wc, tunnel.erspan_ver);
WC_MASK_FIELD(wc, tunnel.erspan_idx);
WC_MASK_FIELD(wc, tunnel.erspan_dir);
WC_MASK_FIELD(wc, tunnel.erspan_hwid);
WC_MASK_FIELD(wc, tunnel.gtpu_flags);
WC_MASK_FIELD(wc, tunnel.gtpu_msgtype);
tunnel: Geneve TLV handling support for OpenFlow. The current support for Geneve in OVS is exactly equivalent to VXLAN: it is possible to set and match on the VNI but not on any options contained in the header. This patch enables the use of options. The goal for Geneve support is not to add support for any particular option but to allow end users or controllers to specify what they would like to match. That is, the full range of Geneve's capabilities should be exposed without modifying the code (the one exception being options that require per-packet computation in the fast path). The main issue with supporting Geneve options is how to integrate the fields into the existing OpenFlow pipeline. All existing operations are referred to by their NXM/OXM field name - matches, action generation, arithmetic operations (i.e. tranfer to a register). However, the Geneve option space is exactly the same as the OXM space, so a direct mapping is not feasible. Instead, we create a pool of 64 NXMs that are then dynamically mapped on Geneve option TLVs using OpenFlow. Once mapped, these fields become first-class citizens in the OpenFlow pipeline. An example of how to use Geneve options: ovs-ofctl add-geneve-map br0 {class=0xffff,type=0,len=4}->tun_metadata0 ovs-ofctl add-flow br0 in_port=LOCAL,actions=set_field:0xffffffff->tun_metadata0,1 This will add a 4 bytes option (filled will all 1's) to all packets coming from the LOCAL port and then send then out to port 1. A limitation of this patch is that although the option table is specified for a particular switch over OpenFlow, it is currently global to all switches. This will be addressed in a future patch. Based on work originally done by Madhu Challa. Ben Pfaff also significantly improved the comments. Signed-off-by: Madhu Challa <challa@noironetworks.com> Signed-off-by: Jesse Gross <jesse@nicira.com> Acked-by: Ben Pfaff <blp@nicira.com>
2015-04-30 18:09:57 -07:00
dpif-netdev: Translate Geneve options per-flow, not per-packet. The kernel implementation of Geneve options stores the TLV option data in the flow exactly as received, without any further parsing. This is then translated to known options for the purposes of matching on flow setup (which will then install a datapath flow in the form the kernel is expecting). The userspace implementation behaves a little bit differently - it looks up known options as each packet is received. The reason for this is there is a much tighter coupling between datapath and flow translation and the representation is generally expected to be the same. This works but it incurs work on a per-packet basis that could be done per-flow instead. This introduces a small translation step for Geneve packets between datapath and flow lookup for the userspace datapath in order to allow the same kind of processing that the kernel does. A side effect of this is that unknown options are now shown when flows dumped via ovs-appctl dpif/dump-flows, similar to the kernel. There is a second benefit to this as well: for some operations it is preferable to keep the options exactly as they were received on the wire, which this enables. One example is that for packets that are executed from ofproto-dpif-upcall to the datapath, this avoids the translation of Geneve metadata. Since this conversion is potentially lossy (for unknown options), keeping everything in the same format removes the possibility of dropping options if the packet comes back up to userspace and the Geneve option translation table has changed. To help with these types of operations, most functions can understand both formats of data and seamlessly do the right thing. Signed-off-by: Jesse Gross <jesse@nicira.com> Acked-by: Jarno Rajahalme <jrajahalme@nicira.com>
2015-06-29 18:01:59 -07:00
if (!(flow->tunnel.flags & FLOW_TNL_F_UDPIF)) {
if (flow->tunnel.metadata.present.map) {
wc->masks.tunnel.metadata.present.map =
flow->tunnel.metadata.present.map;
WC_MASK_FIELD(wc, tunnel.metadata.opts.u8);
tun-metadata: Manage tunnel TLV mapping table on a per-bridge basis. When using tunnel TLVs (at the moment, this means Geneve options), a controller must first map the class and type onto an appropriate OXM field so that it can be used in OVS flow operations. This table is managed using OpenFlow extensions. The original code that added support for TLVs made the mapping table global as a simplification. However, this is not really logically correct as the OpenFlow management commands are operating on a per-bridge basis. This removes the original limitation to make the table per-bridge. One nice result of this change is that it is generally clearer whether the tunnel metadata is in datapath or OpenFlow format. Rather than allowing ad-hoc format changes and trying to handle both formats in the tunnel metadata functions, the format is more clearly separated by function. Datapaths (both kernel and userspace) use datapath format and it is not changed during the upcall process. At the beginning of action translation, tunnel metadata is converted to OpenFlow format and flows and wildcards are translated back at the end of the process. As an additional benefit, this change improves performance in some flow setup situations by keeping the tunnel metadata in the original packet format in more cases. This helps when copies need to be made as the amount of data touched is only what is present in the packet rather than the maximum amount of metadata supported. Co-authored-by: Madhu Challa <challa@noironetworks.com> Signed-off-by: Madhu Challa <challa@noironetworks.com> Signed-off-by: Jesse Gross <jesse@kernel.org> Acked-by: Ben Pfaff <blp@ovn.org>
2016-04-19 18:36:04 -07:00
WC_MASK_FIELD(wc, tunnel.metadata.tab);
dpif-netdev: Translate Geneve options per-flow, not per-packet. The kernel implementation of Geneve options stores the TLV option data in the flow exactly as received, without any further parsing. This is then translated to known options for the purposes of matching on flow setup (which will then install a datapath flow in the form the kernel is expecting). The userspace implementation behaves a little bit differently - it looks up known options as each packet is received. The reason for this is there is a much tighter coupling between datapath and flow translation and the representation is generally expected to be the same. This works but it incurs work on a per-packet basis that could be done per-flow instead. This introduces a small translation step for Geneve packets between datapath and flow lookup for the userspace datapath in order to allow the same kind of processing that the kernel does. A side effect of this is that unknown options are now shown when flows dumped via ovs-appctl dpif/dump-flows, similar to the kernel. There is a second benefit to this as well: for some operations it is preferable to keep the options exactly as they were received on the wire, which this enables. One example is that for packets that are executed from ofproto-dpif-upcall to the datapath, this avoids the translation of Geneve metadata. Since this conversion is potentially lossy (for unknown options), keeping everything in the same format removes the possibility of dropping options if the packet comes back up to userspace and the Geneve option translation table has changed. To help with these types of operations, most functions can understand both formats of data and seamlessly do the right thing. Signed-off-by: Jesse Gross <jesse@nicira.com> Acked-by: Jarno Rajahalme <jrajahalme@nicira.com>
2015-06-29 18:01:59 -07:00
}
} else {
WC_MASK_FIELD(wc, tunnel.metadata.present.len);
memset(wc->masks.tunnel.metadata.opts.gnv, 0xff,
flow->tunnel.metadata.present.len);
tunnel: Geneve TLV handling support for OpenFlow. The current support for Geneve in OVS is exactly equivalent to VXLAN: it is possible to set and match on the VNI but not on any options contained in the header. This patch enables the use of options. The goal for Geneve support is not to add support for any particular option but to allow end users or controllers to specify what they would like to match. That is, the full range of Geneve's capabilities should be exposed without modifying the code (the one exception being options that require per-packet computation in the fast path). The main issue with supporting Geneve options is how to integrate the fields into the existing OpenFlow pipeline. All existing operations are referred to by their NXM/OXM field name - matches, action generation, arithmetic operations (i.e. tranfer to a register). However, the Geneve option space is exactly the same as the OXM space, so a direct mapping is not feasible. Instead, we create a pool of 64 NXMs that are then dynamically mapped on Geneve option TLVs using OpenFlow. Once mapped, these fields become first-class citizens in the OpenFlow pipeline. An example of how to use Geneve options: ovs-ofctl add-geneve-map br0 {class=0xffff,type=0,len=4}->tun_metadata0 ovs-ofctl add-flow br0 in_port=LOCAL,actions=set_field:0xffffffff->tun_metadata0,1 This will add a 4 bytes option (filled will all 1's) to all packets coming from the LOCAL port and then send then out to port 1. A limitation of this patch is that although the option table is specified for a particular switch over OpenFlow, it is currently global to all switches. This will be addressed in a future patch. Based on work originally done by Madhu Challa. Ben Pfaff also significantly improved the comments. Signed-off-by: Madhu Challa <challa@noironetworks.com> Signed-off-by: Jesse Gross <jesse@nicira.com> Acked-by: Ben Pfaff <blp@nicira.com>
2015-04-30 18:09:57 -07:00
}
} else if (flow->tunnel.tun_id) {
WC_MASK_FIELD(wc, tunnel.tun_id);
}
/* metadata, regs, and conj_id wildcarded. */
WC_MASK_FIELD(wc, skb_priority);
WC_MASK_FIELD(wc, pkt_mark);
Add support for connection tracking. This patch adds a new action and fields to OVS that allow connection tracking to be performed. This support works in conjunction with the Linux kernel support merged into the Linux-4.3 development cycle. Packets have two possible states with respect to connection tracking: Untracked packets have not previously passed through the connection tracker, while tracked packets have previously been through the connection tracker. For OpenFlow pipeline processing, untracked packets can become tracked, and they will remain tracked until the end of the pipeline. Tracked packets cannot become untracked. Connections can be unknown, uncommitted, or committed. Packets which are untracked have unknown connection state. To know the connection state, the packet must become tracked. Uncommitted connections have no connection state stored about them, so it is only possible for the connection tracker to identify whether they are a new connection or whether they are invalid. Committed connections have connection state stored beyond the lifetime of the packet, which allows later packets in the same connection to be identified as part of the same established connection, or related to an existing connection - for instance ICMP error responses. The new 'ct' action transitions the packet from "untracked" to "tracked" by sending this flow through the connection tracker. The following parameters are supported initally: - "commit": When commit is executed, the connection moves from uncommitted state to committed state. This signals that information about the connection should be stored beyond the lifetime of the packet within the pipeline. This allows future packets in the same connection to be recognized as part of the same "established" (est) connection, as well as identifying packets in the reply (rpl) direction, or packets related to an existing connection (rel). - "zone=[u16|NXM]": Perform connection tracking in the zone specified. Each zone is an independent connection tracking context. When the "commit" parameter is used, the connection will only be committed in the specified zone, and not in other zones. This is 0 by default. - "table=NUMBER": Fork pipeline processing in two. The original instance of the packet will continue processing the current actions list as an untracked packet. An additional instance of the packet will be sent to the connection tracker, which will be re-injected into the OpenFlow pipeline to resume processing in the specified table, with the ct_state and other ct match fields set. If the table is not specified, then the packet is submitted to the connection tracker, but the pipeline does not fork and the ct match fields are not populated. It is strongly recommended to specify a table later than the current table to prevent loops. When the "table" option is used, the packet that continues processing in the specified table will have the ct_state populated. The ct_state may have any of the following flags set: - Tracked (trk): Connection tracking has occurred. - Reply (rpl): The flow is in the reply direction. - Invalid (inv): The connection tracker couldn't identify the connection. - New (new): This is the beginning of a new connection. - Established (est): This is part of an already existing connection. - Related (rel): This connection is related to an existing connection. For more information, consult the ovs-ofctl(8) man pages. Below is a simple example flow table to allow outbound TCP traffic from port 1 and drop traffic from port 2 that was not initiated by port 1: table=0,priority=1,action=drop table=0,arp,action=normal table=0,in_port=1,tcp,ct_state=-trk,action=ct(commit,zone=9),2 table=0,in_port=2,tcp,ct_state=-trk,action=ct(zone=9,table=1) table=1,in_port=2,ct_state=+trk+est,tcp,action=1 table=1,in_port=2,ct_state=+trk+new,tcp,action=drop Based on original design by Justin Pettit, contributions from Thomas Graf and Daniele Di Proietto. Signed-off-by: Joe Stringer <joestringer@nicira.com> Acked-by: Jarno Rajahalme <jrajahalme@nicira.com> Acked-by: Ben Pfaff <blp@nicira.com>
2015-08-11 10:56:09 -07:00
WC_MASK_FIELD(wc, ct_state);
WC_MASK_FIELD(wc, ct_zone);
WC_MASK_FIELD(wc, ct_mark);
WC_MASK_FIELD(wc, ct_label);
WC_MASK_FIELD(wc, recirc_id);
WC_MASK_FIELD(wc, dp_hash);
WC_MASK_FIELD(wc, in_port);
/* actset_output wildcarded. */
WC_MASK_FIELD(wc, packet_type);
if (flow->packet_type == htonl(PT_ETH)) {
WC_MASK_FIELD(wc, dl_dst);
WC_MASK_FIELD(wc, dl_src);
WC_MASK_FIELD(wc, dl_type);
/* No need to set mask of inner VLANs that don't exist. */
for (int i = 0; i < FLOW_MAX_VLAN_HEADERS; i++) {
/* Always show the first zero VLAN. */
WC_MASK_FIELD(wc, vlans[i]);
if (flow->vlans[i].tci == htons(0)) {
break;
}
}
dl_type = flow->dl_type;
} else {
dl_type = pt_ns_type_be(flow->packet_type);
}
if (dl_type == htons(ETH_TYPE_IP)) {
WC_MASK_FIELD(wc, nw_src);
WC_MASK_FIELD(wc, nw_dst);
WC_MASK_FIELD(wc, ct_nw_src);
WC_MASK_FIELD(wc, ct_nw_dst);
} else if (dl_type == htons(ETH_TYPE_IPV6)) {
WC_MASK_FIELD(wc, ipv6_src);
WC_MASK_FIELD(wc, ipv6_dst);
WC_MASK_FIELD(wc, ipv6_label);
if (is_nd(flow, wc)) {
WC_MASK_FIELD(wc, arp_sha);
WC_MASK_FIELD(wc, arp_tha);
WC_MASK_FIELD(wc, nd_target);
} else {
WC_MASK_FIELD(wc, ct_ipv6_src);
WC_MASK_FIELD(wc, ct_ipv6_dst);
}
} else if (dl_type == htons(ETH_TYPE_ARP) ||
dl_type == htons(ETH_TYPE_RARP)) {
WC_MASK_FIELD(wc, nw_src);
WC_MASK_FIELD(wc, nw_dst);
WC_MASK_FIELD(wc, nw_proto);
WC_MASK_FIELD(wc, arp_sha);
WC_MASK_FIELD(wc, arp_tha);
return;
} else if (eth_type_mpls(dl_type)) {
for (int i = 0; i < FLOW_MAX_MPLS_LABELS; i++) {
WC_MASK_FIELD(wc, mpls_lse[i]);
if (flow->mpls_lse[i] & htonl(MPLS_BOS_MASK)) {
break;
}
}
return;
} else if (flow->dl_type == htons(ETH_TYPE_NSH)) {
WC_MASK_FIELD(wc, nsh.flags);
WC_MASK_FIELD(wc, nsh.ttl);
WC_MASK_FIELD(wc, nsh.mdtype);
WC_MASK_FIELD(wc, nsh.np);
WC_MASK_FIELD(wc, nsh.path_hdr);
WC_MASK_FIELD(wc, nsh.context);
} else {
return; /* Unknown ethertype. */
}
/* IPv4 or IPv6. */
WC_MASK_FIELD_MASK(wc, nw_frag, FLOW_NW_FRAG_MASK);
WC_MASK_FIELD(wc, nw_tos);
WC_MASK_FIELD(wc, nw_ttl);
WC_MASK_FIELD(wc, nw_proto);
WC_MASK_FIELD(wc, ct_nw_proto);
WC_MASK_FIELD(wc, ct_tp_src);
WC_MASK_FIELD(wc, ct_tp_dst);
/* No transport layer header in later fragments. */
if (!(flow->nw_frag & FLOW_NW_FRAG_LATER) &&
(flow->nw_proto == IPPROTO_ICMP ||
flow->nw_proto == IPPROTO_ICMPV6 ||
flow->nw_proto == IPPROTO_TCP ||
flow->nw_proto == IPPROTO_UDP ||
flow->nw_proto == IPPROTO_SCTP ||
flow->nw_proto == IPPROTO_IGMP)) {
WC_MASK_FIELD(wc, tp_src);
WC_MASK_FIELD(wc, tp_dst);
if (flow->nw_proto == IPPROTO_TCP) {
WC_MASK_FIELD(wc, tcp_flags);
} else if (flow->nw_proto == IPPROTO_IGMP) {
WC_MASK_FIELD(wc, igmp_group_ip4);
}
}
}
/* Return a map of possible fields for a packet of the same type as 'flow'.
* Including extra bits in the returned mask is not wrong, it is just less
* optimal.
*
* This is a less precise version of flow_wildcards_init_for_packet() above. */
void
flow_wc_map(const struct flow *flow, struct flowmap *map)
{
/* Update this function whenever struct flow changes. */
BUILD_ASSERT_DECL(FLOW_WC_SEQ == 42);
flowmap_init(map);
if (flow_tnl_dst_is_set(&flow->tunnel)) {
FLOWMAP_SET__(map, tunnel, offsetof(struct flow_tnl, metadata));
dpif-netdev: Translate Geneve options per-flow, not per-packet. The kernel implementation of Geneve options stores the TLV option data in the flow exactly as received, without any further parsing. This is then translated to known options for the purposes of matching on flow setup (which will then install a datapath flow in the form the kernel is expecting). The userspace implementation behaves a little bit differently - it looks up known options as each packet is received. The reason for this is there is a much tighter coupling between datapath and flow translation and the representation is generally expected to be the same. This works but it incurs work on a per-packet basis that could be done per-flow instead. This introduces a small translation step for Geneve packets between datapath and flow lookup for the userspace datapath in order to allow the same kind of processing that the kernel does. A side effect of this is that unknown options are now shown when flows dumped via ovs-appctl dpif/dump-flows, similar to the kernel. There is a second benefit to this as well: for some operations it is preferable to keep the options exactly as they were received on the wire, which this enables. One example is that for packets that are executed from ofproto-dpif-upcall to the datapath, this avoids the translation of Geneve metadata. Since this conversion is potentially lossy (for unknown options), keeping everything in the same format removes the possibility of dropping options if the packet comes back up to userspace and the Geneve option translation table has changed. To help with these types of operations, most functions can understand both formats of data and seamlessly do the right thing. Signed-off-by: Jesse Gross <jesse@nicira.com> Acked-by: Jarno Rajahalme <jrajahalme@nicira.com>
2015-06-29 18:01:59 -07:00
if (!(flow->tunnel.flags & FLOW_TNL_F_UDPIF)) {
if (flow->tunnel.metadata.present.map) {
FLOWMAP_SET(map, tunnel.metadata);
dpif-netdev: Translate Geneve options per-flow, not per-packet. The kernel implementation of Geneve options stores the TLV option data in the flow exactly as received, without any further parsing. This is then translated to known options for the purposes of matching on flow setup (which will then install a datapath flow in the form the kernel is expecting). The userspace implementation behaves a little bit differently - it looks up known options as each packet is received. The reason for this is there is a much tighter coupling between datapath and flow translation and the representation is generally expected to be the same. This works but it incurs work on a per-packet basis that could be done per-flow instead. This introduces a small translation step for Geneve packets between datapath and flow lookup for the userspace datapath in order to allow the same kind of processing that the kernel does. A side effect of this is that unknown options are now shown when flows dumped via ovs-appctl dpif/dump-flows, similar to the kernel. There is a second benefit to this as well: for some operations it is preferable to keep the options exactly as they were received on the wire, which this enables. One example is that for packets that are executed from ofproto-dpif-upcall to the datapath, this avoids the translation of Geneve metadata. Since this conversion is potentially lossy (for unknown options), keeping everything in the same format removes the possibility of dropping options if the packet comes back up to userspace and the Geneve option translation table has changed. To help with these types of operations, most functions can understand both formats of data and seamlessly do the right thing. Signed-off-by: Jesse Gross <jesse@nicira.com> Acked-by: Jarno Rajahalme <jrajahalme@nicira.com>
2015-06-29 18:01:59 -07:00
}
} else {
FLOWMAP_SET(map, tunnel.metadata.present.len);
FLOWMAP_SET__(map, tunnel.metadata.opts.gnv,
flow->tunnel.metadata.present.len);
}
}
/* Metadata fields that can appear on packet input. */
FLOWMAP_SET(map, skb_priority);
FLOWMAP_SET(map, pkt_mark);
FLOWMAP_SET(map, recirc_id);
FLOWMAP_SET(map, dp_hash);
FLOWMAP_SET(map, in_port);
FLOWMAP_SET(map, dl_dst);
FLOWMAP_SET(map, dl_src);
FLOWMAP_SET(map, dl_type);
FLOWMAP_SET(map, vlans);
Add support for connection tracking. This patch adds a new action and fields to OVS that allow connection tracking to be performed. This support works in conjunction with the Linux kernel support merged into the Linux-4.3 development cycle. Packets have two possible states with respect to connection tracking: Untracked packets have not previously passed through the connection tracker, while tracked packets have previously been through the connection tracker. For OpenFlow pipeline processing, untracked packets can become tracked, and they will remain tracked until the end of the pipeline. Tracked packets cannot become untracked. Connections can be unknown, uncommitted, or committed. Packets which are untracked have unknown connection state. To know the connection state, the packet must become tracked. Uncommitted connections have no connection state stored about them, so it is only possible for the connection tracker to identify whether they are a new connection or whether they are invalid. Committed connections have connection state stored beyond the lifetime of the packet, which allows later packets in the same connection to be identified as part of the same established connection, or related to an existing connection - for instance ICMP error responses. The new 'ct' action transitions the packet from "untracked" to "tracked" by sending this flow through the connection tracker. The following parameters are supported initally: - "commit": When commit is executed, the connection moves from uncommitted state to committed state. This signals that information about the connection should be stored beyond the lifetime of the packet within the pipeline. This allows future packets in the same connection to be recognized as part of the same "established" (est) connection, as well as identifying packets in the reply (rpl) direction, or packets related to an existing connection (rel). - "zone=[u16|NXM]": Perform connection tracking in the zone specified. Each zone is an independent connection tracking context. When the "commit" parameter is used, the connection will only be committed in the specified zone, and not in other zones. This is 0 by default. - "table=NUMBER": Fork pipeline processing in two. The original instance of the packet will continue processing the current actions list as an untracked packet. An additional instance of the packet will be sent to the connection tracker, which will be re-injected into the OpenFlow pipeline to resume processing in the specified table, with the ct_state and other ct match fields set. If the table is not specified, then the packet is submitted to the connection tracker, but the pipeline does not fork and the ct match fields are not populated. It is strongly recommended to specify a table later than the current table to prevent loops. When the "table" option is used, the packet that continues processing in the specified table will have the ct_state populated. The ct_state may have any of the following flags set: - Tracked (trk): Connection tracking has occurred. - Reply (rpl): The flow is in the reply direction. - Invalid (inv): The connection tracker couldn't identify the connection. - New (new): This is the beginning of a new connection. - Established (est): This is part of an already existing connection. - Related (rel): This connection is related to an existing connection. For more information, consult the ovs-ofctl(8) man pages. Below is a simple example flow table to allow outbound TCP traffic from port 1 and drop traffic from port 2 that was not initiated by port 1: table=0,priority=1,action=drop table=0,arp,action=normal table=0,in_port=1,tcp,ct_state=-trk,action=ct(commit,zone=9),2 table=0,in_port=2,tcp,ct_state=-trk,action=ct(zone=9,table=1) table=1,in_port=2,ct_state=+trk+est,tcp,action=1 table=1,in_port=2,ct_state=+trk+new,tcp,action=drop Based on original design by Justin Pettit, contributions from Thomas Graf and Daniele Di Proietto. Signed-off-by: Joe Stringer <joestringer@nicira.com> Acked-by: Jarno Rajahalme <jrajahalme@nicira.com> Acked-by: Ben Pfaff <blp@nicira.com>
2015-08-11 10:56:09 -07:00
FLOWMAP_SET(map, ct_state);
FLOWMAP_SET(map, ct_zone);
FLOWMAP_SET(map, ct_mark);
FLOWMAP_SET(map, ct_label);
userspace: Add packet_type in dp_packet and flow This commit adds a packet_type attribute to the structs dp_packet and flow to explicitly carry the type of the packet as prepration for the introduction of the so-called packet type-aware pipeline (PTAP) in OVS. The packet_type is a big-endian 32 bit integer with the encoding as specified in OpenFlow verion 1.5. The upper 16 bits contain the packet type name space. Pre-defined values are defined in openflow-common.h: enum ofp_header_type_namespaces { OFPHTN_ONF = 0, /* ONF namespace. */ OFPHTN_ETHERTYPE = 1, /* ns_type is an Ethertype. */ OFPHTN_IP_PROTO = 2, /* ns_type is a IP protocol number. */ OFPHTN_UDP_TCP_PORT = 3, /* ns_type is a TCP or UDP port. */ OFPHTN_IPV4_OPTION = 4, /* ns_type is an IPv4 option number. */ }; The lower 16 bits specify the actual type in the context of the name space. Only name spaces 0 and 1 will be supported for now. For name space OFPHTN_ONF the relevant packet type is 0 (Ethernet). This is the default packet_type in OVS and the only one supported so far. Packets of type (OFPHTN_ONF, 0) are called Ethernet packets. In name space OFPHTN_ETHERTYPE the type is the Ethertype of the packet. A packet of type (OFPHTN_ETHERTYPE, <Ethertype>) is a standard L2 packet whith the Ethernet header (and any VLAN tags) removed to expose the L3 (or L2.5) payload of the packet. These will simply be called L3 packets. The Ethernet address fields dl_src and dl_dst in struct flow are not applicable for an L3 packet and must be zero. However, to maintain compatibility with the large code base, we have chosen to copy the Ethertype of an L3 packet into the the dl_type field of struct flow. This does not mean that it will be possible to match on dl_type for L3 packets with PTAP later on. Matching must be done on packet_type instead. New dp_packets are initialized with packet_type Ethernet. Ports that receive L3 packets will have to explicitly adjust the packet_type. Signed-off-by: Jean Tourrilhes <jt@labs.hpe.com> Signed-off-by: Jan Scheurich <jan.scheurich@ericsson.com> Co-authored-by: Zoltan Balogh <zoltan.balogh@ericsson.com> Signed-off-by: Ben Pfaff <blp@ovn.org>
2017-04-25 16:29:59 +00:00
FLOWMAP_SET(map, packet_type);
/* Ethertype-dependent fields. */
if (OVS_LIKELY(flow->dl_type == htons(ETH_TYPE_IP))) {
FLOWMAP_SET(map, nw_src);
FLOWMAP_SET(map, nw_dst);
FLOWMAP_SET(map, nw_proto);
FLOWMAP_SET(map, nw_frag);
FLOWMAP_SET(map, nw_tos);
FLOWMAP_SET(map, nw_ttl);
FLOWMAP_SET(map, tp_src);
FLOWMAP_SET(map, tp_dst);
FLOWMAP_SET(map, ct_nw_proto);
FLOWMAP_SET(map, ct_nw_src);
FLOWMAP_SET(map, ct_nw_dst);
FLOWMAP_SET(map, ct_tp_src);
FLOWMAP_SET(map, ct_tp_dst);
if (OVS_UNLIKELY(flow->nw_proto == IPPROTO_IGMP)) {
FLOWMAP_SET(map, igmp_group_ip4);
} else {
FLOWMAP_SET(map, tcp_flags);
}
} else if (flow->dl_type == htons(ETH_TYPE_IPV6)) {
FLOWMAP_SET(map, ipv6_src);
FLOWMAP_SET(map, ipv6_dst);
FLOWMAP_SET(map, ipv6_label);
FLOWMAP_SET(map, nw_proto);
FLOWMAP_SET(map, nw_frag);
FLOWMAP_SET(map, nw_tos);
FLOWMAP_SET(map, nw_ttl);
FLOWMAP_SET(map, tp_src);
FLOWMAP_SET(map, tp_dst);
if (OVS_UNLIKELY(is_nd(flow, NULL))) {
FLOWMAP_SET(map, nd_target);
FLOWMAP_SET(map, arp_sha);
FLOWMAP_SET(map, arp_tha);
FLOWMAP_SET(map, tcp_flags);
FLOWMAP_SET(map, igmp_group_ip4);
} else {
FLOWMAP_SET(map, ct_nw_proto);
FLOWMAP_SET(map, ct_ipv6_src);
FLOWMAP_SET(map, ct_ipv6_dst);
FLOWMAP_SET(map, ct_tp_src);
FLOWMAP_SET(map, ct_tp_dst);
FLOWMAP_SET(map, tcp_flags);
}
} else if (eth_type_mpls(flow->dl_type)) {
FLOWMAP_SET(map, mpls_lse);
} else if (flow->dl_type == htons(ETH_TYPE_ARP) ||
flow->dl_type == htons(ETH_TYPE_RARP)) {
FLOWMAP_SET(map, nw_src);
FLOWMAP_SET(map, nw_dst);
FLOWMAP_SET(map, nw_proto);
FLOWMAP_SET(map, arp_sha);
FLOWMAP_SET(map, arp_tha);
} else if (flow->dl_type == htons(ETH_TYPE_NSH)) {
FLOWMAP_SET(map, nsh.flags);
FLOWMAP_SET(map, nsh.mdtype);
FLOWMAP_SET(map, nsh.np);
FLOWMAP_SET(map, nsh.path_hdr);
FLOWMAP_SET(map, nsh.context);
}
}
/* Clear the metadata and register wildcard masks. They are not packet
* header fields. */
void
flow_wildcards_clear_non_packet_fields(struct flow_wildcards *wc)
{
/* Update this function whenever struct flow changes. */
BUILD_ASSERT_DECL(FLOW_WC_SEQ == 42);
memset(&wc->masks.metadata, 0, sizeof wc->masks.metadata);
memset(&wc->masks.regs, 0, sizeof wc->masks.regs);
wc->masks.actset_output = 0;
wc->masks.conj_id = 0;
}
/* Returns true if 'wc' matches every packet, false if 'wc' fixes any bits or
* fields. */
bool
flow_wildcards_is_catchall(const struct flow_wildcards *wc)
{
const uint64_t *wc_u64 = (const uint64_t *) &wc->masks;
size_t i;
for (i = 0; i < FLOW_U64S; i++) {
if (wc_u64[i]) {
return false;
}
}
return true;
}
/* Sets 'dst' as the bitwise AND of wildcards in 'src1' and 'src2'.
* That is, a bit or a field is wildcarded in 'dst' if it is wildcarded
* in 'src1' or 'src2' or both. */
void
flow_wildcards_and(struct flow_wildcards *dst,
const struct flow_wildcards *src1,
const struct flow_wildcards *src2)
{
uint64_t *dst_u64 = (uint64_t *) &dst->masks;
const uint64_t *src1_u64 = (const uint64_t *) &src1->masks;
const uint64_t *src2_u64 = (const uint64_t *) &src2->masks;
size_t i;
for (i = 0; i < FLOW_U64S; i++) {
dst_u64[i] = src1_u64[i] & src2_u64[i];
}
}
/* Sets 'dst' as the bitwise OR of wildcards in 'src1' and 'src2'. That
* is, a bit or a field is wildcarded in 'dst' if it is neither
* wildcarded in 'src1' nor 'src2'. */
void
flow_wildcards_or(struct flow_wildcards *dst,
const struct flow_wildcards *src1,
const struct flow_wildcards *src2)
{
uint64_t *dst_u64 = (uint64_t *) &dst->masks;
const uint64_t *src1_u64 = (const uint64_t *) &src1->masks;
const uint64_t *src2_u64 = (const uint64_t *) &src2->masks;
size_t i;
for (i = 0; i < FLOW_U64S; i++) {
dst_u64[i] = src1_u64[i] | src2_u64[i];
}
}
/* Returns a hash of the wildcards in 'wc'. */
uint32_t
flow_wildcards_hash(const struct flow_wildcards *wc, uint32_t basis)
{
return flow_hash(&wc->masks, basis);
}
/* Returns true if 'a' and 'b' represent the same wildcards, false if they are
* different. */
bool
flow_wildcards_equal(const struct flow_wildcards *a,
const struct flow_wildcards *b)
{
return flow_equal(&a->masks, &b->masks);
}
/* Returns true if at least one bit or field is wildcarded in 'a' but not in
* 'b', false otherwise. */
bool
flow_wildcards_has_extra(const struct flow_wildcards *a,
const struct flow_wildcards *b)
{
const uint64_t *a_u64 = (const uint64_t *) &a->masks;
const uint64_t *b_u64 = (const uint64_t *) &b->masks;
size_t i;
for (i = 0; i < FLOW_U64S; i++) {
if ((a_u64[i] & b_u64[i]) != b_u64[i]) {
return true;
}
}
return false;
}
/* Returns true if 'a' and 'b' are equal, except that 0-bits (wildcarded bits)
* in 'wc' do not need to be equal in 'a' and 'b'. */
bool
flow_equal_except(const struct flow *a, const struct flow *b,
const struct flow_wildcards *wc)
{
const uint64_t *a_u64 = (const uint64_t *) a;
const uint64_t *b_u64 = (const uint64_t *) b;
const uint64_t *wc_u64 = (const uint64_t *) &wc->masks;
size_t i;
for (i = 0; i < FLOW_U64S; i++) {
if ((a_u64[i] ^ b_u64[i]) & wc_u64[i]) {
return false;
}
}
return true;
}
/* Sets the wildcard mask for register 'idx' in 'wc' to 'mask'.
* (A 0-bit indicates a wildcard bit.) */
void
flow_wildcards_set_reg_mask(struct flow_wildcards *wc, int idx, uint32_t mask)
{
wc->masks.regs[idx] = mask;
}
/* Sets the wildcard mask for register 'idx' in 'wc' to 'mask'.
* (A 0-bit indicates a wildcard bit.) */
void
flow_wildcards_set_xreg_mask(struct flow_wildcards *wc, int idx, uint64_t mask)
{
flow_set_xreg(&wc->masks, idx, mask);
}
/* Sets the wildcard mask for register 'idx' in 'wc' to 'mask'.
* (A 0-bit indicates a wildcard bit.) */
void
flow_wildcards_set_xxreg_mask(struct flow_wildcards *wc, int idx,
ovs_u128 mask)
{
flow_set_xxreg(&wc->masks, idx, mask);
}
/* Calculates the 5-tuple hash from the given miniflow.
* This returns the same value as flow_hash_5tuple for the corresponding
* flow. */
uint32_t
miniflow_hash_5tuple(const struct miniflow *flow, uint32_t basis)
{
BUILD_ASSERT_DECL(FLOW_WC_SEQ == 42);
uint32_t hash = basis;
if (flow) {
ovs_be16 dl_type = MINIFLOW_GET_BE16(flow, dl_type);
uint8_t nw_proto;
if (dl_type == htons(ETH_TYPE_IPV6)) {
struct flowmap map = FLOWMAP_EMPTY_INITIALIZER;
uint64_t value;
FLOWMAP_SET(&map, ipv6_src);
FLOWMAP_SET(&map, ipv6_dst);
MINIFLOW_FOR_EACH_IN_FLOWMAP(value, flow, map) {
hash = hash_add64(hash, value);
}
} else if (dl_type == htons(ETH_TYPE_IP)
|| dl_type == htons(ETH_TYPE_ARP)) {
hash = hash_add(hash, MINIFLOW_GET_U32(flow, nw_src));
hash = hash_add(hash, MINIFLOW_GET_U32(flow, nw_dst));
} else {
goto out;
}
nw_proto = MINIFLOW_GET_U8(flow, nw_proto);
hash = hash_add(hash, nw_proto);
if (nw_proto != IPPROTO_TCP && nw_proto != IPPROTO_UDP
&& nw_proto != IPPROTO_SCTP && nw_proto != IPPROTO_ICMP
&& nw_proto != IPPROTO_ICMPV6) {
goto out;
}
/* Add both ports at once. */
hash = hash_add(hash, (OVS_FORCE uint32_t) miniflow_get_ports(flow));
}
out:
return hash_finish(hash, 42);
}
ASSERT_SEQUENTIAL_SAME_WORD(tp_src, tp_dst);
ASSERT_SEQUENTIAL(ipv6_src, ipv6_dst);
/* Calculates the 5-tuple hash from the given flow. */
uint32_t
flow_hash_5tuple(const struct flow *flow, uint32_t basis)
{
BUILD_ASSERT_DECL(FLOW_WC_SEQ == 42);
uint32_t hash = basis;
if (flow) {
if (flow->dl_type == htons(ETH_TYPE_IPV6)) {
const uint64_t *flow_u64 = (const uint64_t *)flow;
int ofs = offsetof(struct flow, ipv6_src) / 8;
int end = ofs + 2 * sizeof flow->ipv6_src / 8;
for (;ofs < end; ofs++) {
hash = hash_add64(hash, flow_u64[ofs]);
}
} else if (flow->dl_type == htons(ETH_TYPE_IP)
|| flow->dl_type == htons(ETH_TYPE_ARP)) {
hash = hash_add(hash, (OVS_FORCE uint32_t) flow->nw_src);
hash = hash_add(hash, (OVS_FORCE uint32_t) flow->nw_dst);
} else {
goto out;
}
hash = hash_add(hash, flow->nw_proto);
if (flow->nw_proto != IPPROTO_TCP && flow->nw_proto != IPPROTO_UDP
&& flow->nw_proto != IPPROTO_SCTP && flow->nw_proto != IPPROTO_ICMP
&& flow->nw_proto != IPPROTO_ICMPV6) {
goto out;
}
/* Add both ports at once. */
hash = hash_add(hash,
((const uint32_t *)flow)[offsetof(struct flow, tp_src)
/ sizeof(uint32_t)]);
}
out:
return hash_finish(hash, 42); /* Arbitrary number. */
}
/* Hashes 'flow' based on its L2 through L4 protocol information. */
uint32_t
flow_hash_symmetric_l4(const struct flow *flow, uint32_t basis)
{
struct {
union {
ovs_be32 ipv4_addr;
struct in6_addr ipv6_addr;
};
ovs_be16 eth_type;
ovs_be16 vlan_tci;
ovs_be16 tp_port;
struct eth_addr eth_addr;
uint8_t ip_proto;
} fields;
int i;
memset(&fields, 0, sizeof fields);
for (i = 0; i < ARRAY_SIZE(fields.eth_addr.be16); i++) {
fields.eth_addr.be16[i] = flow->dl_src.be16[i] ^ flow->dl_dst.be16[i];
}
for (i = 0; i < FLOW_MAX_VLAN_HEADERS; i++) {
fields.vlan_tci ^= flow->vlans[i].tci & htons(VLAN_VID_MASK);
}
fields.eth_type = flow->dl_type;
/* UDP source and destination port are not taken into account because they
* will not necessarily be symmetric in a bidirectional flow. */
if (fields.eth_type == htons(ETH_TYPE_IP)) {
fields.ipv4_addr = flow->nw_src ^ flow->nw_dst;
fields.ip_proto = flow->nw_proto;
if (fields.ip_proto == IPPROTO_TCP || fields.ip_proto == IPPROTO_SCTP) {
fields.tp_port = flow->tp_src ^ flow->tp_dst;
}
} else if (fields.eth_type == htons(ETH_TYPE_IPV6)) {
const uint8_t *a = &flow->ipv6_src.s6_addr[0];
const uint8_t *b = &flow->ipv6_dst.s6_addr[0];
uint8_t *ipv6_addr = &fields.ipv6_addr.s6_addr[0];
for (i=0; i<16; i++) {
ipv6_addr[i] = a[i] ^ b[i];
}
fields.ip_proto = flow->nw_proto;
if (fields.ip_proto == IPPROTO_TCP || fields.ip_proto == IPPROTO_SCTP) {
fields.tp_port = flow->tp_src ^ flow->tp_dst;
}
}
return jhash_bytes(&fields, sizeof fields, basis);
}
/* Symmetrically Hashes non-IP 'flow' based on its L2 headers. */
uint32_t
flow_hash_symmetric_l2(const struct flow *flow, uint32_t basis)
{
union {
struct {
ovs_be16 eth_type;
ovs_be16 vlan_tci;
struct eth_addr eth_addr;
ovs_be16 pad;
};
uint32_t word[3];
} fields;
uint32_t hash = basis;
int i;
if (flow->packet_type != htonl(PT_ETH)) {
/* Cannot hash non-Ethernet flows */
return 0;
}
for (i = 0; i < ARRAY_SIZE(fields.eth_addr.be16); i++) {
fields.eth_addr.be16[i] =
flow->dl_src.be16[i] ^ flow->dl_dst.be16[i];
}
fields.vlan_tci = 0;
for (i = 0; i < FLOW_MAX_VLAN_HEADERS; i++) {
fields.vlan_tci ^= flow->vlans[i].tci & htons(VLAN_VID_MASK);
}
fields.eth_type = flow->dl_type;
fields.pad = 0;
hash = hash_add(hash, fields.word[0]);
hash = hash_add(hash, fields.word[1]);
hash = hash_add(hash, fields.word[2]);
return hash_finish(hash, basis);
}
/* Hashes 'flow' based on its L3 through L4 protocol information */
uint32_t
flow_hash_symmetric_l3l4(const struct flow *flow, uint32_t basis,
bool inc_udp_ports)
{
uint32_t hash = basis;
/* UDP source and destination port are also taken into account. */
if (flow->dl_type == htons(ETH_TYPE_IP)) {
hash = hash_add(hash,
(OVS_FORCE uint32_t) (flow->nw_src ^ flow->nw_dst));
} else if (flow->dl_type == htons(ETH_TYPE_IPV6)) {
/* IPv6 addresses are 64-bit aligned inside struct flow. */
const uint64_t *a = ALIGNED_CAST(uint64_t *, flow->ipv6_src.s6_addr);
const uint64_t *b = ALIGNED_CAST(uint64_t *, flow->ipv6_dst.s6_addr);
for (int i = 0; i < sizeof flow->ipv6_src / sizeof *a; i++) {
hash = hash_add64(hash, a[i] ^ b[i]);
}
} else {
/* Revert to hashing L2 headers */
return flow_hash_symmetric_l2(flow, basis);
}
hash = hash_add(hash, flow->nw_proto);
if (!(flow->nw_frag & FLOW_NW_FRAG_MASK)
&& (flow->nw_proto == IPPROTO_TCP || flow->nw_proto == IPPROTO_SCTP ||
(inc_udp_ports && flow->nw_proto == IPPROTO_UDP))) {
hash = hash_add(hash,
(OVS_FORCE uint16_t) (flow->tp_src ^ flow->tp_dst));
}
return hash_finish(hash, basis);
}
/* Hashes 'flow' based on its nw_dst and nw_src for multipath. */
uint32_t
flow_hash_symmetric_l3(const struct flow *flow, uint32_t basis)
{
struct {
union {
ovs_be32 ipv4_addr;
struct in6_addr ipv6_addr;
};
ovs_be16 eth_type;
} fields;
int i;
memset(&fields, 0, sizeof fields);
fields.eth_type = flow->dl_type;
if (fields.eth_type == htons(ETH_TYPE_IP)) {
fields.ipv4_addr = flow->nw_src ^ flow->nw_dst;
} else if (fields.eth_type == htons(ETH_TYPE_IPV6)) {
const uint8_t *a = &flow->ipv6_src.s6_addr[0];
const uint8_t *b = &flow->ipv6_dst.s6_addr[0];
uint8_t *ipv6_addr = &fields.ipv6_addr.s6_addr[0];
for (i = 0; i < 16; i++) {
ipv6_addr[i] = a[i] ^ b[i];
}
}
return jhash_bytes(&fields, sizeof fields, basis);
}
/* Initialize a flow with random fields that matter for nx_hash_fields. */
void
flow_random_hash_fields(struct flow *flow)
{
uint16_t rnd = random_uint16();
int i;
/* Initialize to all zeros. */
memset(flow, 0, sizeof *flow);
eth_addr_random(&flow->dl_src);
eth_addr_random(&flow->dl_dst);
for (i = 0; i < FLOW_MAX_VLAN_HEADERS; i++) {
uint16_t vlan = random_uint16() & VLAN_VID_MASK;
flow->vlans[i].tpid = htons(ETH_TYPE_VLAN_8021Q);
flow->vlans[i].tci = htons(vlan | VLAN_CFI);
}
/* Make most of the random flows IPv4, some IPv6, and rest random. */
flow->dl_type = rnd < 0x8000 ? htons(ETH_TYPE_IP) :
rnd < 0xc000 ? htons(ETH_TYPE_IPV6) : (OVS_FORCE ovs_be16)rnd;
if (dl_type_is_ip_any(flow->dl_type)) {
if (flow->dl_type == htons(ETH_TYPE_IP)) {
flow->nw_src = (OVS_FORCE ovs_be32)random_uint32();
flow->nw_dst = (OVS_FORCE ovs_be32)random_uint32();
} else {
random_bytes(&flow->ipv6_src, sizeof flow->ipv6_src);
random_bytes(&flow->ipv6_dst, sizeof flow->ipv6_dst);
}
/* Make most of IP flows TCP, some UDP or SCTP, and rest random. */
rnd = random_uint16();
flow->nw_proto = rnd < 0x8000 ? IPPROTO_TCP :
rnd < 0xc000 ? IPPROTO_UDP :
rnd < 0xd000 ? IPPROTO_SCTP : (uint8_t)rnd;
if (flow->nw_proto == IPPROTO_TCP ||
flow->nw_proto == IPPROTO_UDP ||
flow->nw_proto == IPPROTO_SCTP) {
flow->tp_src = (OVS_FORCE ovs_be16)random_uint16();
flow->tp_dst = (OVS_FORCE ovs_be16)random_uint16();
}
}
}
/* Masks the fields in 'wc' that are used by the flow hash 'fields'. */
void
flow_mask_hash_fields(const struct flow *flow, struct flow_wildcards *wc,
enum nx_hash_fields fields)
{
int i;
switch (fields) {
case NX_HASH_FIELDS_ETH_SRC:
memset(&wc->masks.dl_src, 0xff, sizeof wc->masks.dl_src);
break;
case NX_HASH_FIELDS_SYMMETRIC_L4:
memset(&wc->masks.dl_src, 0xff, sizeof wc->masks.dl_src);
memset(&wc->masks.dl_dst, 0xff, sizeof wc->masks.dl_dst);
if (flow->dl_type == htons(ETH_TYPE_IP)) {
memset(&wc->masks.nw_src, 0xff, sizeof wc->masks.nw_src);
memset(&wc->masks.nw_dst, 0xff, sizeof wc->masks.nw_dst);
} else if (flow->dl_type == htons(ETH_TYPE_IPV6)) {
memset(&wc->masks.ipv6_src, 0xff, sizeof wc->masks.ipv6_src);
memset(&wc->masks.ipv6_dst, 0xff, sizeof wc->masks.ipv6_dst);
}
if (is_ip_any(flow)) {
memset(&wc->masks.nw_proto, 0xff, sizeof wc->masks.nw_proto);
/* Unwildcard port only for non-UDP packets as udp port
* numbers are not used in hash calculations.
*/
if (flow->nw_proto != IPPROTO_UDP) {
flow_unwildcard_tp_ports(flow, wc);
}
}
for (i = 0; i < FLOW_MAX_VLAN_HEADERS; i++) {
wc->masks.vlans[i].tci |= htons(VLAN_VID_MASK | VLAN_CFI);
}
break;
case NX_HASH_FIELDS_SYMMETRIC_L3L4_UDP:
if (is_ip_any(flow) && flow->nw_proto == IPPROTO_UDP
&& !(flow->nw_frag & FLOW_NW_FRAG_MASK)) {
memset(&wc->masks.tp_src, 0xff, sizeof wc->masks.tp_src);
memset(&wc->masks.tp_dst, 0xff, sizeof wc->masks.tp_dst);
}
/* fall through */
case NX_HASH_FIELDS_SYMMETRIC_L3L4:
if (flow->dl_type == htons(ETH_TYPE_IP)) {
memset(&wc->masks.nw_src, 0xff, sizeof wc->masks.nw_src);
memset(&wc->masks.nw_dst, 0xff, sizeof wc->masks.nw_dst);
} else if (flow->dl_type == htons(ETH_TYPE_IPV6)) {
memset(&wc->masks.ipv6_src, 0xff, sizeof wc->masks.ipv6_src);
memset(&wc->masks.ipv6_dst, 0xff, sizeof wc->masks.ipv6_dst);
} else {
break; /* non-IP flow */
}
memset(&wc->masks.nw_proto, 0xff, sizeof wc->masks.nw_proto);
if ((flow->nw_proto == IPPROTO_TCP || flow->nw_proto == IPPROTO_SCTP)
&& !(flow->nw_frag & FLOW_NW_FRAG_MASK)) {
memset(&wc->masks.tp_src, 0xff, sizeof wc->masks.tp_src);
memset(&wc->masks.tp_dst, 0xff, sizeof wc->masks.tp_dst);
}
break;
case NX_HASH_FIELDS_NW_SRC:
if (flow->dl_type == htons(ETH_TYPE_IP)) {
memset(&wc->masks.nw_src, 0xff, sizeof wc->masks.nw_src);
} else if (flow->dl_type == htons(ETH_TYPE_IPV6)) {
memset(&wc->masks.ipv6_src, 0xff, sizeof wc->masks.ipv6_src);
}
break;
case NX_HASH_FIELDS_NW_DST:
if (flow->dl_type == htons(ETH_TYPE_IP)) {
memset(&wc->masks.nw_dst, 0xff, sizeof wc->masks.nw_dst);
} else if (flow->dl_type == htons(ETH_TYPE_IPV6)) {
memset(&wc->masks.ipv6_dst, 0xff, sizeof wc->masks.ipv6_dst);
}
break;
case NX_HASH_FIELDS_SYMMETRIC_L3:
if (flow->dl_type == htons(ETH_TYPE_IP)) {
memset(&wc->masks.nw_src, 0xff, sizeof wc->masks.nw_src);
memset(&wc->masks.nw_dst, 0xff, sizeof wc->masks.nw_dst);
} else if (flow->dl_type == htons(ETH_TYPE_IPV6)) {
memset(&wc->masks.ipv6_src, 0xff, sizeof wc->masks.ipv6_src);
memset(&wc->masks.ipv6_dst, 0xff, sizeof wc->masks.ipv6_dst);
}
break;
default:
OVS_NOT_REACHED();
}
}
/* Hashes the portions of 'flow' designated by 'fields'. */
uint32_t
flow_hash_fields(const struct flow *flow, enum nx_hash_fields fields,
uint16_t basis)
{
switch (fields) {
case NX_HASH_FIELDS_ETH_SRC:
return jhash_bytes(&flow->dl_src, sizeof flow->dl_src, basis);
case NX_HASH_FIELDS_SYMMETRIC_L4:
return flow_hash_symmetric_l4(flow, basis);
case NX_HASH_FIELDS_SYMMETRIC_L3L4:
return flow_hash_symmetric_l3l4(flow, basis, false);
case NX_HASH_FIELDS_SYMMETRIC_L3L4_UDP:
return flow_hash_symmetric_l3l4(flow, basis, true);
case NX_HASH_FIELDS_NW_SRC:
if (flow->dl_type == htons(ETH_TYPE_IP)) {
return jhash_bytes(&flow->nw_src, sizeof flow->nw_src, basis);
} else if (flow->dl_type == htons(ETH_TYPE_IPV6)) {
return jhash_bytes(&flow->ipv6_src, sizeof flow->ipv6_src, basis);
} else {
return basis;
}
case NX_HASH_FIELDS_NW_DST:
if (flow->dl_type == htons(ETH_TYPE_IP)) {
return jhash_bytes(&flow->nw_dst, sizeof flow->nw_dst, basis);
} else if (flow->dl_type == htons(ETH_TYPE_IPV6)) {
return jhash_bytes(&flow->ipv6_dst, sizeof flow->ipv6_dst, basis);
} else {
return basis;
}
case NX_HASH_FIELDS_SYMMETRIC_L3:
return flow_hash_symmetric_l3(flow, basis);
}
OVS_NOT_REACHED();
}
/* Returns a string representation of 'fields'. */
const char *
flow_hash_fields_to_str(enum nx_hash_fields fields)
{
switch (fields) {
case NX_HASH_FIELDS_ETH_SRC: return "eth_src";
case NX_HASH_FIELDS_SYMMETRIC_L4: return "symmetric_l4";
case NX_HASH_FIELDS_SYMMETRIC_L3L4: return "symmetric_l3l4";
case NX_HASH_FIELDS_SYMMETRIC_L3L4_UDP: return "symmetric_l3l4+udp";
case NX_HASH_FIELDS_NW_SRC: return "nw_src";
case NX_HASH_FIELDS_NW_DST: return "nw_dst";
case NX_HASH_FIELDS_SYMMETRIC_L3: return "symmetric_l3";
default: return "<unknown>";
}
}
/* Returns true if the value of 'fields' is supported. Otherwise false. */
bool
flow_hash_fields_valid(enum nx_hash_fields fields)
{
return fields == NX_HASH_FIELDS_ETH_SRC
|| fields == NX_HASH_FIELDS_SYMMETRIC_L4
|| fields == NX_HASH_FIELDS_SYMMETRIC_L3L4
|| fields == NX_HASH_FIELDS_SYMMETRIC_L3L4_UDP
|| fields == NX_HASH_FIELDS_NW_SRC
|| fields == NX_HASH_FIELDS_NW_DST
|| fields == NX_HASH_FIELDS_SYMMETRIC_L3;
}
/* Returns a hash value for the bits of 'flow' that are active based on
* 'wc', given 'basis'. */
uint32_t
flow_hash_in_wildcards(const struct flow *flow,
const struct flow_wildcards *wc, uint32_t basis)
{
const uint64_t *wc_u64 = (const uint64_t *) &wc->masks;
const uint64_t *flow_u64 = (const uint64_t *) flow;
uint32_t hash;
size_t i;
hash = basis;
for (i = 0; i < FLOW_U64S; i++) {
hash = hash_add64(hash, flow_u64[i] & wc_u64[i]);
}
return hash_finish(hash, 8 * FLOW_U64S);
}
/* Sets the VLAN VID that 'flow' matches to 'vid', which is interpreted as an
* OpenFlow 1.0 "dl_vlan" value:
*
* - If it is in the range 0...4095, 'flow->vlans[0].tci' is set to match
* that VLAN. Any existing PCP match is unchanged (it becomes 0 if
* 'flow' previously matched packets without a VLAN header).
*
* - If it is OFP_VLAN_NONE, 'flow->vlan_tci' is set to match a packet
* without a VLAN tag.
*
* - Other values of 'vid' should not be used. */
void
flow_set_dl_vlan(struct flow *flow, ovs_be16 vid, int id)
{
if (vid == htons(OFP10_VLAN_NONE)) {
flow->vlans[id].tci = htons(0);
} else {
vid &= htons(VLAN_VID_MASK);
flow->vlans[id].tci &= ~htons(VLAN_VID_MASK);
flow->vlans[id].tci |= htons(VLAN_CFI) | vid;
}
}
/* Sets the VLAN header TPID, which must be either ETH_TYPE_VLAN_8021Q or
* ETH_TYPE_VLAN_8021AD. */
void
flow_fix_vlan_tpid(struct flow *flow)
{
if (flow->vlans[0].tpid == htons(0) && flow->vlans[0].tci != 0) {
flow->vlans[0].tpid = htons(ETH_TYPE_VLAN_8021Q);
}
}
/* Sets the VLAN VID that 'flow' matches to 'vid', which is interpreted as an
* OpenFlow 1.2 "vlan_vid" value, that is, the low 13 bits of 'vlan_tci' (VID
* plus CFI). */
void
flow_set_vlan_vid(struct flow *flow, ovs_be16 vid)
{
ovs_be16 mask = htons(VLAN_VID_MASK | VLAN_CFI);
flow->vlans[0].tci &= ~mask;
flow->vlans[0].tci |= vid & mask;
}
/* Sets the VLAN PCP that 'flow' matches to 'pcp', which should be in the
* range 0...7.
*
* This function has no effect on the VLAN ID that 'flow' matches.
*
* After calling this function, 'flow' will not match packets without a VLAN
* header. */
void
flow_set_vlan_pcp(struct flow *flow, uint8_t pcp, int id)
{
pcp &= 0x07;
flow->vlans[id].tci &= ~htons(VLAN_PCP_MASK);
flow->vlans[id].tci |= htons((pcp << VLAN_PCP_SHIFT) | VLAN_CFI);
}
/* Counts the number of VLAN headers. */
int
flow_count_vlan_headers(const struct flow *flow)
{
int i;
for (i = 0; i < FLOW_MAX_VLAN_HEADERS; i++) {
if (!(flow->vlans[i].tci & htons(VLAN_CFI))) {
break;
}
}
return i;
}
/* Given '*p_an' and '*p_bn' pointing to one past the last VLAN header of
* 'a' and 'b' respectively, skip common VLANs so that they point to the
* first different VLAN counting from bottom. */
void
flow_skip_common_vlan_headers(const struct flow *a, int *p_an,
const struct flow *b, int *p_bn)
{
int an = *p_an, bn = *p_bn;
for (an--, bn--; an >= 0 && bn >= 0; an--, bn--) {
if (a->vlans[an].qtag != b->vlans[bn].qtag) {
break;
}
}
*p_an = an;
*p_bn = bn;
}
void
flow_pop_vlan(struct flow *flow, struct flow_wildcards *wc)
{
int n = flow_count_vlan_headers(flow);
if (n > 1) {
if (wc) {
memset(&wc->masks.vlans[1], 0xff,
sizeof(union flow_vlan_hdr) * (n - 1));
}
memmove(&flow->vlans[0], &flow->vlans[1],
sizeof(union flow_vlan_hdr) * (n - 1));
}
if (n > 0) {
memset(&flow->vlans[n - 1], 0, sizeof(union flow_vlan_hdr));
}
}
void
flow_push_vlan_uninit(struct flow *flow, struct flow_wildcards *wc)
{
if (wc) {
int n = flow_count_vlan_headers(flow);
if (n) {
memset(wc->masks.vlans, 0xff, sizeof(union flow_vlan_hdr) * n);
}
}
memmove(&flow->vlans[1], &flow->vlans[0],
sizeof(union flow_vlan_hdr) * (FLOW_MAX_VLAN_HEADERS - 1));
memset(&flow->vlans[0], 0, sizeof(union flow_vlan_hdr));
}
/* Returns the number of MPLS LSEs present in 'flow'
*
* Returns 0 if the 'dl_type' of 'flow' is not an MPLS ethernet type.
* Otherwise traverses 'flow''s MPLS label stack stopping at the
* first entry that has the BoS bit set. If no such entry exists then
* the maximum number of LSEs that can be stored in 'flow' is returned.
*/
int
flow_count_mpls_labels(const struct flow *flow, struct flow_wildcards *wc)
{
/* dl_type is always masked. */
if (eth_type_mpls(flow->dl_type)) {
int i;
int cnt;
cnt = 0;
for (i = 0; i < FLOW_MAX_MPLS_LABELS; i++) {
if (wc) {
wc->masks.mpls_lse[i] |= htonl(MPLS_BOS_MASK);
}
if (flow->mpls_lse[i] & htonl(MPLS_BOS_MASK)) {
return i + 1;
}
if (flow->mpls_lse[i]) {
cnt++;
}
}
return cnt;
} else {
return 0;
}
}
/* Returns the number consecutive of MPLS LSEs, starting at the
* innermost LSE, that are common in 'a' and 'b'.
*
* 'an' must be flow_count_mpls_labels(a).
* 'bn' must be flow_count_mpls_labels(b).
*/
int
flow_count_common_mpls_labels(const struct flow *a, int an,
const struct flow *b, int bn,
struct flow_wildcards *wc)
{
int min_n = MIN(an, bn);
if (min_n == 0) {
return 0;
} else {
int common_n = 0;
int a_last = an - 1;
int b_last = bn - 1;
int i;
for (i = 0; i < min_n; i++) {
if (wc) {
wc->masks.mpls_lse[a_last - i] = OVS_BE32_MAX;
wc->masks.mpls_lse[b_last - i] = OVS_BE32_MAX;
}
if (a->mpls_lse[a_last - i] != b->mpls_lse[b_last - i]) {
break;
} else {
common_n++;
}
}
return common_n;
}
}
/* Adds a new outermost MPLS label to 'flow' and changes 'flow''s Ethernet type
* to 'mpls_eth_type', which must be an MPLS Ethertype.
*
* If the new label is the first MPLS label in 'flow', it is generated as;
*
* - label: 2, if 'flow' is IPv6, otherwise 0.
*
* - TTL: IPv4 or IPv6 TTL, if present and nonzero, otherwise 64.
*
* - TC: IPv4 or IPv6 TOS, if present, otherwise 0.
*
* - BoS: 1.
*
* If the new label is the second or later label MPLS label in 'flow', it is
* generated as;
*
* - label: Copied from outer label.
*
* - TTL: Copied from outer label.
*
* - TC: Copied from outer label.
*
* - BoS: 0.
*
* 'n' must be flow_count_mpls_labels(flow). 'n' must be less than
* FLOW_MAX_MPLS_LABELS (because otherwise flow->mpls_lse[] would overflow).
*/
void
flow_push_mpls(struct flow *flow, int n, ovs_be16 mpls_eth_type,
mpls: Fix MPLS restoration after patch port and group bucket. This patch fixes problems with MPLS handling related to patch ports and group buckets. If a group bucket or a peer bridge across a patch port pushes MPLS headers to a non-MPLS packet and outputs, the flow translation after returning from the group bucket or patch port would undo the packet transformations so that the processing could continue with the packet as it was before entering the patch port. There were two problems with this: 1. As part of the first MPLS push on a non-MPLS packet, the flow translation would first clear the L3/4 headers of the 'flow' to mark those fields invalid. Later, when committing 'flow' changes to datapath actions before output, the necessary datapath MPLS actions are created and the corresponding changes updated to the 'base flow'. This was done using the same flow_push_mpls() function that clears the L2/3 headers, so also the 'base flow' L2/3 headers were cleared. Then, when translation returns from a patch port or group bucket, the original 'flow' is restored, now showing no sign of the MPLS labels. Since the 'base flow' now has the MPLS labels, following translations know to issue MPLS POP actions before any output actions. However, as part of checking for changes to IP headers we test that the IP protocol type was not changed. But now the 'base flow's 'nw_proto' field is zero and an assert fail crashes OVS. This is solved by not clearing the L3/4 fields of the 'base flow'. This allows the processing after the patch port to continue with L3/4 fields as if no MPLS was done, after first issuing the necessary MPLS POP actions. 2. IP header updates were done before the MPLS POP actions were issued. This caused incorrect packet output after, e.g., group action or patch port. For example, with actions: group 1234: all bucket=push_mpls,output:LOCAL ip actions=group:1234,dec_ttl,output:LOCAL,output:LOCAL the dec_ttl would only be executed before the last output to LOCAL, since at the time of committing IP changes after the group action the packet was still an MPLS packet. This is solved by checking the dl_type of both 'flow' and 'base flow' and issuing MPLS actions if they can transform the packet from an MPLS packet to a non-MPLS packet. For an IP packet the change in ttl can then be correctly committed before the last two output actions. Two test cases are added to prevent future regressions. Reported-by: Thomas Morin <thomas.morin@orange.com> Suggested-by: Takashi YAMAMOTO <yamamoto@ovn.org> Fixes: 8bfd0fdac ("Enhance userspace support for MPLS, for up to 3 labels.") Fixes: 1b035ef20 ("mpls: Allow l3 and l4 actions to prior to a push_mpls action") Signed-off-by: Jarno Rajahalme <jarno@ovn.org> Acked-by: YAMAMOTO Takashi <yamamoto@ovn.org>
2016-12-01 14:05:24 -08:00
struct flow_wildcards *wc, bool clear_flow_L3)
{
ovs_assert(eth_type_mpls(mpls_eth_type));
ovs_assert(n < FLOW_MAX_MPLS_LABELS);
if (n) {
int i;
if (wc) {
memset(&wc->masks.mpls_lse, 0xff, sizeof *wc->masks.mpls_lse * n);
}
for (i = n; i >= 1; i--) {
flow->mpls_lse[i] = flow->mpls_lse[i - 1];
}
flow->mpls_lse[0] = (flow->mpls_lse[1] & htonl(~MPLS_BOS_MASK));
} else {
int label = 0; /* IPv4 Explicit Null. */
int tc = 0;
int ttl = 64;
if (flow->dl_type == htons(ETH_TYPE_IPV6)) {
label = 2;
}
if (is_ip_any(flow)) {
tc = (flow->nw_tos & IP_DSCP_MASK) >> 2;
if (wc) {
wc->masks.nw_tos |= IP_DSCP_MASK;
wc->masks.nw_ttl = 0xff;
}
if (flow->nw_ttl) {
ttl = flow->nw_ttl;
}
}
flow->mpls_lse[0] = set_mpls_lse_values(ttl, tc, 1, htonl(label));
mpls: Fix MPLS restoration after patch port and group bucket. This patch fixes problems with MPLS handling related to patch ports and group buckets. If a group bucket or a peer bridge across a patch port pushes MPLS headers to a non-MPLS packet and outputs, the flow translation after returning from the group bucket or patch port would undo the packet transformations so that the processing could continue with the packet as it was before entering the patch port. There were two problems with this: 1. As part of the first MPLS push on a non-MPLS packet, the flow translation would first clear the L3/4 headers of the 'flow' to mark those fields invalid. Later, when committing 'flow' changes to datapath actions before output, the necessary datapath MPLS actions are created and the corresponding changes updated to the 'base flow'. This was done using the same flow_push_mpls() function that clears the L2/3 headers, so also the 'base flow' L2/3 headers were cleared. Then, when translation returns from a patch port or group bucket, the original 'flow' is restored, now showing no sign of the MPLS labels. Since the 'base flow' now has the MPLS labels, following translations know to issue MPLS POP actions before any output actions. However, as part of checking for changes to IP headers we test that the IP protocol type was not changed. But now the 'base flow's 'nw_proto' field is zero and an assert fail crashes OVS. This is solved by not clearing the L3/4 fields of the 'base flow'. This allows the processing after the patch port to continue with L3/4 fields as if no MPLS was done, after first issuing the necessary MPLS POP actions. 2. IP header updates were done before the MPLS POP actions were issued. This caused incorrect packet output after, e.g., group action or patch port. For example, with actions: group 1234: all bucket=push_mpls,output:LOCAL ip actions=group:1234,dec_ttl,output:LOCAL,output:LOCAL the dec_ttl would only be executed before the last output to LOCAL, since at the time of committing IP changes after the group action the packet was still an MPLS packet. This is solved by checking the dl_type of both 'flow' and 'base flow' and issuing MPLS actions if they can transform the packet from an MPLS packet to a non-MPLS packet. For an IP packet the change in ttl can then be correctly committed before the last two output actions. Two test cases are added to prevent future regressions. Reported-by: Thomas Morin <thomas.morin@orange.com> Suggested-by: Takashi YAMAMOTO <yamamoto@ovn.org> Fixes: 8bfd0fdac ("Enhance userspace support for MPLS, for up to 3 labels.") Fixes: 1b035ef20 ("mpls: Allow l3 and l4 actions to prior to a push_mpls action") Signed-off-by: Jarno Rajahalme <jarno@ovn.org> Acked-by: YAMAMOTO Takashi <yamamoto@ovn.org>
2016-12-01 14:05:24 -08:00
if (clear_flow_L3) {
/* Clear all L3 and L4 fields and dp_hash. */
BUILD_ASSERT(FLOW_WC_SEQ == 42);
mpls: Fix MPLS restoration after patch port and group bucket. This patch fixes problems with MPLS handling related to patch ports and group buckets. If a group bucket or a peer bridge across a patch port pushes MPLS headers to a non-MPLS packet and outputs, the flow translation after returning from the group bucket or patch port would undo the packet transformations so that the processing could continue with the packet as it was before entering the patch port. There were two problems with this: 1. As part of the first MPLS push on a non-MPLS packet, the flow translation would first clear the L3/4 headers of the 'flow' to mark those fields invalid. Later, when committing 'flow' changes to datapath actions before output, the necessary datapath MPLS actions are created and the corresponding changes updated to the 'base flow'. This was done using the same flow_push_mpls() function that clears the L2/3 headers, so also the 'base flow' L2/3 headers were cleared. Then, when translation returns from a patch port or group bucket, the original 'flow' is restored, now showing no sign of the MPLS labels. Since the 'base flow' now has the MPLS labels, following translations know to issue MPLS POP actions before any output actions. However, as part of checking for changes to IP headers we test that the IP protocol type was not changed. But now the 'base flow's 'nw_proto' field is zero and an assert fail crashes OVS. This is solved by not clearing the L3/4 fields of the 'base flow'. This allows the processing after the patch port to continue with L3/4 fields as if no MPLS was done, after first issuing the necessary MPLS POP actions. 2. IP header updates were done before the MPLS POP actions were issued. This caused incorrect packet output after, e.g., group action or patch port. For example, with actions: group 1234: all bucket=push_mpls,output:LOCAL ip actions=group:1234,dec_ttl,output:LOCAL,output:LOCAL the dec_ttl would only be executed before the last output to LOCAL, since at the time of committing IP changes after the group action the packet was still an MPLS packet. This is solved by checking the dl_type of both 'flow' and 'base flow' and issuing MPLS actions if they can transform the packet from an MPLS packet to a non-MPLS packet. For an IP packet the change in ttl can then be correctly committed before the last two output actions. Two test cases are added to prevent future regressions. Reported-by: Thomas Morin <thomas.morin@orange.com> Suggested-by: Takashi YAMAMOTO <yamamoto@ovn.org> Fixes: 8bfd0fdac ("Enhance userspace support for MPLS, for up to 3 labels.") Fixes: 1b035ef20 ("mpls: Allow l3 and l4 actions to prior to a push_mpls action") Signed-off-by: Jarno Rajahalme <jarno@ovn.org> Acked-by: YAMAMOTO Takashi <yamamoto@ovn.org>
2016-12-01 14:05:24 -08:00
memset((char *) flow + FLOW_SEGMENT_2_ENDS_AT, 0,
sizeof(struct flow) - FLOW_SEGMENT_2_ENDS_AT);
flow->dp_hash = 0;
}
}
flow->dl_type = mpls_eth_type;
}
/* Tries to remove the outermost MPLS label from 'flow'. Returns true if
* successful, false otherwise. On success, sets 'flow''s Ethernet type to
* 'eth_type'.
*
* 'n' must be flow_count_mpls_labels(flow). */
bool
flow_pop_mpls(struct flow *flow, int n, ovs_be16 eth_type,
struct flow_wildcards *wc)
{
int i;
if (n == 0) {
/* Nothing to pop. */
return false;
} else if (n == FLOW_MAX_MPLS_LABELS) {
if (wc) {
wc->masks.mpls_lse[n - 1] |= htonl(MPLS_BOS_MASK);
}
if (!(flow->mpls_lse[n - 1] & htonl(MPLS_BOS_MASK))) {
/* Can't pop because don't know what to fill in mpls_lse[n - 1]. */
return false;
}
}
if (wc) {
memset(&wc->masks.mpls_lse[1], 0xff,
sizeof *wc->masks.mpls_lse * (n - 1));
}
for (i = 1; i < n; i++) {
flow->mpls_lse[i - 1] = flow->mpls_lse[i];
}
flow->mpls_lse[n - 1] = 0;
flow->dl_type = eth_type;
return true;
}
/* Sets the MPLS Label that 'flow' matches to 'label', which is interpreted
* as an OpenFlow 1.1 "mpls_label" value. */
void
flow_set_mpls_label(struct flow *flow, int idx, ovs_be32 label)
{
set_mpls_lse_label(&flow->mpls_lse[idx], label);
}
/* Sets the MPLS TTL that 'flow' matches to 'ttl', which should be in the
* range 0...255. */
void
flow_set_mpls_ttl(struct flow *flow, int idx, uint8_t ttl)
{
set_mpls_lse_ttl(&flow->mpls_lse[idx], ttl);
}
/* Sets the MPLS TC that 'flow' matches to 'tc', which should be in the
* range 0...7. */
void
flow_set_mpls_tc(struct flow *flow, int idx, uint8_t tc)
{
set_mpls_lse_tc(&flow->mpls_lse[idx], tc);
}
/* Sets the MPLS BOS bit that 'flow' matches to which should be 0 or 1. */
void
flow_set_mpls_bos(struct flow *flow, int idx, uint8_t bos)
{
set_mpls_lse_bos(&flow->mpls_lse[idx], bos);
}
/* Sets the entire MPLS LSE. */
void
flow_set_mpls_lse(struct flow *flow, int idx, ovs_be32 lse)
{
flow->mpls_lse[idx] = lse;
}
static void
flow_compose_l7(struct dp_packet *p, const void *l7, size_t l7_len)
{
if (l7_len) {
if (l7) {
dp_packet_put(p, l7, l7_len);
} else {
uint8_t *payload = dp_packet_put_uninit(p, l7_len);
for (size_t i = 0; i < l7_len; i++) {
payload[i] = i;
}
}
}
}
static size_t
flow_compose_l4(struct dp_packet *p, const struct flow *flow,
const void *l7, size_t l7_len)
{
size_t orig_len = dp_packet_size(p);
if (!(flow->nw_frag & FLOW_NW_FRAG_ANY)
|| !(flow->nw_frag & FLOW_NW_FRAG_LATER)) {
if (flow->nw_proto == IPPROTO_TCP) {
struct tcp_header *tcp = dp_packet_put_zeros(p, sizeof *tcp);
tcp->tcp_src = flow->tp_src;
tcp->tcp_dst = flow->tp_dst;
tcp->tcp_ctl = TCP_CTL(ntohs(flow->tcp_flags), 5);
if (!(flow->tcp_flags & htons(TCP_SYN | TCP_FIN | TCP_RST))) {
flow_compose_l7(p, l7, l7_len);
}
} else if (flow->nw_proto == IPPROTO_UDP) {
struct udp_header *udp = dp_packet_put_zeros(p, sizeof *udp);
udp->udp_src = flow->tp_src;
udp->udp_dst = flow->tp_dst;
udp->udp_len = htons(sizeof *udp + l7_len);
flow_compose_l7(p, l7, l7_len);
} else if (flow->nw_proto == IPPROTO_SCTP) {
struct sctp_header *sctp = dp_packet_put_zeros(p, sizeof *sctp);
sctp->sctp_src = flow->tp_src;
sctp->sctp_dst = flow->tp_dst;
/* XXX Someone should figure out what L7 data to include. */
} else if (flow->nw_proto == IPPROTO_ICMP) {
struct icmp_header *icmp = dp_packet_put_zeros(p, sizeof *icmp);
icmp->icmp_type = ntohs(flow->tp_src);
icmp->icmp_code = ntohs(flow->tp_dst);
if ((icmp->icmp_type == ICMP4_ECHO_REQUEST ||
icmp->icmp_type == ICMP4_ECHO_REPLY)
&& icmp->icmp_code == 0) {
flow_compose_l7(p, l7, l7_len);
} else {
/* XXX Add inner IP packet for e.g. destination unreachable? */
}
} else if (flow->nw_proto == IPPROTO_IGMP) {
struct igmp_header *igmp = dp_packet_put_zeros(p, sizeof *igmp);
igmp->igmp_type = ntohs(flow->tp_src);
igmp->igmp_code = ntohs(flow->tp_dst);
put_16aligned_be32(&igmp->group, flow->igmp_group_ip4);
} else if (flow->nw_proto == IPPROTO_ICMPV6) {
struct icmp6_data_header *icmp6;
icmp6 = dp_packet_put_zeros(p, sizeof *icmp6);
icmp6->icmp6_base.icmp6_type = ntohs(flow->tp_src);
icmp6->icmp6_base.icmp6_code = ntohs(flow->tp_dst);
put_16aligned_be32(icmp6->icmp6_data.be32, flow->igmp_group_ip4);
if (icmp6->icmp6_base.icmp6_code == 0 &&
(icmp6->icmp6_base.icmp6_type == ND_NEIGHBOR_SOLICIT ||
icmp6->icmp6_base.icmp6_type == ND_NEIGHBOR_ADVERT)) {
struct in6_addr *nd_target;
struct ovs_nd_lla_opt *lla_opt;
nd_target = dp_packet_put_zeros(p, sizeof *nd_target);
*nd_target = flow->nd_target;
if (!eth_addr_is_zero(flow->arp_sha)) {
lla_opt = dp_packet_put_zeros(p, 8);
lla_opt->len = 1;
lla_opt->type = ND_OPT_SOURCE_LINKADDR;
lla_opt->mac = flow->arp_sha;
}
if (!eth_addr_is_zero(flow->arp_tha)) {
lla_opt = dp_packet_put_zeros(p, 8);
lla_opt->len = 1;
lla_opt->type = ND_OPT_TARGET_LINKADDR;
lla_opt->mac = flow->arp_tha;
}
} else if (icmp6->icmp6_base.icmp6_code == 0 &&
(icmp6->icmp6_base.icmp6_type == ICMP6_ECHO_REQUEST ||
icmp6->icmp6_base.icmp6_type == ICMP6_ECHO_REPLY)) {
flow_compose_l7(p, l7, l7_len);
} else {
/* XXX Add inner IP packet for e.g. destination unreachable? */
}
}
}
return dp_packet_size(p) - orig_len;
}
static void
flow_compose_l4_csum(struct dp_packet *p, const struct flow *flow,
uint32_t pseudo_hdr_csum)
{
size_t l4_len = (char *) dp_packet_tail(p) - (char *) dp_packet_l4(p);
if (!(flow->nw_frag & FLOW_NW_FRAG_ANY)
|| !(flow->nw_frag & FLOW_NW_FRAG_LATER)) {
if (flow->nw_proto == IPPROTO_TCP) {
struct tcp_header *tcp = dp_packet_l4(p);
tcp->tcp_csum = 0;
tcp->tcp_csum = csum_finish(csum_continue(pseudo_hdr_csum,
tcp, l4_len));
dp_packet_l4_checksum_set_good(p);
} else if (flow->nw_proto == IPPROTO_UDP) {
struct udp_header *udp = dp_packet_l4(p);
udp->udp_csum = 0;
udp->udp_csum = csum_finish(csum_continue(pseudo_hdr_csum,
udp, l4_len));
if (!udp->udp_csum) {
udp->udp_csum = htons(0xffff);
}
dp_packet_l4_checksum_set_good(p);
} else if (flow->nw_proto == IPPROTO_ICMP) {
struct icmp_header *icmp = dp_packet_l4(p);
icmp->icmp_csum = 0;
icmp->icmp_csum = csum(icmp, l4_len);
} else if (flow->nw_proto == IPPROTO_IGMP) {
struct igmp_header *igmp = dp_packet_l4(p);
igmp->igmp_csum = 0;
igmp->igmp_csum = csum(igmp, l4_len);
} else if (flow->nw_proto == IPPROTO_ICMPV6) {
struct icmp6_data_header *icmp6 = dp_packet_l4(p);
icmp6->icmp6_base.icmp6_cksum = 0;
icmp6->icmp6_base.icmp6_cksum =
csum_finish(csum_continue(pseudo_hdr_csum, icmp6, l4_len));
}
}
}
/* Increase the size of packet composed by 'flow_compose_minimal'
* up to 'size' bytes. Fixes all the required packet headers like
* ip/udp lengths and l3/l4 checksums.
*
* 'size' needs to be larger then the current packet size. */
void
packet_expand(struct dp_packet *p, const struct flow *flow, size_t size)
{
size_t extra_size;
ovs_assert(size > dp_packet_size(p));
extra_size = size - dp_packet_size(p);
dp_packet_put_zeros(p, extra_size);
if (flow->dl_type == htons(FLOW_DL_TYPE_NONE)) {
struct eth_header *eth = dp_packet_eth(p);
eth->eth_type = htons(dp_packet_size(p));
} else if (dl_type_is_ip_any(flow->dl_type)) {
uint32_t pseudo_hdr_csum;
size_t l4_len = (char *) dp_packet_tail(p) - (char *) dp_packet_l4(p);
if (flow->dl_type == htons(ETH_TYPE_IP)) {
struct ip_header *ip = dp_packet_l3(p);
ip->ip_tot_len = htons(p->l4_ofs - p->l3_ofs + l4_len);
dp-packet: Rework IP checksum offloads. As the packet traverses through OVS, offloading Tx flags must be carefully evaluated and updated which results in a bit of complexity because of a separate "outer" Tx offloading flag coming from DPDK API, and a "normal"/"inner" Tx offloading flag. On the other hand, the DPDK mbuf API specifies 4 status when it comes to IP checksums: - RTE_MBUF_F_RX_IP_CKSUM_UNKNOWN: no information about the RX IP checksum - RTE_MBUF_F_RX_IP_CKSUM_BAD: the IP checksum in the packet is wrong - RTE_MBUF_F_RX_IP_CKSUM_GOOD: the IP checksum in the packet is valid - RTE_MBUF_F_RX_IP_CKSUM_NONE: the IP checksum is not correct in the packet data, but the integrity of the IP header is verified. This patch changes OVS API so that OVS code only tracks the status of the checksum of the "current" L3 header and let the Tx flags aspect to the netdev-* implementations. With this API, the flow extraction can be cleaned up. During packet processing, OVS can simply look for the IP checksum validity (either good, or partial) before changing some IP header, and then mark the checksum as partial. In the conntrack case, when natting packets, the checksum status of the inner part (ICMP error case) must be forced temporarily as unknown to force checksum resolution. When tunneling comes into play, IP checksums status is bit-shifted for future considerations in the processing if, for example, the tunnel header gets decapsulated again, or in the netdev-* implementations that support tunnel offloading. Finally, netdev-* implementations only need to care about packets in partial status: a good checksum does not need touching, a bad checksum has been updated by kept as bad by OVS, an unknown checksum is either an IPv6 or if it was an IPv4, OVS updated it too (keeping it good or bad accordingly). Rename current API for consistency with dp_packet_(inner_)?ip_checksum_. Signed-off-by: David Marchand <david.marchand@redhat.com> Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
2025-06-17 09:20:57 +02:00
dp_packet_ip_set_header_csum(p, false);
pseudo_hdr_csum = packet_csum_pseudoheader(ip);
} else { /* ETH_TYPE_IPV6 */
struct ovs_16aligned_ip6_hdr *nh = dp_packet_l3(p);
nh->ip6_plen = htons(l4_len);
pseudo_hdr_csum = packet_csum_pseudoheader6(nh);
}
if ((!(flow->nw_frag & FLOW_NW_FRAG_ANY)
|| !(flow->nw_frag & FLOW_NW_FRAG_LATER))
&& flow->nw_proto == IPPROTO_UDP) {
struct udp_header *udp = dp_packet_l4(p);
udp->udp_len = htons(l4_len + extra_size);
}
flow_compose_l4_csum(p, flow, pseudo_hdr_csum);
}
}
/* Puts into 'p' a packet that flow_extract() would parse as having the given
* 'flow'.
*
* (This is useful only for testing, obviously, and the packet isn't really
* valid. Lots of fields are just zeroed.)
*
* If 'bad_csum' is true, the final IP checksum is invalid.
*
* For packets whose protocols can encapsulate arbitrary L7 payloads, 'l7' and
* 'l7_len' determine that payload:
*
* - If 'l7_len' is zero, no payload is included.
*
* - If 'l7_len' is nonzero and 'l7' is null, an arbitrary payload 'l7_len'
* bytes long is included.
*
* - If 'l7_len' is nonzero and 'l7' is nonnull, the payload is copied
* from 'l7'. */
void
flow_compose(struct dp_packet *p, const struct flow *flow,
const void *l7, size_t l7_len, bool bad_csum)
{
/* Add code to this function (or its callees) for emitting new fields or
* protocols. (This isn't essential, so it can be skipped for initial
* testing.) */
BUILD_ASSERT_DECL(FLOW_WC_SEQ == 42);
uint32_t pseudo_hdr_csum;
size_t l4_len;
/* eth_compose() sets l3 pointer and makes sure it is 32-bit aligned. */
eth_compose(p, flow->dl_dst, flow->dl_src, ntohs(flow->dl_type), 0);
if (flow->dl_type == htons(FLOW_DL_TYPE_NONE)) {
userspace: Add packet_type in dp_packet and flow This commit adds a packet_type attribute to the structs dp_packet and flow to explicitly carry the type of the packet as prepration for the introduction of the so-called packet type-aware pipeline (PTAP) in OVS. The packet_type is a big-endian 32 bit integer with the encoding as specified in OpenFlow verion 1.5. The upper 16 bits contain the packet type name space. Pre-defined values are defined in openflow-common.h: enum ofp_header_type_namespaces { OFPHTN_ONF = 0, /* ONF namespace. */ OFPHTN_ETHERTYPE = 1, /* ns_type is an Ethertype. */ OFPHTN_IP_PROTO = 2, /* ns_type is a IP protocol number. */ OFPHTN_UDP_TCP_PORT = 3, /* ns_type is a TCP or UDP port. */ OFPHTN_IPV4_OPTION = 4, /* ns_type is an IPv4 option number. */ }; The lower 16 bits specify the actual type in the context of the name space. Only name spaces 0 and 1 will be supported for now. For name space OFPHTN_ONF the relevant packet type is 0 (Ethernet). This is the default packet_type in OVS and the only one supported so far. Packets of type (OFPHTN_ONF, 0) are called Ethernet packets. In name space OFPHTN_ETHERTYPE the type is the Ethertype of the packet. A packet of type (OFPHTN_ETHERTYPE, <Ethertype>) is a standard L2 packet whith the Ethernet header (and any VLAN tags) removed to expose the L3 (or L2.5) payload of the packet. These will simply be called L3 packets. The Ethernet address fields dl_src and dl_dst in struct flow are not applicable for an L3 packet and must be zero. However, to maintain compatibility with the large code base, we have chosen to copy the Ethertype of an L3 packet into the the dl_type field of struct flow. This does not mean that it will be possible to match on dl_type for L3 packets with PTAP later on. Matching must be done on packet_type instead. New dp_packets are initialized with packet_type Ethernet. Ports that receive L3 packets will have to explicitly adjust the packet_type. Signed-off-by: Jean Tourrilhes <jt@labs.hpe.com> Signed-off-by: Jan Scheurich <jan.scheurich@ericsson.com> Co-authored-by: Zoltan Balogh <zoltan.balogh@ericsson.com> Signed-off-by: Ben Pfaff <blp@ovn.org>
2017-04-25 16:29:59 +00:00
struct eth_header *eth = dp_packet_eth(p);
eth->eth_type = htons(dp_packet_size(p));
return;
}
for (int encaps = FLOW_MAX_VLAN_HEADERS - 1; encaps >= 0; encaps--) {
if (flow->vlans[encaps].tci & htons(VLAN_CFI)) {
eth_push_vlan(p, flow->vlans[encaps].tpid,
flow->vlans[encaps].tci);
}
}
if (flow->dl_type == htons(ETH_TYPE_IP)) {
struct ip_header *ip;
ip = dp_packet_put_zeros(p, sizeof *ip);
ip->ip_ihl_ver = IP_IHL_VER(5, 4);
ip->ip_tos = flow->nw_tos;
ip->ip_ttl = flow->nw_ttl;
ip->ip_proto = flow->nw_proto;
packets: Do not assume that IPv4, TCP, or ARP headers are 32-bit aligned. Ethernet headers are 14 bytes long, so when the beginning of such a header is 32-bit aligned, the following data is misaligned. The usual trick to fix that is to start the Ethernet header on an odd-numbered 16-bit boundary. That trick works OK for Open vSwitch, but there are two problems: - OVS doesn't use that trick everywhere. Maybe it should, but it's difficult to make sure that it does consistently because the CPUs most commonly used with OVS don't care about misalignment, so we only find problems when porting. - Some protocols (GRE, VXLAN) don't use that trick, so in such a case one can properly align the inner or outer L3/L4/L7 but not both. (OVS userspace doesn't directly deal with such protocols yet, so this is just future-proofing.) - OpenFlow uses the alignment trick in a few places but not all of them. This commit starts the adoption of what I hope will be a more robust way to avoid misalignment problems and the resulting bus errors on RISC architectures. Instead of trying to ensure that 32-bit quantities are always aligned, we always read them as if they were misaligned. To ensure that they are read this way, we change their types from 32-bit types to pairs of 16-bit types. (I don't know of any protocols that offset the next header by an odd number of bytes, so a 16-bit alignment assumption seems OK.) The same would be necessary for 64-bit types in protocol headers, but we don't yet have any protocol definitions with 64-bit types. IPv6 protocol headers need the same treatment, but for those we rely on structs provided by system headers, so I'll leave them for an upcoming patch. Signed-off-by: Ben Pfaff <blp@nicira.com>
2013-08-15 10:47:39 -07:00
put_16aligned_be32(&ip->ip_src, flow->nw_src);
put_16aligned_be32(&ip->ip_dst, flow->nw_dst);
if (flow->nw_frag & FLOW_NW_FRAG_ANY) {
Implement new fragment handling policy. Until now, OVS has handled IP fragments more awkwardly than necessary. It has not been possible to match on L4 headers, even in fragments with offset 0 where they are actually present. This means that there was no way to implement ACLs that treat, say, different TCP ports differently, on fragmented traffic; instead, all decisions for fragment forwarding had to be made on the basis of L2 and L3 headers alone. This commit improves the situation significantly. It is still not possible to match on L4 headers in fragments with nonzero offset, because that information is simply not present in such fragments, but this commit adds the ability to match on L4 headers for fragments with zero offset. This means that it becomes possible to implement ACLs that drop such "first fragments" on the basis of L4 headers. In practice, that effectively blocks even fragmented traffic on an L4 basis, because the receiving IP stack cannot reassemble a full packet when the first fragment is missing. This commit works by adding a new "fragment type" to the kernel flow match and making it available through OpenFlow as a new NXM field named NXM_NX_IP_FRAG. Because OpenFlow 1.0 explicitly says that the L4 fields are always 0 for IP fragments, it adds a new OpenFlow fragment handling mode that fills in the L4 fields for "first fragments". It also enhances ovs-ofctl to allow users to configure this new fragment handling mode and to parse the new field. Signed-off-by: Ben Pfaff <blp@nicira.com> Bug #7557.
2011-10-19 21:33:44 -07:00
ip->ip_frag_off |= htons(IP_MORE_FRAGMENTS);
if (flow->nw_frag & FLOW_NW_FRAG_LATER) {
Implement new fragment handling policy. Until now, OVS has handled IP fragments more awkwardly than necessary. It has not been possible to match on L4 headers, even in fragments with offset 0 where they are actually present. This means that there was no way to implement ACLs that treat, say, different TCP ports differently, on fragmented traffic; instead, all decisions for fragment forwarding had to be made on the basis of L2 and L3 headers alone. This commit improves the situation significantly. It is still not possible to match on L4 headers in fragments with nonzero offset, because that information is simply not present in such fragments, but this commit adds the ability to match on L4 headers for fragments with zero offset. This means that it becomes possible to implement ACLs that drop such "first fragments" on the basis of L4 headers. In practice, that effectively blocks even fragmented traffic on an L4 basis, because the receiving IP stack cannot reassemble a full packet when the first fragment is missing. This commit works by adding a new "fragment type" to the kernel flow match and making it available through OpenFlow as a new NXM field named NXM_NX_IP_FRAG. Because OpenFlow 1.0 explicitly says that the L4 fields are always 0 for IP fragments, it adds a new OpenFlow fragment handling mode that fills in the L4 fields for "first fragments". It also enhances ovs-ofctl to allow users to configure this new fragment handling mode and to parse the new field. Signed-off-by: Ben Pfaff <blp@nicira.com> Bug #7557.
2011-10-19 21:33:44 -07:00
ip->ip_frag_off |= htons(100);
}
}
dp_packet_set_l4(p, dp_packet_tail(p));
l4_len = flow_compose_l4(p, flow, l7, l7_len);
ip = dp_packet_l3(p);
ip->ip_tot_len = htons(p->l4_ofs - p->l3_ofs + l4_len);
/* Checksum has already been zeroed by put_zeros call. */
ip->ip_csum = csum(ip, sizeof *ip);
if (bad_csum) {
/*
* Internet checksum is a sum complement to zero, so any other
* value will result in an invalid checksum. Here, we flip one
* bit.
*/
ip->ip_csum ^= (OVS_FORCE ovs_be16) 0x1;
dp-packet: Rework IP checksum offloads. As the packet traverses through OVS, offloading Tx flags must be carefully evaluated and updated which results in a bit of complexity because of a separate "outer" Tx offloading flag coming from DPDK API, and a "normal"/"inner" Tx offloading flag. On the other hand, the DPDK mbuf API specifies 4 status when it comes to IP checksums: - RTE_MBUF_F_RX_IP_CKSUM_UNKNOWN: no information about the RX IP checksum - RTE_MBUF_F_RX_IP_CKSUM_BAD: the IP checksum in the packet is wrong - RTE_MBUF_F_RX_IP_CKSUM_GOOD: the IP checksum in the packet is valid - RTE_MBUF_F_RX_IP_CKSUM_NONE: the IP checksum is not correct in the packet data, but the integrity of the IP header is verified. This patch changes OVS API so that OVS code only tracks the status of the checksum of the "current" L3 header and let the Tx flags aspect to the netdev-* implementations. With this API, the flow extraction can be cleaned up. During packet processing, OVS can simply look for the IP checksum validity (either good, or partial) before changing some IP header, and then mark the checksum as partial. In the conntrack case, when natting packets, the checksum status of the inner part (ICMP error case) must be forced temporarily as unknown to force checksum resolution. When tunneling comes into play, IP checksums status is bit-shifted for future considerations in the processing if, for example, the tunnel header gets decapsulated again, or in the netdev-* implementations that support tunnel offloading. Finally, netdev-* implementations only need to care about packets in partial status: a good checksum does not need touching, a bad checksum has been updated by kept as bad by OVS, an unknown checksum is either an IPv6 or if it was an IPv4, OVS updated it too (keeping it good or bad accordingly). Rename current API for consistency with dp_packet_(inner_)?ip_checksum_. Signed-off-by: David Marchand <david.marchand@redhat.com> Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
2025-06-17 09:20:57 +02:00
dp_packet_ip_checksum_set_bad(p);
} else {
dp-packet: Rework IP checksum offloads. As the packet traverses through OVS, offloading Tx flags must be carefully evaluated and updated which results in a bit of complexity because of a separate "outer" Tx offloading flag coming from DPDK API, and a "normal"/"inner" Tx offloading flag. On the other hand, the DPDK mbuf API specifies 4 status when it comes to IP checksums: - RTE_MBUF_F_RX_IP_CKSUM_UNKNOWN: no information about the RX IP checksum - RTE_MBUF_F_RX_IP_CKSUM_BAD: the IP checksum in the packet is wrong - RTE_MBUF_F_RX_IP_CKSUM_GOOD: the IP checksum in the packet is valid - RTE_MBUF_F_RX_IP_CKSUM_NONE: the IP checksum is not correct in the packet data, but the integrity of the IP header is verified. This patch changes OVS API so that OVS code only tracks the status of the checksum of the "current" L3 header and let the Tx flags aspect to the netdev-* implementations. With this API, the flow extraction can be cleaned up. During packet processing, OVS can simply look for the IP checksum validity (either good, or partial) before changing some IP header, and then mark the checksum as partial. In the conntrack case, when natting packets, the checksum status of the inner part (ICMP error case) must be forced temporarily as unknown to force checksum resolution. When tunneling comes into play, IP checksums status is bit-shifted for future considerations in the processing if, for example, the tunnel header gets decapsulated again, or in the netdev-* implementations that support tunnel offloading. Finally, netdev-* implementations only need to care about packets in partial status: a good checksum does not need touching, a bad checksum has been updated by kept as bad by OVS, an unknown checksum is either an IPv6 or if it was an IPv4, OVS updated it too (keeping it good or bad accordingly). Rename current API for consistency with dp_packet_(inner_)?ip_checksum_. Signed-off-by: David Marchand <david.marchand@redhat.com> Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
2025-06-17 09:20:57 +02:00
dp_packet_ip_checksum_set_good(p);
}
pseudo_hdr_csum = packet_csum_pseudoheader(ip);
flow_compose_l4_csum(p, flow, pseudo_hdr_csum);
} else if (flow->dl_type == htons(ETH_TYPE_IPV6)) {
struct ovs_16aligned_ip6_hdr *nh;
nh = dp_packet_put_zeros(p, sizeof *nh);
put_16aligned_be32(&nh->ip6_flow, htonl(6 << 28) |
htonl(flow->nw_tos << 20) | flow->ipv6_label);
nh->ip6_hlim = flow->nw_ttl;
nh->ip6_nxt = flow->nw_proto;
memcpy(&nh->ip6_src, &flow->ipv6_src, sizeof(nh->ip6_src));
memcpy(&nh->ip6_dst, &flow->ipv6_dst, sizeof(nh->ip6_dst));
dp_packet_set_l4(p, dp_packet_tail(p));
l4_len = flow_compose_l4(p, flow, l7, l7_len);
nh = dp_packet_l3(p);
nh->ip6_plen = htons(l4_len);
pseudo_hdr_csum = packet_csum_pseudoheader6(nh);
flow_compose_l4_csum(p, flow, pseudo_hdr_csum);
} else if (flow->dl_type == htons(ETH_TYPE_ARP) ||
flow->dl_type == htons(ETH_TYPE_RARP)) {
struct arp_eth_header *arp;
arp = dp_packet_put_zeros(p, sizeof *arp);
dp_packet_set_l3(p, arp);
arp->ar_hrd = htons(1);
arp->ar_pro = htons(ETH_TYPE_IP);
arp->ar_hln = ETH_ADDR_LEN;
arp->ar_pln = 4;
arp->ar_op = htons(flow->nw_proto);
if (flow->nw_proto == ARP_OP_REQUEST ||
flow->nw_proto == ARP_OP_REPLY) {
packets: Do not assume that IPv4, TCP, or ARP headers are 32-bit aligned. Ethernet headers are 14 bytes long, so when the beginning of such a header is 32-bit aligned, the following data is misaligned. The usual trick to fix that is to start the Ethernet header on an odd-numbered 16-bit boundary. That trick works OK for Open vSwitch, but there are two problems: - OVS doesn't use that trick everywhere. Maybe it should, but it's difficult to make sure that it does consistently because the CPUs most commonly used with OVS don't care about misalignment, so we only find problems when porting. - Some protocols (GRE, VXLAN) don't use that trick, so in such a case one can properly align the inner or outer L3/L4/L7 but not both. (OVS userspace doesn't directly deal with such protocols yet, so this is just future-proofing.) - OpenFlow uses the alignment trick in a few places but not all of them. This commit starts the adoption of what I hope will be a more robust way to avoid misalignment problems and the resulting bus errors on RISC architectures. Instead of trying to ensure that 32-bit quantities are always aligned, we always read them as if they were misaligned. To ensure that they are read this way, we change their types from 32-bit types to pairs of 16-bit types. (I don't know of any protocols that offset the next header by an odd number of bytes, so a 16-bit alignment assumption seems OK.) The same would be necessary for 64-bit types in protocol headers, but we don't yet have any protocol definitions with 64-bit types. IPv6 protocol headers need the same treatment, but for those we rely on structs provided by system headers, so I'll leave them for an upcoming patch. Signed-off-by: Ben Pfaff <blp@nicira.com>
2013-08-15 10:47:39 -07:00
put_16aligned_be32(&arp->ar_spa, flow->nw_src);
put_16aligned_be32(&arp->ar_tpa, flow->nw_dst);
arp->ar_sha = flow->arp_sha;
arp->ar_tha = flow->arp_tha;
}
} else if (flow->dl_type == htons(ETH_TYPE_NSH)) {
struct nsh_hdr *nsh;
nsh = dp_packet_put_zeros(p, sizeof *nsh);
dp_packet_set_l3(p, nsh);
nsh_set_flags_ttl_len(nsh, flow->nsh.flags, flow->nsh.ttl,
flow->nsh.mdtype == NSH_M_TYPE1
? NSH_M_TYPE1_LEN : NSH_BASE_HDR_LEN);
nsh->next_proto = flow->nsh.np;
nsh->md_type = flow->nsh.mdtype;
put_16aligned_be32(&nsh->path_hdr, flow->nsh.path_hdr);
if (flow->nsh.mdtype == NSH_M_TYPE1) {
for (size_t i = 0; i < 4; i++) {
put_16aligned_be32(&nsh->md1.context[i], flow->nsh.context[i]);
}
}
}
if (eth_type_mpls(flow->dl_type)) {
int n;
p->l2_5_ofs = p->l3_ofs;
for (n = 1; n < FLOW_MAX_MPLS_LABELS; n++) {
if (flow->mpls_lse[n - 1] & htonl(MPLS_BOS_MASK)) {
break;
}
}
while (n > 0) {
push_mpls(p, flow->dl_type, flow->mpls_lse[--n]);
}
}
}
/* Compressed flow. */
/* Completes an initialization of 'dst' as a miniflow copy of 'src' begun by
* the caller. The caller must have already computed 'dst->map' properly to
* indicate the significant uint64_t elements of 'src'.
Classifier: Track address prefixes. Add a prefix tree (trie) structure for tracking the used address space, enabling skipping classifier tables containing longer masks than necessary for an address field value in a packet header being classified. This enables less unwildcarding for datapath flows in parts of the address space without host routes. Trie lookup is interwoven to the staged lookup, so that a trie is searched only when the configured trie field becomes relevant for the lookup. The trie lookup results are retained so that each trie is checked at most once for each classifier lookup. This implementation tracks the number of rules at each address prefix for the whole classifier. More aggressive table skipping would be possible by maintaining lists of tables that have prefixes at the lengths encountered on tree traversal, or by maintaining separate tries for subsets of rules separated by metadata fields. Prefix tracking is configured via OVSDB. A new column "prefixes" is added to the database table "Flow_Table". "prefixes" is a set of string values listing the field names for which prefix lookup should be used. As of now, the fields for which prefix lookup can be enabled are: - tun_id, tun_src, tun_dst - nw_src, nw_dst (or aliases ip_src and ip_dst) - ipv6_src, ipv6_dst There is a maximum number of fields that can be enabled for any one flow table. Currently this limit is 3. Examples: ovs-vsctl set Bridge br0 flow_tables:0=@N1 -- \ --id=@N1 create Flow_Table name=table0 ovs-vsctl set Bridge br0 flow_tables:1=@N1 -- \ --id=@N1 create Flow_Table name=table1 ovs-vsctl set Flow_Table table0 prefixes=ip_dst,ip_src ovs-vsctl set Flow_Table table1 prefixes=[] Signed-off-by: Jarno Rajahalme <jrajahalme@nicira.com> Acked-by: Ben Pfaff <blp@nicira.com>
2013-12-11 11:07:01 -08:00
*
* Normally the significant elements are the ones that are non-zero. However,
* when a miniflow is initialized from a (mini)mask, the values can be zeroes,
* so that the flow and mask always have the same maps. */
void
miniflow_init(struct miniflow *dst, const struct flow *src)
{
uint64_t *dst_u64 = miniflow_values(dst);
size_t idx;
FLOWMAP_FOR_EACH_INDEX(idx, dst->map) {
*dst_u64++ = flow_u64_value(src, idx);
}
}
/* Initialize the maps of 'flow' from 'src'. */
void
miniflow_map_init(struct miniflow *flow, const struct flow *src)
{
/* Initialize map, counting the number of nonzero elements. */
flowmap_init(&flow->map);
for (size_t i = 0; i < FLOW_U64S; i++) {
if (flow_u64_value(src, i)) {
flowmap_set(&flow->map, i, 1);
}
}
}
/* Allocates 'n' count of miniflows, consecutive in memory, initializing the
* map of each from 'src'.
* Returns the size of the miniflow data. */
size_t
miniflow_alloc(struct miniflow *dsts[], size_t n, const struct miniflow *src)
{
size_t n_values = miniflow_n_values(src);
size_t data_size = MINIFLOW_VALUES_SIZE(n_values);
struct miniflow *dst = xmalloc(n * (sizeof *src + data_size));
size_t i;
COVERAGE_INC(miniflow_malloc);
for (i = 0; i < n; i++) {
*dst = *src; /* Copy maps. */
dsts[i] = dst;
dst += 1; /* Just past the maps. */
dst = (struct miniflow *)((uint64_t *)dst + n_values); /* Skip data. */
}
return data_size;
}
/* Returns a miniflow copy of 'src'. The caller must eventually free() the
* returned miniflow. */
struct miniflow *
miniflow_create(const struct flow *src)
{
struct miniflow tmp;
struct miniflow *dst;
miniflow_map_init(&tmp, src);
miniflow_alloc(&dst, 1, &tmp);
miniflow_init(dst, src);
return dst;
}
/* Initializes 'dst' as a copy of 'src'. The caller must have allocated
* 'dst' to have inline space for 'n_values' data in 'src'. */
void
miniflow_clone(struct miniflow *dst, const struct miniflow *src,
size_t n_values)
{
*dst = *src; /* Copy maps. */
memcpy(miniflow_values(dst), miniflow_get_values(src),
MINIFLOW_VALUES_SIZE(n_values));
}
/* Initializes 'dst' as a copy of 'src'. */
void
miniflow_expand(const struct miniflow *src, struct flow *dst)
{
memset(dst, 0, sizeof *dst);
flow_union_with_miniflow(dst, src);
}
/* Returns true if 'a' and 'b' are equal miniflows, false otherwise. */
bool
miniflow_equal(const struct miniflow *a, const struct miniflow *b)
{
const uint64_t *ap = miniflow_get_values(a);
const uint64_t *bp = miniflow_get_values(b);
/* This is mostly called after a matching hash, so it is highly likely that
* the maps are equal as well. */
if (OVS_LIKELY(flowmap_equal(a->map, b->map))) {
return !memcmp(ap, bp, miniflow_n_values(a) * sizeof *ap);
} else {
size_t idx;
FLOWMAP_FOR_EACH_INDEX (idx, flowmap_or(a->map, b->map)) {
if ((flowmap_is_set(&a->map, idx) ? *ap++ : 0)
!= (flowmap_is_set(&b->map, idx) ? *bp++ : 0)) {
return false;
}
}
}
return true;
}
/* Returns false if 'a' and 'b' differ at the places where there are 1-bits
* in 'mask', true otherwise. */
bool
miniflow_equal_in_minimask(const struct miniflow *a, const struct miniflow *b,
const struct minimask *mask)
{
const uint64_t *p = miniflow_get_values(&mask->masks);
size_t idx;
FLOWMAP_FOR_EACH_INDEX(idx, mask->masks.map) {
if ((miniflow_get(a, idx) ^ miniflow_get(b, idx)) & *p++) {
return false;
}
}
return true;
}
/* Returns true if 'a' and 'b' are equal at the places where there are 1-bits
* in 'mask', false if they differ. */
bool
miniflow_equal_flow_in_minimask(const struct miniflow *a, const struct flow *b,
const struct minimask *mask)
{
const uint64_t *p = miniflow_get_values(&mask->masks);
size_t idx;
FLOWMAP_FOR_EACH_INDEX(idx, mask->masks.map) {
if ((miniflow_get(a, idx) ^ flow_u64_value(b, idx)) & *p++) {
return false;
}
}
return true;
}
void
minimask_init(struct minimask *mask, const struct flow_wildcards *wc)
{
miniflow_init(&mask->masks, &wc->masks);
}
/* Returns a minimask copy of 'wc'. The caller must eventually free the
* returned minimask with free(). */
struct minimask *
minimask_create(const struct flow_wildcards *wc)
{
return (struct minimask *)miniflow_create(&wc->masks);
}
/* Initializes 'dst_' as the bit-wise "and" of 'a_' and 'b_'.
*
* The caller must provide room for FLOW_U64S "uint64_t"s in 'storage', which
* must follow '*dst_' in memory, for use by 'dst_'. The caller must *not*
* free 'dst_' free(). */
void
minimask_combine(struct minimask *dst_,
const struct minimask *a_, const struct minimask *b_,
uint64_t storage[FLOW_U64S])
{
struct miniflow *dst = &dst_->masks;
uint64_t *dst_values = storage;
const struct miniflow *a = &a_->masks;
const struct miniflow *b = &b_->masks;
size_t idx;
flowmap_init(&dst->map);
FLOWMAP_FOR_EACH_INDEX(idx, flowmap_and(a->map, b->map)) {
/* Both 'a' and 'b' have non-zero data at 'idx'. */
uint64_t mask = *miniflow_get__(a, idx) & *miniflow_get__(b, idx);
if (mask) {
flowmap_set(&dst->map, idx, 1);
*dst_values++ = mask;
}
}
}
/* Initializes 'wc' as a copy of 'mask'. */
void
minimask_expand(const struct minimask *mask, struct flow_wildcards *wc)
{
miniflow_expand(&mask->masks, &wc->masks);
}
/* Returns true if 'a' and 'b' are the same flow mask, false otherwise.
* Minimasks may not have zero data values, so for the minimasks to be the
* same, they need to have the same map and the same data values. */
bool
minimask_equal(const struct minimask *a, const struct minimask *b)
{
flow: Avoid unsafe comparison of minimasks. The following, run inside the OVS sandbox, caused OVS to abort when Address Sanitizer was used: ovs-vsctl add-br br-int ovs-ofctl add-flow br-int "table=0,cookie=0x1234,priority=10000,icmp,actions=drop" ovs-ofctl --strict del-flows br-int "table=0,cookie=0x1234/-1,priority=10000" Sample report from Address Sanitizer: ==3029==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x603000043260 at pc 0x7f6b09c2459b bp 0x7ffcb67e7540 sp 0x7ffcb67e6cf0 READ of size 40 at 0x603000043260 thread T0 #0 0x7f6b09c2459a (/lib/x86_64-linux-gnu/libasan.so.5+0xb859a) #1 0x565110a748a5 in minimask_equal ../lib/flow.c:3510 #2 0x565110a9ea41 in minimatch_equal ../lib/match.c:1821 #3 0x56511091e864 in collect_rules_strict ../ofproto/ofproto.c:4516 #4 0x56511093d526 in delete_flow_start_strict ../ofproto/ofproto.c:5959 #5 0x56511093d526 in ofproto_flow_mod_start ../ofproto/ofproto.c:7949 #6 0x56511093d77b in handle_flow_mod__ ../ofproto/ofproto.c:6122 #7 0x56511093db71 in handle_flow_mod ../ofproto/ofproto.c:6099 #8 0x5651109407f6 in handle_single_part_openflow ../ofproto/ofproto.c:8406 #9 0x5651109407f6 in handle_openflow ../ofproto/ofproto.c:8587 #10 0x5651109e40da in ofconn_run ../ofproto/connmgr.c:1318 #11 0x5651109e40da in connmgr_run ../ofproto/connmgr.c:355 #12 0x56511092b129 in ofproto_run ../ofproto/ofproto.c:1826 #13 0x5651108f23cd in bridge_run__ ../vswitchd/bridge.c:2965 #14 0x565110904887 in bridge_run ../vswitchd/bridge.c:3023 #15 0x5651108e659c in main ../vswitchd/ovs-vswitchd.c:127 #16 0x7f6b093b709a in __libc_start_main ../csu/libc-start.c:308 #17 0x5651108e9009 in _start (/home/blp/nicira/ovs/_build/vswitchd/ovs-vswitchd+0x11d009) This fixes the problem, which although largely theoretical could crop up with odd implementations of memcmp(), perhaps ones optimized in various "clever" ways. All in all, it seems best to avoid the theoretical problem. Acked-by: Dumitru Ceara <dceara@redhat.com> Signed-off-by: Ben Pfaff <blp@ovn.org>
2019-07-17 10:55:16 -07:00
/* At first glance, it might seem that this can be reasonably optimized
* into a single memcmp() for the total size of the region. Such an
* optimization will work OK with most implementations of memcmp() that
* proceed from the start of the regions to be compared to the end in
* reasonably sized chunks. However, memcmp() is not required to be
* implemented that way, and an implementation that, for example, compares
* all of the bytes in both regions without early exit when it finds a
* difference, or one that compares, say, 64 bytes at a time, could access
* an unmapped region of memory if minimasks 'a' and 'b' have different
* lengths. By first checking that the maps are the same with the first
* memcmp(), we verify that 'a' and 'b' have the same length and therefore
* ensure that the second memcmp() is safe. */
return (!memcmp(a, b, sizeof *a)
&& !memcmp(a + 1, b + 1,
MINIFLOW_VALUES_SIZE(miniflow_n_values(&a->masks))));
}
/* Returns true if at least one bit matched by 'b' is wildcarded by 'a',
* false otherwise. */
bool
minimask_has_extra(const struct minimask *a, const struct minimask *b)
{
const uint64_t *bp = miniflow_get_values(&b->masks);
size_t idx;
FLOWMAP_FOR_EACH_INDEX(idx, b->masks.map) {
uint64_t b_u64 = *bp++;
/* 'b_u64' is non-zero, check if the data in 'a' is either zero
* or misses some of the bits in 'b_u64'. */
if (!MINIFLOW_IN_MAP(&a->masks, idx)
|| ((*miniflow_get__(&a->masks, idx) & b_u64) != b_u64)) {
return true; /* 'a' wildcards some bits 'b' doesn't. */
}
}
return false;
}
void
flow_limit_vlans(int vlan_limit)
{
if (vlan_limit <= 0) {
flow_vlan_limit = FLOW_MAX_VLAN_HEADERS;
} else {
flow_vlan_limit = MIN(vlan_limit, FLOW_MAX_VLAN_HEADERS);
}
}
struct netdev *
flow_get_tunnel_netdev(struct flow_tnl *tunnel)
{
char iface[IFNAMSIZ];
struct in6_addr ip6;
struct in6_addr gw;
if (tunnel->ip_src) {
in6_addr_set_mapped_ipv4(&ip6, tunnel->ip_src);
} else if (ipv6_addr_is_set(&tunnel->ipv6_src)) {
ip6 = tunnel->ipv6_src;
} else {
return NULL;
}
if (!ovs_router_lookup(0, &ip6, iface, NULL, &gw)) {
return NULL;
}
return netdev_from_name(iface);
}