2
0
mirror of https://github.com/openvswitch/ovs synced 2025-08-24 02:47:14 +00:00
ovs/tests/system-common-macros.at

148 lines
4.9 KiB
Plaintext
Raw Normal View History

# DEL_NAMESPACES(ns [, ns ... ])
#
# Delete namespaces from the running OS
m4_define([DEL_NAMESPACES],
[m4_foreach([ns], [$@],
[ip netns del ns
])
]
)
# ADD_NAMESPACES(ns [, ns ... ])
#
# Add new namespaces, if ns exists, the old one
# will be remove before new ones are installed.
m4_define([ADD_NAMESPACES],
[m4_foreach([ns], [$@],
[DEL_NAMESPACES(ns)
AT_CHECK([ip netns add ns])
on_exit 'DEL_NAMESPACES(ns)'
])
]
)
# NS_EXEC([namespace], [command])
#
# Execute 'command' in 'namespace'
m4_define([NS_EXEC],
[ip netns exec $1 sh << NS_EXEC_HEREDOC
$2
NS_EXEC_HEREDOC])
# NS_CHECK_EXEC([namespace], [command], other_params...)
#
# Wrapper for AT_CHECK that executes 'command' inside 'namespace'.
# 'other_params' as passed as they are to AT_CHECK.
m4_define([NS_CHECK_EXEC],
[ AT_CHECK([NS_EXEC([$1], [$2])], m4_shift(m4_shift($@))) ]
)
# ADD_BR([name], [vsctl-args])
#
# Expands into the proper ovs-vsctl commands to create a bridge with the
# appropriate type, and allows additional arguments to be passed.
m4_define([ADD_BR], [ovs-vsctl _ADD_BR([$1]) -- $2])
# ADD_VETH([port], [namespace], [ovs-br], [ip_addr])
#
# Add a pair of veth ports. 'port' will be added to name space 'namespace',
# and "ovs-'port'" will be added to ovs bridge 'ovs-br'.
#
# The 'port' in 'namespace' will be brought up with static IP address
# with 'ip_addr' in CIDR notation.
#
# The existing 'port' or 'ovs-port' will be removed before new ones are added.
#
m4_define([ADD_VETH],
[ AT_CHECK([ip link add $1 type veth peer name ovs-$1])
AT_CHECK([ip link set $1 netns $2])
AT_CHECK([ip link set dev ovs-$1 up])
AT_CHECK([ovs-vsctl add-port $3 ovs-$1])
NS_CHECK_EXEC([$2], [ip addr add $4 dev $1])
NS_CHECK_EXEC([$2], [ip link set dev $1 up])
on_exit 'ip link del ovs-$1'
]
)
# ADD_VLAN([port], [namespace], [vlan-id], [ip-addr])
#
# Add a VLAN device named 'port' within 'namespace'. It will be configured
# with the ID 'vlan-id' and the address 'ip-addr'.
m4_define([ADD_VLAN],
[ NS_CHECK_EXEC([$2], [ip link add link $1 name $1.$3 type vlan id $3])
NS_CHECK_EXEC([$2], [ip link set dev $1.$3 up])
NS_CHECK_EXEC([$2], [ip addr add dev $1.$3 $4])
]
)
# ADD_OVS_TUNNEL([type], [bridge], [port], [remote-addr], [overlay-addr])
#
# Add an ovs-based tunnel device in the root namespace, with name 'port' and
# type 'type'. The tunnel device will be configured as point-to-point with the
# 'remote-addr' as the underlay address of the remote tunnel endpoint.
#
# 'port will be configured with the address 'overlay-addr'.
#
m4_define([ADD_OVS_TUNNEL],
[AT_CHECK([ovs-vsctl add-port $2 $3 -- \
set int $3 type=$1 options:remote_ip=$4])
AT_CHECK([ip addr add dev $2 $5])
AT_CHECK([ip link set dev $2 up])
AT_CHECK([ip link set dev $2 mtu 1450])
on_exit 'ip addr del dev $2 $5'
]
)
# ADD_NATIVE_TUNNEL([type], [port], [namespace], [remote-addr], [overlay-addr],
# [link-args])
#
# Add a native tunnel device within 'namespace', with name 'port' and type
# 'type'. The tunnel device will be configured as point-to-point with the
# 'remote-addr' as the underlay address of the remote tunnel endpoint (as
# viewed from the perspective of that namespace).
#
# 'port' will be configured with the address 'overlay-addr'. 'link-args' is
# made available so that additional arguments can be passed to "ip link",
# for instance to configure the vxlan destination port.
#
m4_define([ADD_NATIVE_TUNNEL],
[NS_CHECK_EXEC([$3], [ip link add dev $2 type $1 remote $4 $6])
NS_CHECK_EXEC([$3], [ip addr add dev $2 $5])
NS_CHECK_EXEC([$3], [ip link set dev $2 up])
NS_CHECK_EXEC([$3], [ip link set dev $2 mtu 1450])
]
)
# FORMAT_PING([])
#
# Strip variant pieces from ping output so the output can be reliably compared.
#
m4_define([FORMAT_PING], [grep "transmitted" | sed 's/time.*ms$/time 0ms/'])
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
# FORMAT_CT()
#
# Strip content from the piped input which would differ from test to test.
# Strip also content that depends on the system setup (accounting,
# timestamping)
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
m4_define([FORMAT_CT],
[[grep "dst=$1" | sed -e 's/port=[0-9]*/port=<cleared>/g' -e 's/ */ /g' \
-e 's/secctx[^ ]* //' \
-e 's/packets=[^ ]* //' \
-e 's/bytes=[^ ]* //' \
-e 's/packets=[^ ]* //' \
-e 's/bytes=[^ ]* //' \
-e 's/delta-time=[^ ]* //' \
-e 's/id=[0-9]*/id=<cleared>/g' \
| cut -d' ' -f4- | sort | uniq]])
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
# NETNS_DAEMONIZE([namespace], [command], [pidfile])
#
# Run 'command' as a background process within 'namespace' and record its pid
# to 'pidfile' to allow cleanup on exit.
#
m4_define([NETNS_DAEMONIZE],
[ip netns exec $1 $2 & echo $! > $3
echo "kill \`cat $3\`" >> cleanup
]
)