2015-08-12 14:01:28 -07:00
|
|
|
# _ADD_BR([name])
|
2015-08-07 19:40:36 +01:00
|
|
|
#
|
|
|
|
|
# Expands into the proper ovs-vsctl commands to create a bridge with the
|
2015-11-24 13:33:22 -08:00
|
|
|
# appropriate type and properties
|
|
|
|
|
m4_define([_ADD_BR], [[add-br $1 -- set Bridge $1 datapath_type="netdev" protocols=OpenFlow10,OpenFlow11,OpenFlow12,OpenFlow13,OpenFlow14,OpenFlow15 fail-mode=secure ]])
|
2015-08-07 19:40:36 +01:00
|
|
|
|
2022-07-13 10:21:12 +02:00
|
|
|
# OVS_TRAFFIC_VSWITCHD_START([vsctl-args], [vsctl-output], [dbinit-aux-args])
|
2015-08-07 19:40:36 +01:00
|
|
|
#
|
|
|
|
|
# Creates a database and starts ovsdb-server, starts ovs-vswitchd
|
|
|
|
|
# connected to that database, calls ovs-vsctl to create a bridge named
|
|
|
|
|
# br0 with predictable settings, passing 'vsctl-args' as additional
|
|
|
|
|
# commands to ovs-vsctl. If 'vsctl-args' causes ovs-vsctl to provide
|
|
|
|
|
# output (e.g. because it includes "create" commands) then 'vsctl-output'
|
2017-11-26 16:07:39 -08:00
|
|
|
# specifies the expected output after filtering through uuidfilt.
|
2022-07-13 10:21:12 +02:00
|
|
|
# 'dbinit-aux-args' are passed as additional commands to 'ovs-vsctl init'
|
|
|
|
|
# before starting ovs-vswitchd.
|
2015-08-07 19:40:36 +01:00
|
|
|
m4_define([OVS_TRAFFIC_VSWITCHD_START],
|
|
|
|
|
[
|
2016-03-04 08:31:57 +03:00
|
|
|
OVS_WAIT_WHILE([ip link show ovs-netdev])
|
2022-07-13 10:21:12 +02:00
|
|
|
_OVS_VSWITCHD_START([--disable-system], [$3])
|
2015-08-07 19:40:36 +01:00
|
|
|
dnl Add bridges, ports, etc.
|
2016-03-04 08:31:57 +03:00
|
|
|
OVS_WAIT_WHILE([ip link show br0])
|
2017-11-26 16:07:39 -08:00
|
|
|
AT_CHECK([ovs-vsctl -- _ADD_BR([br0]) -- $1 m4_if([$2], [], [], [| uuidfilt])], [0], [$2])
|
2015-08-07 19:40:36 +01:00
|
|
|
])
|
|
|
|
|
|
2020-06-17 14:22:47 -07:00
|
|
|
# OVS_TRAFFIC_VSWITCHD_STOP([ALLOWLIST], [extra_cmds])
|
2015-08-07 19:40:36 +01:00
|
|
|
#
|
|
|
|
|
# Gracefully stops ovs-vswitchd and ovsdb-server, checking their log files
|
|
|
|
|
# for messages with severity WARN or higher and signaling an error if any
|
2020-06-17 14:22:47 -07:00
|
|
|
# is present. The optional ALLOWLIST may contain shell-quoted "sed"
|
2015-08-07 19:40:36 +01:00
|
|
|
# commands to delete any warnings that are actually expected, e.g.:
|
|
|
|
|
#
|
|
|
|
|
# OVS_TRAFFIC_VSWITCHD_STOP(["/expected error/d"])
|
|
|
|
|
#
|
2020-06-17 14:22:47 -07:00
|
|
|
# 'extra_cmds' are shell commands to be executed after OVS_VSWITCHD_STOP() is
|
2015-08-07 19:40:36 +01:00
|
|
|
# invoked. They can be used to perform additional cleanups such as name space
|
|
|
|
|
# removal.
|
|
|
|
|
m4_define([OVS_TRAFFIC_VSWITCHD_STOP],
|
2015-08-12 14:01:29 -07:00
|
|
|
[OVS_VSWITCHD_STOP([dnl
|
2016-09-23 15:16:23 -04:00
|
|
|
$1";/netdev_linux.*obtaining netdev stats via vport failed/d
|
2019-06-25 14:52:38 -07:00
|
|
|
/dpif_netlink.*Generic Netlink family 'ovs_datapath' does not exist. The Open vSwitch kernel module is probably not loaded./d
|
|
|
|
|
/dpif_netdev(revalidator.*)|ERR|internal error parsing flow key.*proto=2.*/d
|
|
|
|
|
/dpif(revalidator.*)|WARN|netdev@ovs-netdev: failed to.*proto=2.*/d"])
|
2015-08-07 19:40:36 +01:00
|
|
|
AT_CHECK([:; $2])
|
|
|
|
|
])
|
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
|
|
|
|
system-tests: Disable offloads in userspace tests.
The system userspace testsuite uses the userspace datapath with
netdev-linux devices, connected to veth pairs with the AF_PACKET socket:
(veth pair) (AF_PACKET)
TCP stack -> p0 ---> ovs-p0 -------------> netdev-linux (userspace OVS)
Unfortunately this configuration has some problems with offloads: a
packet generated by the TCP stack maybe sent to p0 without being
checksummed or segmented. The AF_PACKET socket, by default, ignores the
offloads and just transmits the data of the packets to userspace, but:
1. The packet may need GSO, so the data will be too big to be received
by the userspace datapath
2. The packet might have incomplete checksums, so it will likely be
discarded by the receiver.
Problem 1 causes TCP connections to see a congestion window smaller than
the MTU, which hurts performance but doesn't prevent communication.
Problem 2 was hidden in the testsuite by a Linux kernel bug, fixed by
commit ce8c839b74e3("veth: don’t modify ip_summed; doing so treats
packets with bad checksums as good"). In the kernels that include the
fix, the userspace datapath is able to process pings, but not tcp or udp
data.
Unfortunately I couldn't find a way to ask the AF_PACKET to perform
offloads in kernel. A possible fix would be to use the PACKET_VNET_HDR
sockopt and perform the offloads in userspace.
Until a proper fix is worked out for netdev-linux, this commit disables
offloads on the non-OVS side of the veth pair, as a workaround.
Signed-off-by: Daniele Di Proietto <diproiettod@vmware.com>
Acked-by: Joe Stringer <joe@ovn.org>
Acked-by: Flavio Leitner <fbl@sysclose.org>
2016-04-15 13:17:50 -07:00
|
|
|
# CONFIGURE_VETH_OFFLOADS([VETH])
|
|
|
|
|
#
|
|
|
|
|
# Disable TX offloads for veths. The userspace datapath uses the AF_PACKET
|
|
|
|
|
# socket to receive packets for veths. Unfortunately, the AF_PACKET socket
|
|
|
|
|
# doesn't play well with offloads:
|
|
|
|
|
# 1. GSO packets are received without segmentation and therefore discarded.
|
|
|
|
|
# 2. Packets with offloaded partial checksum are received with the wrong
|
|
|
|
|
# checksum, therefore discarded by the receiver.
|
|
|
|
|
#
|
|
|
|
|
# By disabling tx offloads in the non-OVS side of the veth peer we make sure
|
|
|
|
|
# that the AF_PACKET socket will not receive bad packets.
|
|
|
|
|
#
|
|
|
|
|
# This is a workaround, and should be removed when offloads are properly
|
|
|
|
|
# supported in netdev-linux.
|
|
|
|
|
m4_define([CONFIGURE_VETH_OFFLOADS],
|
2017-07-26 12:49:48 -07:00
|
|
|
[AT_CHECK([ethtool -K $1 tx off], [0], [ignore], [ignore])]
|
system-tests: Disable offloads in userspace tests.
The system userspace testsuite uses the userspace datapath with
netdev-linux devices, connected to veth pairs with the AF_PACKET socket:
(veth pair) (AF_PACKET)
TCP stack -> p0 ---> ovs-p0 -------------> netdev-linux (userspace OVS)
Unfortunately this configuration has some problems with offloads: a
packet generated by the TCP stack maybe sent to p0 without being
checksummed or segmented. The AF_PACKET socket, by default, ignores the
offloads and just transmits the data of the packets to userspace, but:
1. The packet may need GSO, so the data will be too big to be received
by the userspace datapath
2. The packet might have incomplete checksums, so it will likely be
discarded by the receiver.
Problem 1 causes TCP connections to see a congestion window smaller than
the MTU, which hurts performance but doesn't prevent communication.
Problem 2 was hidden in the testsuite by a Linux kernel bug, fixed by
commit ce8c839b74e3("veth: don’t modify ip_summed; doing so treats
packets with bad checksums as good"). In the kernels that include the
fix, the userspace datapath is able to process pings, but not tcp or udp
data.
Unfortunately I couldn't find a way to ask the AF_PACKET to perform
offloads in kernel. A possible fix would be to use the PACKET_VNET_HDR
sockopt and perform the offloads in userspace.
Until a proper fix is worked out for netdev-linux, this commit disables
offloads on the non-OVS side of the veth pair, as a workaround.
Signed-off-by: Daniele Di Proietto <diproiettod@vmware.com>
Acked-by: Joe Stringer <joe@ovn.org>
Acked-by: Flavio Leitner <fbl@sysclose.org>
2016-04-15 13:17:50 -07:00
|
|
|
)
|
|
|
|
|
|
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
|
|
|
# CHECK_CONNTRACK()
|
|
|
|
|
#
|
2015-11-15 22:07:25 -08:00
|
|
|
# Perform requirements checks for running conntrack tests.
|
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
|
|
|
#
|
2019-09-20 08:30:42 -07:00
|
|
|
m4_define([CHECK_CONNTRACK], [])
|
2015-11-15 22:07:25 -08:00
|
|
|
|
|
|
|
|
# CHECK_CONNTRACK_ALG()
|
|
|
|
|
#
|
|
|
|
|
# Perform requirements checks for running conntrack ALG tests. The userspace
|
2017-08-06 10:51:16 -07:00
|
|
|
# supports FTP and TFTP.
|
2015-11-15 22:07:25 -08:00
|
|
|
#
|
2017-08-06 10:51:16 -07:00
|
|
|
m4_define([CHECK_CONNTRACK_ALG])
|
2015-11-15 22:07:25 -08:00
|
|
|
|
|
|
|
|
# CHECK_CONNTRACK_LOCAL_STACK()
|
|
|
|
|
#
|
|
|
|
|
# Perform requirements checks for running conntrack tests with local stack.
|
|
|
|
|
# While the kernel connection tracker automatically passes all the connection
|
|
|
|
|
# tracking state from an internal port to the OpenvSwitch kernel module, there
|
|
|
|
|
# is simply no way of doing that with the userspace, so skip the tests.
|
|
|
|
|
m4_define([CHECK_CONNTRACK_LOCAL_STACK],
|
|
|
|
|
[
|
|
|
|
|
AT_SKIP_IF([:])
|
|
|
|
|
])
|
|
|
|
|
|
2018-06-28 23:41:44 -07:00
|
|
|
# CHECK_CONNTRACK_FRAG_OVERLAP()
|
|
|
|
|
#
|
2019-02-13 15:34:21 -08:00
|
|
|
# The userspace datapath supports fragment overlap check.
|
|
|
|
|
m4_define([CHECK_CONNTRACK_FRAG_OVERLAP])
|
2018-06-28 23:41:44 -07:00
|
|
|
|
2015-11-15 22:07:25 -08:00
|
|
|
# CHECK_CONNTRACK_NAT()
|
|
|
|
|
#
|
|
|
|
|
# Perform requirements checks for running conntrack NAT tests. The userspace
|
2017-05-30 10:49:32 -07:00
|
|
|
# datapath supports NAT.
|
2015-11-15 22:07:25 -08:00
|
|
|
#
|
2017-05-30 10:49:32 -07:00
|
|
|
m4_define([CHECK_CONNTRACK_NAT])
|
dpctl: Support flush conntrack by conntrack 5-tuple
With this patch, "flush-conntrack" in ovs-dpctl and ovs-appctl accept
a conntrack 5-tuple to delete the conntrack entry specified by the 5-tuple.
For example, user can use the following command to flush a conntrack entry
in zone 5.
$ ovs-dpctl flush-conntrack zone=5 \
'ct_nw_src=10.1.1.2,ct_nw_dst=10.1.1.1,ct_nw_proto=17,ct_tp_src=2,ct_tp_dst=1'
$ ovs-appctl dpctl/flush-conntrack zone=5 \
'ct_nw_src=10.1.1.2,ct_nw_dst=10.1.1.1,ct_nw_proto=17,ct_tp_src=2,ct_tp_dst=1'
VMWare-BZ: #1983178
Signed-off-by: Yi-Hung Wei <yihung.wei@gmail.com>
Signed-off-by: Justin Pettit <jpettit@ovn.org>
2017-12-07 10:40:04 -08:00
|
|
|
|
2021-06-10 11:24:15 +02:00
|
|
|
# CHECK_CONNTRACK_ZEROIP_SNAT()
|
|
|
|
|
#
|
|
|
|
|
# Perform requirements checks for running conntrack all-zero IP SNAT tests.
|
conntrack: Handle SNAT with all-zero IP address.
This patch introduces for the userspace datapath the handling
of rules like the following:
ct(commit,nat(src=0.0.0.0),...)
Kernel datapath already handle this case that is particularly
handy in scenarios like the following:
Given A: 10.1.1.1, B: 192.168.2.100, C: 10.1.1.2
A opens a connection toward B on port 80 selecting as source port 10000.
B's IP gets dnat'ed to C's IP (10.1.1.1:10000 -> 192.168.2.100:80).
This will result in:
tcp,orig=(src=10.1.1.1,dst=192.168.2.100,sport=10000,dport=80),
reply=(src=10.1.1.2,dst=10.1.1.1,sport=80,dport=10000),
protoinfo=(state=ESTABLISHED)
A now tries to establish another connection with C using source port
10000, this time using C's IP address (10.1.1.1:10000 -> 10.1.1.2:80).
This second connection, if processed by conntrack with no SNAT/DNAT
involved, collides with the reverse tuple of the first connection,
so the entry for this valid connection doesn't get created.
With this commit, and adding a SNAT rule with 0.0.0.0 for
10.1.1.1:10000 -> 10.1.1.2:80 will allow to create the conn entry:
tcp,orig=(src=10.1.1.1,dst=10.1.1.2,sport=10000,dport=80),
reply=(src=10.1.1.2,dst=10.1.1.1,sport=80,dport=10001),
protoinfo=(state=ESTABLISHED)
tcp,orig=(src=10.1.1.1,dst=192.168.2.100,sport=10000,dport=80),
reply=(src=10.1.1.2,dst=10.1.1.1,sport=80,dport=10000),
protoinfo=(state=ESTABLISHED)
The issue exists even in the opposite case (with A trying to connect
to C using B's IP after establishing a direct connection from A to C).
This commit refactors the relevant function in a way that both of the
previously mentioned cases are handled as well.
Suggested-by: Eelco Chaudron <echaudro@redhat.com>
Signed-off-by: Paolo Valerio <pvalerio@redhat.com>
Acked-by: Gaetan Rivet <grive@u256.net>
Acked-by: Aaron Conole <aconole@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
2021-07-06 15:03:18 +02:00
|
|
|
# The userspace datapath always supports all-zero IP SNAT, so no check is
|
|
|
|
|
# needed.
|
2021-06-10 11:24:15 +02:00
|
|
|
#
|
conntrack: Handle SNAT with all-zero IP address.
This patch introduces for the userspace datapath the handling
of rules like the following:
ct(commit,nat(src=0.0.0.0),...)
Kernel datapath already handle this case that is particularly
handy in scenarios like the following:
Given A: 10.1.1.1, B: 192.168.2.100, C: 10.1.1.2
A opens a connection toward B on port 80 selecting as source port 10000.
B's IP gets dnat'ed to C's IP (10.1.1.1:10000 -> 192.168.2.100:80).
This will result in:
tcp,orig=(src=10.1.1.1,dst=192.168.2.100,sport=10000,dport=80),
reply=(src=10.1.1.2,dst=10.1.1.1,sport=80,dport=10000),
protoinfo=(state=ESTABLISHED)
A now tries to establish another connection with C using source port
10000, this time using C's IP address (10.1.1.1:10000 -> 10.1.1.2:80).
This second connection, if processed by conntrack with no SNAT/DNAT
involved, collides with the reverse tuple of the first connection,
so the entry for this valid connection doesn't get created.
With this commit, and adding a SNAT rule with 0.0.0.0 for
10.1.1.1:10000 -> 10.1.1.2:80 will allow to create the conn entry:
tcp,orig=(src=10.1.1.1,dst=10.1.1.2,sport=10000,dport=80),
reply=(src=10.1.1.2,dst=10.1.1.1,sport=80,dport=10001),
protoinfo=(state=ESTABLISHED)
tcp,orig=(src=10.1.1.1,dst=192.168.2.100,sport=10000,dport=80),
reply=(src=10.1.1.2,dst=10.1.1.1,sport=80,dport=10000),
protoinfo=(state=ESTABLISHED)
The issue exists even in the opposite case (with A trying to connect
to C using B's IP after establishing a direct connection from A to C).
This commit refactors the relevant function in a way that both of the
previously mentioned cases are handled as well.
Suggested-by: Eelco Chaudron <echaudro@redhat.com>
Signed-off-by: Paolo Valerio <pvalerio@redhat.com>
Acked-by: Gaetan Rivet <grive@u256.net>
Acked-by: Aaron Conole <aconole@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
2021-07-06 15:03:18 +02:00
|
|
|
m4_define([CHECK_CONNTRACK_ZEROIP_SNAT])
|
2021-06-10 11:24:15 +02:00
|
|
|
|
conntrack: Extract l4 information for SCTP.
Since a27d70a89 ("conntrack: add generic IP protocol support") all
the unrecognized IP protocols get handled using ct_proto_other ops
and are managed as L3 using 3 tuples.
This patch stores L4 information for SCTP in the conn_key so that
multiple conn instances, instead of one with ports zeroed, will be
created when there are multiple SCTP connections between two hosts.
It also performs crc32c check when not offloaded, and adds SCTP to
pat_enabled.
With this patch, given two SCTP association between two hosts,
tracking the connection will result in:
sctp,orig=(src=10.1.1.2,dst=10.1.1.1,sport=55884,dport=5201),
reply=(src=10.1.1.1,dst=10.1.1.2,sport=5201,dport=12345),zone=1
sctp,orig=(src=10.1.1.2,dst=10.1.1.1,sport=59874,dport=5202),
reply=(src=10.1.1.1,dst=10.1.1.2,sport=5202,dport=12346),zone=1
instead of:
sctp,orig=(src=10.1.1.2,dst=10.1.1.1,sport=0,dport=0),
reply=(src=10.1.1.1,dst=10.1.1.2,sport=0,dport=0),zone=1
Signed-off-by: Paolo Valerio <pvalerio@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
2023-07-12 11:16:43 +02:00
|
|
|
# CHECK_CONNTRACK_SCTP()
|
|
|
|
|
#
|
|
|
|
|
# Perform requirements checks for running conntrack SCTP. The userspace
|
|
|
|
|
# datapath has no dependency, so no check is required.
|
|
|
|
|
#
|
|
|
|
|
m4_define([CHECK_CONNTRACK_SCTP])
|
|
|
|
|
|
2019-08-28 15:14:29 -07:00
|
|
|
# CHECK_CONNTRACK_TIMEOUT()
|
|
|
|
|
#
|
|
|
|
|
# Perform requirements checks for running conntrack customized timeout tests.
|
|
|
|
|
#
|
2020-04-29 12:25:11 -07:00
|
|
|
m4_define([CHECK_CONNTRACK_TIMEOUT])
|
2019-08-28 15:14:29 -07:00
|
|
|
|
2023-06-23 12:33:43 +02:00
|
|
|
# CHECK_CONNTRACK_DUMP_EXPECTATIONS()
|
|
|
|
|
#
|
|
|
|
|
# Perform requirements checks for dumping conntrack expectations.
|
|
|
|
|
#
|
|
|
|
|
m4_define([CHECK_CONNTRACK_DUMP_EXPECTATIONS])
|
|
|
|
|
|
2018-01-08 15:18:44 -08:00
|
|
|
# CHECK_CT_DPIF_SET_GET_MAXCONNS()
|
|
|
|
|
#
|
|
|
|
|
# Perform requirements checks for running ovs-dpctl ct-set-maxconns or
|
|
|
|
|
# ovs-dpctl ct-get-maxconns. The userspace datapath does support this feature.
|
|
|
|
|
m4_define([CHECK_CT_DPIF_SET_GET_MAXCONNS])
|
|
|
|
|
|
|
|
|
|
# CHECK_CT_DPIF_GET_NCONNS()
|
|
|
|
|
#
|
|
|
|
|
# Perform requirements checks for running ovs-dpctl ct-get-nconns. The
|
|
|
|
|
# userspace datapath does support this feature.
|
|
|
|
|
m4_define([CHECK_CT_DPIF_GET_NCONNS])
|
2018-08-15 06:24:48 -07:00
|
|
|
|
2019-02-13 15:34:21 -08:00
|
|
|
# DPCTL_SET_MIN_FRAG_SIZE()
|
|
|
|
|
#
|
|
|
|
|
# The userspace datapath supports this command.
|
|
|
|
|
m4_define([DPCTL_SET_MIN_FRAG_SIZE],
|
|
|
|
|
[
|
|
|
|
|
AT_CHECK([ovs-appctl dpctl/ipf-set-min-frag v4 400], [], [dnl
|
|
|
|
|
setting minimum fragment size successful
|
|
|
|
|
])
|
|
|
|
|
AT_CHECK([ovs-appctl dpctl/ipf-set-min-frag v6 400], [], [dnl
|
|
|
|
|
setting minimum fragment size successful
|
|
|
|
|
])
|
|
|
|
|
])
|
|
|
|
|
|
|
|
|
|
# DPCTL_MODIFY_FRAGMENTATION()
|
|
|
|
|
#
|
|
|
|
|
# The userspace datapath supports this command.
|
|
|
|
|
m4_define([DPCTL_MODIFY_FRAGMENTATION],
|
|
|
|
|
[
|
|
|
|
|
AT_CHECK([ovs-appctl dpctl/ipf-set-min-frag v4 1000], [], [dnl
|
|
|
|
|
setting minimum fragment size successful
|
|
|
|
|
])
|
|
|
|
|
AT_CHECK([ovs-appctl dpctl/ipf-set-max-nfrags 500], [], [dnl
|
|
|
|
|
setting maximum fragments successful
|
|
|
|
|
])
|
|
|
|
|
AT_CHECK([ovs-appctl dpctl/ipf-get-status], [], [dnl
|
|
|
|
|
Fragmentation Module Status
|
|
|
|
|
---------------------------
|
|
|
|
|
v4 enabled: 1
|
|
|
|
|
v6 enabled: 1
|
|
|
|
|
max num frags (v4/v6): 500
|
|
|
|
|
num frag: 0
|
|
|
|
|
min v4 frag size: 1000
|
|
|
|
|
v4 frags accepted: 0
|
|
|
|
|
v4 frags completed: 0
|
|
|
|
|
v4 frags expired: 0
|
|
|
|
|
v4 frags too small: 0
|
|
|
|
|
v4 frags overlapped: 0
|
|
|
|
|
v4 frags purged: 0
|
|
|
|
|
min v6 frag size: 1280
|
|
|
|
|
v6 frags accepted: 0
|
|
|
|
|
v6 frags completed: 0
|
|
|
|
|
v6 frags expired: 0
|
|
|
|
|
v6 frags too small: 0
|
|
|
|
|
v6 frags overlapped: 0
|
|
|
|
|
v6 frags purged: 0
|
|
|
|
|
])
|
|
|
|
|
])
|
|
|
|
|
|
|
|
|
|
# DPCTL_CHECK_FRAGMENTATION_PASS()
|
|
|
|
|
#
|
|
|
|
|
# Used to check fragmentation counters for some fragmentation tests using
|
|
|
|
|
# the userspace datapath.
|
|
|
|
|
m4_define([DPCTL_CHECK_FRAGMENTATION_PASS],
|
|
|
|
|
[
|
|
|
|
|
AT_CHECK([ovs-appctl dpctl/ipf-get-status --more], [], [dnl
|
|
|
|
|
Fragmentation Module Status
|
|
|
|
|
---------------------------
|
|
|
|
|
v4 enabled: 1
|
|
|
|
|
v6 enabled: 1
|
|
|
|
|
max num frags (v4/v6): 500
|
|
|
|
|
num frag: 0
|
|
|
|
|
min v4 frag size: 1000
|
|
|
|
|
v4 frags accepted: 30
|
|
|
|
|
v4 frags completed: 30
|
|
|
|
|
v4 frags expired: 0
|
|
|
|
|
v4 frags too small: 0
|
|
|
|
|
v4 frags overlapped: 0
|
|
|
|
|
v4 frags purged: 0
|
|
|
|
|
min v6 frag size: 1280
|
|
|
|
|
v6 frags accepted: 0
|
|
|
|
|
v6 frags completed: 0
|
|
|
|
|
v6 frags expired: 0
|
|
|
|
|
v6 frags too small: 0
|
|
|
|
|
v6 frags overlapped: 0
|
|
|
|
|
v6 frags purged: 0
|
|
|
|
|
|
|
|
|
|
Fragment Lists:
|
|
|
|
|
|
|
|
|
|
])
|
|
|
|
|
])
|
|
|
|
|
|
|
|
|
|
# DPCTL_CHECK_V6_FRAGMENTATION_PASS()
|
|
|
|
|
#
|
|
|
|
|
# Used to check fragmentation counters for some fragmentation tests using
|
|
|
|
|
# the userspace datapath.
|
|
|
|
|
m4_define([DPCTL_CHECK_V6_FRAGMENTATION_PASS],
|
|
|
|
|
[
|
|
|
|
|
AT_CHECK([ovs-appctl dpctl/ipf-get-status --more], [], [dnl
|
|
|
|
|
Fragmentation Module Status
|
|
|
|
|
---------------------------
|
|
|
|
|
v4 enabled: 1
|
|
|
|
|
v6 enabled: 1
|
|
|
|
|
max num frags (v4/v6): 1000
|
|
|
|
|
num frag: 0
|
|
|
|
|
min v4 frag size: 1200
|
|
|
|
|
v4 frags accepted: 0
|
|
|
|
|
v4 frags completed: 0
|
|
|
|
|
v4 frags expired: 0
|
|
|
|
|
v4 frags too small: 0
|
|
|
|
|
v4 frags overlapped: 0
|
|
|
|
|
v4 frags purged: 0
|
|
|
|
|
min v6 frag size: 1280
|
|
|
|
|
v6 frags accepted: 30
|
|
|
|
|
v6 frags completed: 30
|
|
|
|
|
v6 frags expired: 0
|
|
|
|
|
v6 frags too small: 0
|
|
|
|
|
v6 frags overlapped: 0
|
|
|
|
|
v6 frags purged: 0
|
|
|
|
|
|
|
|
|
|
Fragment Lists:
|
|
|
|
|
|
|
|
|
|
])
|
|
|
|
|
])
|
|
|
|
|
|
|
|
|
|
# FORMAT_FRAG_LIST([])
|
|
|
|
|
#
|
|
|
|
|
# Strip content from the piped input which can differ from test to test; recirc_id
|
|
|
|
|
# and ip_id fields in an ipf_list vary from test to test and hence are cleared.
|
|
|
|
|
m4_define([FORMAT_FRAG_LIST],
|
|
|
|
|
[[sed -e 's/ip_id=[0-9]*/ip_id=<cleared>/g' -e 's/recirc_id=[0-9]*/recirc_id=<cleared>/g']])
|
|
|
|
|
|
|
|
|
|
# DPCTL_CHECK_FRAGMENTATION_FAIL()
|
|
|
|
|
#
|
|
|
|
|
# Used to check fragmentation counters for some fragmentation tests using
|
|
|
|
|
# the userspace datapath, when failure to transmit fragments is expected.
|
|
|
|
|
m4_define([DPCTL_CHECK_FRAGMENTATION_FAIL],
|
|
|
|
|
[
|
|
|
|
|
AT_CHECK([ovs-appctl dpctl/ipf-get-status -m | FORMAT_FRAG_LIST()], [], [dnl
|
|
|
|
|
Fragmentation Module Status
|
|
|
|
|
---------------------------
|
|
|
|
|
v4 enabled: 1
|
|
|
|
|
v6 enabled: 1
|
|
|
|
|
max num frags (v4/v6): 500
|
|
|
|
|
num frag: 7
|
|
|
|
|
min v4 frag size: 1000
|
|
|
|
|
v4 frags accepted: 7
|
|
|
|
|
v4 frags completed: 0
|
|
|
|
|
v4 frags expired: 0
|
|
|
|
|
v4 frags too small: 0
|
|
|
|
|
v4 frags overlapped: 0
|
|
|
|
|
v4 frags purged: 0
|
|
|
|
|
min v6 frag size: 1280
|
|
|
|
|
v6 frags accepted: 0
|
|
|
|
|
v6 frags completed: 0
|
|
|
|
|
v6 frags expired: 0
|
|
|
|
|
v6 frags too small: 0
|
|
|
|
|
v6 frags overlapped: 0
|
|
|
|
|
v6 frags purged: 0
|
|
|
|
|
|
|
|
|
|
Fragment Lists:
|
|
|
|
|
|
|
|
|
|
(src=10.1.1.1,dst=10.1.1.2,recirc_id=<cleared>,ip_id=<cleared>,dl_type=0x800,zone=9,nw_proto=1,num_fragments=1,state=first frag)
|
|
|
|
|
(src=10.1.1.1,dst=10.1.1.2,recirc_id=<cleared>,ip_id=<cleared>,dl_type=0x800,zone=9,nw_proto=1,num_fragments=1,state=first frag)
|
|
|
|
|
(src=10.1.1.1,dst=10.1.1.2,recirc_id=<cleared>,ip_id=<cleared>,dl_type=0x800,zone=9,nw_proto=1,num_fragments=1,state=first frag)
|
|
|
|
|
(src=10.1.1.1,dst=10.1.1.2,recirc_id=<cleared>,ip_id=<cleared>,dl_type=0x800,zone=9,nw_proto=1,num_fragments=1,state=first frag)
|
|
|
|
|
(src=10.1.1.1,dst=10.1.1.2,recirc_id=<cleared>,ip_id=<cleared>,dl_type=0x800,zone=9,nw_proto=1,num_fragments=1,state=first frag)
|
|
|
|
|
(src=10.1.1.1,dst=10.1.1.2,recirc_id=<cleared>,ip_id=<cleared>,dl_type=0x800,zone=9,nw_proto=1,num_fragments=1,state=first frag)
|
|
|
|
|
(src=10.1.1.1,dst=10.1.1.2,recirc_id=<cleared>,ip_id=<cleared>,dl_type=0x800,zone=9,nw_proto=1,num_fragments=1,state=first frag)
|
|
|
|
|
])
|
|
|
|
|
])
|
|
|
|
|
|
ipf: Fix the over-sized reassembly.
Fix the coredump of ovs_assert, The backtrace is as follows,
#8 0x0000561ee52084bb in ovs_assert_failure (where=<>, function=<>, condition=<>) at ../lib/util.c:89
#9 0x0000561ee50f8ab2 in dp_packet_set_size (b=<>, v=<>) at ../lib/dp-packet.h:687
#10 dp_packet_set_size (v=<>, b=0x7f7f88143e80) at ../lib/dp-packet.h:687
#11 dp_packet_put_uninit (size=395, b=0x7f7f88143e80) at ../lib/dp-packet.c:355
#12 dp_packet_put (b=0x7f7f88143e80, p=0x7f7f88143ce2, size=395) at ../lib/dp-packet.c:376
#13 0x0000561ee512c147 in ipf_reassemble_v4_frags (ipf_list=0x7f7f88110810) at ../lib/ipf.c:430
The mbuf data_len is a uint16_t field, which includes the ether header.
So does IPv6.
Fixes: 4ea96698f667 ("Userspace datapath: Add fragmentation handling.")
Acked-by: Mike Pattrick <mkp@redhat.com>
Signed-off-by: Faicker Mo <faicker.mo@zenlayer.com>
Signed-off-by: Aaron Conole <aconole@redhat.com>
2025-01-09 02:18:16 +00:00
|
|
|
# OVS_CHECK_FRAG_LARGE()
|
|
|
|
|
#
|
|
|
|
|
# The userspace needs to check that ipf larger fragments have occurred.
|
|
|
|
|
m4_define([OVS_CHECK_FRAG_LARGE],
|
|
|
|
|
[
|
|
|
|
|
OVS_WAIT_UNTIL([grep -Eq 'Unsupported big reassembled (v4|v6) packet' ovs-vswitchd.log])
|
|
|
|
|
])
|
|
|
|
|
|
2019-03-16 11:50:24 -07:00
|
|
|
# OVS_CHECK_MIN_KERNEL([minversion], [maxversion])
|
2018-08-15 06:24:48 -07:00
|
|
|
#
|
|
|
|
|
# The userspace skips all tests that check kernel version.
|
2019-03-16 11:50:24 -07:00
|
|
|
m4_define([OVS_CHECK_MIN_KERNEL],
|
2018-08-15 06:24:48 -07:00
|
|
|
[
|
|
|
|
|
AT_SKIP_IF([:])
|
|
|
|
|
])
|
|
|
|
|
|
|
|
|
|
# OVS_CHECK_KERNEL_EXCL([minversion], [maxversion], [minsublevel], [maxsublevel])
|
|
|
|
|
#
|
|
|
|
|
# The userspace skips all tests that check kernel version.
|
|
|
|
|
m4_define([OVS_CHECK_KERNEL_EXCL],
|
|
|
|
|
[
|
|
|
|
|
AT_SKIP_IF([:])
|
|
|
|
|
])
|
2019-08-28 15:14:29 -07:00
|
|
|
|
2023-03-29 14:51:17 +09:00
|
|
|
# OVS_CHECK_SRV6()
|
|
|
|
|
m4_define([OVS_CHECK_SRV6],
|
|
|
|
|
[AT_SKIP_IF([! ip -6 route add fc00::1/96 encap seg6 mode encap dev lo 2>&1 >/dev/null])
|
|
|
|
|
AT_CHECK([ip -6 route del fc00::1/96 2>&1 >/dev/null])
|
|
|
|
|
OVS_CHECK_FIREWALL()])
|
|
|
|
|
|
2022-08-05 13:17:08 +02:00
|
|
|
# CHECK_LATER_IPV6_FRAGMENTS()
|
|
|
|
|
#
|
|
|
|
|
# Userspace is parsing later IPv6 fragments correctly.
|
|
|
|
|
m4_define([CHECK_LATER_IPV6_FRAGMENTS], [])
|
|
|
|
|
|
2019-08-28 15:14:29 -07:00
|
|
|
# VSCTL_ADD_DATAPATH_TABLE()
|
|
|
|
|
#
|
|
|
|
|
# Create datapath table "netdev" for userspace tests in ovsdb
|
|
|
|
|
m4_define([VSCTL_ADD_DATAPATH_TABLE],
|
|
|
|
|
[
|
|
|
|
|
AT_CHECK([ovs-vsctl -- --id=@m create Datapath datapath_version=0 -- set Open_vSwitch . datapaths:"netdev"=@m], [0], [stdout])
|
|
|
|
|
DP_TYPE=$(echo "netdev")
|
|
|
|
|
])
|
2019-10-04 09:49:57 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
# CHECK_L3L4_CONNTRACK_REASM()
|
|
|
|
|
#
|
|
|
|
|
# Only allow this test to run on the kernel datapath - it is not useful
|
|
|
|
|
# or necessary for the userspace datapath as it is checking for a kernel
|
|
|
|
|
# specific regression.
|
|
|
|
|
m4_define([CHECK_L3L4_CONNTRACK_REASM],
|
|
|
|
|
[
|
|
|
|
|
AT_SKIP_IF([:])
|
|
|
|
|
])
|
2023-02-07 15:03:57 +01:00
|
|
|
|
|
|
|
|
# CHECK_NO_TC_OFFLOAD
|
|
|
|
|
#
|
|
|
|
|
# Userspace tests do not use TC offload.
|
|
|
|
|
m4_define([CHECK_NO_TC_OFFLOAD])
|
2023-05-25 15:07:53 +02:00
|
|
|
|
|
|
|
|
# OVS_CHECK_BAREUDP()
|
|
|
|
|
#
|
|
|
|
|
# The userspace datapath does not support bareudp tunnels.
|
|
|
|
|
m4_define([OVS_CHECK_BAREUDP],
|
|
|
|
|
[
|
|
|
|
|
AT_SKIP_IF([:])
|
|
|
|
|
])
|
2024-10-07 17:54:24 +02:00
|
|
|
|
|
|
|
|
# CHECK_EXTERNAL_CT()
|
|
|
|
|
#
|
|
|
|
|
# The userspace datapath does not support external ct.
|
|
|
|
|
m4_define([CHECK_EXTERNAL_CT],
|
|
|
|
|
[
|
|
|
|
|
AT_SKIP_IF([:])
|
|
|
|
|
])
|
|
|
|
|
|
|
|
|
|
# ADD_EXTERNAL_CT()
|
|
|
|
|
#
|
|
|
|
|
# The userspace datapath does not support external ct.
|
|
|
|
|
m4_define([ADD_EXTERNAL_CT],
|
|
|
|
|
[
|
|
|
|
|
AT_SKIP_IF([:])
|
|
|
|
|
])
|
