mir/ovs
2
0
Fork 0
mirror of https://github.com/openvswitch/ovs synced 2025-08-22 18:07:40 +00:00
Code Issues Releases Wiki Activity
ovs/tests/learn.at

330 lines
16 KiB
Plaintext
Raw Normal View History

Implement new "learn" action. There are a few loose ends here. First, learning actions cause too much flow revalidation. Upcoming commits will fix that problem. The following additional issues have not yet been addressed: * Resource limits: nothing yet limits the maximum number of flows that can be learned. It is possible to exhaust all system memory. * Age reporting: there is no way to find out how soon a learned table entry is due to be evicted. To try this action out, here's a recipe for a very simple-minded MAC learning switch. It uses a 10-second MAC expiration time to make it easier to see what's going on: ovs-vsctl del-controller br0 ovs-ofctl del-flows br0 ovs-ofctl add-flow br0 "table=0 actions=learn(table=1, hard_timeout=10, \ NXM_OF_VLAN_TCI[0..11], NXM_OF_ETH_DST[]=NXM_OF_ETH_SRC[], \ output:NXM_OF_IN_PORT[]), resubmit(,1)" ovs-ofctl add-flow br0 "table=1 priority=0 actions=flood" You can then dump the MAC learning table with: ovs-ofctl dump-flows br0 table=1
2011-09-12 16:19:57 -07:00
AT_BANNER([learning action])
AT_SETUP([learning action - parsing and formatting])
AT_DATA([flows.txt], [[
actions=learn()
actions=learn(NXM_OF_VLAN_TCI[0..11], NXM_OF_ETH_DST[]=NXM_OF_ETH_SRC[], output:NXM_OF_IN_PORT[], load:10->NXM_NX_REG0[5..10])
Implement new "fin_timeout" action and "learn" feature. The "learn" action can create matching return flows. If those have a long timeout then it's a good idea to have a way to notice when in fact the flows have terminated. This new action and matching "learn" feature provides that way. Feature #8603. Signed-off-by: Ben Pfaff <blp@nicira.com>
2012-02-15 10:37:03 -08:00
actions=learn(table=1,idle_timeout=10, hard_timeout=20, fin_idle_timeout=5, fin_hard_timeout=10, priority=10, cookie=0xfedcba9876543210, in_port=99,NXM_OF_ETH_DST[]=NXM_OF_ETH_SRC[],load:NXM_OF_IN_PORT[]->NXM_NX_REG1[16..31])
Implement new "learn" action. There are a few loose ends here. First, learning actions cause too much flow revalidation. Upcoming commits will fix that problem. The following additional issues have not yet been addressed: * Resource limits: nothing yet limits the maximum number of flows that can be learned. It is possible to exhaust all system memory. * Age reporting: there is no way to find out how soon a learned table entry is due to be evicted. To try this action out, here's a recipe for a very simple-minded MAC learning switch. It uses a 10-second MAC expiration time to make it easier to see what's going on: ovs-vsctl del-controller br0 ovs-ofctl del-flows br0 ovs-ofctl add-flow br0 "table=0 actions=learn(table=1, hard_timeout=10, \ NXM_OF_VLAN_TCI[0..11], NXM_OF_ETH_DST[]=NXM_OF_ETH_SRC[], \ output:NXM_OF_IN_PORT[]), resubmit(,1)" ovs-ofctl add-flow br0 "table=1 priority=0 actions=flood" You can then dump the MAC learning table with: ovs-ofctl dump-flows br0 table=1
2011-09-12 16:19:57 -07:00
]])
AT_CHECK([ovs-ofctl parse-flows flows.txt], [0],
Introduce ofputil_protocol, to abstract the protocol in use on a connection. Open vSwitch already handles a few different protocol variations, but it does so in a nonuniform manner: - OpenFlow 1.0 and NXM flow formats are distinguished using the NXFF_* constant values from nicira-ext.h. - The "flow_mod_table_id" feature setting is maintained in ofproto as part of an OpenFlow connection's (ofconn's) state. There's no way to easily communicate this state among components. It's not much of a problem yet, but as more protocol support is added it seems better to have an abstract, uniform way to represent protocol versions and variants. This commit implements that by introducing a new type "enum ofputil_protocol". Each ofputil_protocol value represents a variant of a protocol version. Each value is a separate bit, so a single enum can also represent a set of protocols, which is often useful as well. Reviewed-by: Simon Horman <horms@verge.net.au> Signed-off-by: Ben Pfaff <blp@nicira.com>
2012-02-10 13:30:23 -08:00
[[usable protocols: any
chosen protocol: OpenFlow10-table_id
OFPT_FLOW_MOD (xid=0x1): ADD actions=learn(table=1)
Introduce ofpacts, an abstraction of OpenFlow actions. OpenFlow actions have always been somewhat awkward to handle. Moreover, over time we've started creating actions that require more complicated parsing. When we maintain those actions internally in their wire format, we end up parsing them multiple times, whenever we have to look at the set of actions. When we add support for OpenFlow 1.1 or later protocols, the situation will get worse, because these newer protocols support many of the same actions but with different representations. It becomes unrealistic to handle each protocol in its wire format. This commit adopts a new strategy, by converting OpenFlow actions into an internal form from the wire format when they are read, and converting them back to the wire format when flows are dumped. I believe that this will be more maintainable over time. Thanks to Simon Horman and Pravin Shelar for reviews. Signed-off-by: Ben Pfaff <blp@nicira.com>
2012-07-03 22:17:14 -07:00
OFPT_FLOW_MOD (xid=0x2): ADD actions=learn(table=1,NXM_OF_VLAN_TCI[0..11],NXM_OF_ETH_DST[]=NXM_OF_ETH_SRC[],output:NXM_OF_IN_PORT[],load:0xa->NXM_NX_REG0[5..10])
Implement new "fin_timeout" action and "learn" feature. The "learn" action can create matching return flows. If those have a long timeout then it's a good idea to have a way to notice when in fact the flows have terminated. This new action and matching "learn" feature provides that way. Feature #8603. Signed-off-by: Ben Pfaff <blp@nicira.com>
2012-02-15 10:37:03 -08:00
OFPT_FLOW_MOD (xid=0x3): ADD actions=learn(table=1,idle_timeout=10,hard_timeout=20,fin_idle_timeout=5,fin_hard_timeout=10,priority=10,cookie=0xfedcba9876543210,in_port=99,NXM_OF_ETH_DST[]=NXM_OF_ETH_SRC[],load:NXM_OF_IN_PORT[]->NXM_NX_REG1[16..31])
Implement new "learn" action. There are a few loose ends here. First, learning actions cause too much flow revalidation. Upcoming commits will fix that problem. The following additional issues have not yet been addressed: * Resource limits: nothing yet limits the maximum number of flows that can be learned. It is possible to exhaust all system memory. * Age reporting: there is no way to find out how soon a learned table entry is due to be evicted. To try this action out, here's a recipe for a very simple-minded MAC learning switch. It uses a 10-second MAC expiration time to make it easier to see what's going on: ovs-vsctl del-controller br0 ovs-ofctl del-flows br0 ovs-ofctl add-flow br0 "table=0 actions=learn(table=1, hard_timeout=10, \ NXM_OF_VLAN_TCI[0..11], NXM_OF_ETH_DST[]=NXM_OF_ETH_SRC[], \ output:NXM_OF_IN_PORT[]), resubmit(,1)" ovs-ofctl add-flow br0 "table=1 priority=0 actions=flood" You can then dump the MAC learning table with: ovs-ofctl dump-flows br0 table=1
2011-09-12 16:19:57 -07:00
]])
AT_CLEANUP
learn: Correct example in nicira-ext.h and add examples as test cases.
2011-09-27 13:35:09 -07:00
meta-flow: Add MFF_IN_PORT_OXM, a 32-bit in_port. This helps get rid of one special case in nx_pull_raw() and allows loading of 32-bit values from/to OXM_OF_IN_PORT in NXAST_LEARN actions. Previously the 16-bit limit acted the same on both NXM_OF_IN_PORT and OXM_OF_IN_PORT, even though OF1.1+ controllers would expect OXM_OF_IN_PORT to be 32 bits wide. Signed-off-by: Jarno Rajahalme <jarno.rajahalme@nsn.com> Signed-off-by: Ben Pfaff <blp@nicira.com>
2013-05-19 15:44:53 +03:00
AT_SETUP([learning action - parsing and formatting - illegal in_port_oxm])
AT_CHECK([[ovs-ofctl parse-flow 'actions=learn(table=1, in_port_oxm=123456)']],
[1], [], [stderr])
AT_CHECK([sed -e 's/.*|ofp_util|WARN|//' < stderr], [0],
[[port 123456 is outside the supported range 0 through ffff or 0xffffff00 through 0xffffffff
ovs-ofctl: 123456: port value out of range for in_port_oxm
]], [[]])
AT_CLEANUP
AT_SETUP([learning action - parsing and formatting - OXM])
AT_DATA([flows.txt], [[
actions=learn(output:OXM_OF_IN_PORT[])
actions=learn(table=1, in_port=1, load:OXM_OF_IN_PORT[]->NXM_NX_REG1[], load:0xfffffffe->OXM_OF_IN_PORT[])
]])
AT_CHECK([ovs-ofctl parse-flows flows.txt], [0],
[[usable protocols: any
chosen protocol: OpenFlow10-table_id
OFPT_FLOW_MOD (xid=0x1): ADD actions=learn(table=1,output:OXM_OF_IN_PORT[])
OFPT_FLOW_MOD (xid=0x2): ADD actions=learn(table=1,in_port=1,load:OXM_OF_IN_PORT[]->NXM_NX_REG1[],load:0xfffffffe->OXM_OF_IN_PORT[])
]])
AT_CLEANUP
learn: Correct example in nicira-ext.h and add examples as test cases.
2011-09-27 13:35:09 -07:00
AT_SETUP([learning action - examples])
AT_DATA([flows.txt], [[
# These are the examples from nicira-ext.h.
actions=learn(in_port=99,NXM_OF_ETH_DST[]=NXM_OF_ETH_SRC[], load:NXM_OF_IN_PORT[]->NXM_NX_REG1[16..31])
actions=learn(NXM_OF_VLAN_TCI[0..11], NXM_OF_ETH_DST[]=NXM_OF_ETH_SRC[],output:NXM_OF_IN_PORT[])
table=0 actions=learn(table=1,hard_timeout=10, NXM_OF_VLAN_TCI[0..11],output:NXM_OF_IN_PORT[]), resubmit(,1)
table=1 priority=0 actions=flood
]])
AT_CHECK([ovs-ofctl parse-flows flows.txt], [0],
Add basic OpenFlow 1.1 protocol support. Signed-off-by: Ben Pfaff <blp@nicira.com>
2013-07-08 14:48:05 -07:00
[[usable protocols: OXM,OpenFlow10+table_id,NXM+table_id,OpenFlow11
Introduce ofputil_protocol, to abstract the protocol in use on a connection. Open vSwitch already handles a few different protocol variations, but it does so in a nonuniform manner: - OpenFlow 1.0 and NXM flow formats are distinguished using the NXFF_* constant values from nicira-ext.h. - The "flow_mod_table_id" feature setting is maintained in ofproto as part of an OpenFlow connection's (ofconn's) state. There's no way to easily communicate this state among components. It's not much of a problem yet, but as more protocol support is added it seems better to have an abstract, uniform way to represent protocol versions and variants. This commit implements that by introducing a new type "enum ofputil_protocol". Each ofputil_protocol value represents a variant of a protocol version. Each value is a separate bit, so a single enum can also represent a set of protocols, which is often useful as well. Reviewed-by: Simon Horman <horms@verge.net.au> Signed-off-by: Ben Pfaff <blp@nicira.com>
2012-02-10 13:30:23 -08:00
chosen protocol: OpenFlow10+table_id
OFPT_FLOW_MOD (xid=0x1): ADD table:255 actions=learn(table=1,in_port=99,NXM_OF_ETH_DST[]=NXM_OF_ETH_SRC[],load:NXM_OF_IN_PORT[]->NXM_NX_REG1[16..31])
OFPT_FLOW_MOD (xid=0x2): ADD table:255 actions=learn(table=1,NXM_OF_VLAN_TCI[0..11],NXM_OF_ETH_DST[]=NXM_OF_ETH_SRC[],output:NXM_OF_IN_PORT[])
OFPT_FLOW_MOD (xid=0x3): ADD actions=learn(table=1,hard_timeout=10,NXM_OF_VLAN_TCI[0..11],output:NXM_OF_IN_PORT[]),resubmit(,1)
OFPT_FLOW_MOD (xid=0x4): ADD table:1 priority=0 actions=FLOOD
learn: Correct example in nicira-ext.h and add examples as test cases.
2011-09-27 13:35:09 -07:00
]])
AT_CLEANUP
Implement new "learn" action. There are a few loose ends here. First, learning actions cause too much flow revalidation. Upcoming commits will fix that problem. The following additional issues have not yet been addressed: * Resource limits: nothing yet limits the maximum number of flows that can be learned. It is possible to exhaust all system memory. * Age reporting: there is no way to find out how soon a learned table entry is due to be evicted. To try this action out, here's a recipe for a very simple-minded MAC learning switch. It uses a 10-second MAC expiration time to make it easier to see what's going on: ovs-vsctl del-controller br0 ovs-ofctl del-flows br0 ovs-ofctl add-flow br0 "table=0 actions=learn(table=1, hard_timeout=10, \ NXM_OF_VLAN_TCI[0..11], NXM_OF_ETH_DST[]=NXM_OF_ETH_SRC[], \ output:NXM_OF_IN_PORT[]), resubmit(,1)" ovs-ofctl add-flow br0 "table=1 priority=0 actions=flood" You can then dump the MAC learning table with: ovs-ofctl dump-flows br0 table=1
2011-09-12 16:19:57 -07:00
AT_SETUP([learning action - satisfied prerequisites])
AT_DATA([flows.txt],
[[actions=learn(eth_type=0x800,load:5->NXM_OF_IP_DST[])
ip,actions=learn(load:NXM_OF_IP_DST[]->NXM_NX_REG1[])
meta-flow: Accept NXM and OXM field names, support NXM and OXM for output. This commit makes actions that accept NXM header values also accept OXM header values and accept OXM field names where previously only NXM field names were accepted. This makes it possible to add new OXM fields that don't have NXM header values, e.g. the OXM "metadata" field. Inspired by Joe Stringer's patch: http://openvswitch.org/pipermail/dev/2012-June/018344.html Reported-by: Joe Stringer <joe@wand.net.nz> Signed-off-by: Ben Pfaff <blp@nicira.com>
2012-06-26 10:52:34 -07:00
ip,actions=learn(eth_type=0x800,OXM_OF_IPV4_DST[])
Implement new "learn" action. There are a few loose ends here. First, learning actions cause too much flow revalidation. Upcoming commits will fix that problem. The following additional issues have not yet been addressed: * Resource limits: nothing yet limits the maximum number of flows that can be learned. It is possible to exhaust all system memory. * Age reporting: there is no way to find out how soon a learned table entry is due to be evicted. To try this action out, here's a recipe for a very simple-minded MAC learning switch. It uses a 10-second MAC expiration time to make it easier to see what's going on: ovs-vsctl del-controller br0 ovs-ofctl del-flows br0 ovs-ofctl add-flow br0 "table=0 actions=learn(table=1, hard_timeout=10, \ NXM_OF_VLAN_TCI[0..11], NXM_OF_ETH_DST[]=NXM_OF_ETH_SRC[], \ output:NXM_OF_IN_PORT[]), resubmit(,1)" ovs-ofctl add-flow br0 "table=1 priority=0 actions=flood" You can then dump the MAC learning table with: ovs-ofctl dump-flows br0 table=1
2011-09-12 16:19:57 -07:00
]])
AT_CHECK([ovs-ofctl parse-flows flows.txt], [0],
Introduce ofputil_protocol, to abstract the protocol in use on a connection. Open vSwitch already handles a few different protocol variations, but it does so in a nonuniform manner: - OpenFlow 1.0 and NXM flow formats are distinguished using the NXFF_* constant values from nicira-ext.h. - The "flow_mod_table_id" feature setting is maintained in ofproto as part of an OpenFlow connection's (ofconn's) state. There's no way to easily communicate this state among components. It's not much of a problem yet, but as more protocol support is added it seems better to have an abstract, uniform way to represent protocol versions and variants. This commit implements that by introducing a new type "enum ofputil_protocol". Each ofputil_protocol value represents a variant of a protocol version. Each value is a separate bit, so a single enum can also represent a set of protocols, which is often useful as well. Reviewed-by: Simon Horman <horms@verge.net.au> Signed-off-by: Ben Pfaff <blp@nicira.com>
2012-02-10 13:30:23 -08:00
[[usable protocols: any
chosen protocol: OpenFlow10-table_id
Introduce ofpacts, an abstraction of OpenFlow actions. OpenFlow actions have always been somewhat awkward to handle. Moreover, over time we've started creating actions that require more complicated parsing. When we maintain those actions internally in their wire format, we end up parsing them multiple times, whenever we have to look at the set of actions. When we add support for OpenFlow 1.1 or later protocols, the situation will get worse, because these newer protocols support many of the same actions but with different representations. It becomes unrealistic to handle each protocol in its wire format. This commit adopts a new strategy, by converting OpenFlow actions into an internal form from the wire format when they are read, and converting them back to the wire format when flows are dumped. I believe that this will be more maintainable over time. Thanks to Simon Horman and Pravin Shelar for reviews. Signed-off-by: Ben Pfaff <blp@nicira.com>
2012-07-03 22:17:14 -07:00
OFPT_FLOW_MOD (xid=0x1): ADD actions=learn(table=1,eth_type=0x800,load:0x5->NXM_OF_IP_DST[])
Implement new "learn" action. There are a few loose ends here. First, learning actions cause too much flow revalidation. Upcoming commits will fix that problem. The following additional issues have not yet been addressed: * Resource limits: nothing yet limits the maximum number of flows that can be learned. It is possible to exhaust all system memory. * Age reporting: there is no way to find out how soon a learned table entry is due to be evicted. To try this action out, here's a recipe for a very simple-minded MAC learning switch. It uses a 10-second MAC expiration time to make it easier to see what's going on: ovs-vsctl del-controller br0 ovs-ofctl del-flows br0 ovs-ofctl add-flow br0 "table=0 actions=learn(table=1, hard_timeout=10, \ NXM_OF_VLAN_TCI[0..11], NXM_OF_ETH_DST[]=NXM_OF_ETH_SRC[], \ output:NXM_OF_IN_PORT[]), resubmit(,1)" ovs-ofctl add-flow br0 "table=1 priority=0 actions=flood" You can then dump the MAC learning table with: ovs-ofctl dump-flows br0 table=1
2011-09-12 16:19:57 -07:00
OFPT_FLOW_MOD (xid=0x2): ADD ip actions=learn(table=1,load:NXM_OF_IP_DST[]->NXM_NX_REG1[])
OFPT_FLOW_MOD (xid=0x3): ADD ip actions=learn(table=1,eth_type=0x800,NXM_OF_IP_DST[])
]])
AT_CLEANUP
AT_SETUP([learning action - invalid prerequisites])
AT_CHECK([[ovs-ofctl parse-flow 'actions=learn(load:5->NXM_OF_IP_DST[])']],
Do not perform validation in learn_parse(); I believe this is consistent with the handling of all other action parsing called from parse_named_action(). Verification of all actions, including learn actions, occurs separately in ofpact_check__(). It also occurs via in a call to ofpacts_check() in parse_ofp_str(), This patch is larger than might otherwise be expected as the flow argument of learn_parse() is now unused and thus removed. This propagates up the call-chain some way. This implementation was suggested by Jesse Gross in response to an enhancement I made to the validation performed during parsing learn actions to allow it to correctly account for changes to the dl_type due to MPLS push and pop actions. Tests have also been updated to check for the less specific messages generated by the call to ofpacts_check() in parse_ofp_str() which at the suggestion of Ben Pfaff was added by a prior patch for this purpose. Cc: Jesse Gross <jesse@nicira.com> Cc: Ben Pfaff <blp@nicira.com> Signed-off-by: Simon Horman <horms@verge.net.au> Signed-off-by: Ben Pfaff <blp@nicira.com>
2013-05-08 10:50:15 +09:00
[1], [], [stderr])
AT_CHECK([sed -e 's/.*|meta_flow|WARN|//' < stderr], [0],
[[destination field ip_dst lacks correct prerequisites
ofp-parse: Do not exit() upon a parse error. Until now, failure to parse a flow in the ofp-parse module has caused the program to abort immediately with a fatal error. This makes it hard to use these functions from any long-lived program. This commit fixes the problem. Signed-off-by: Ben Pfaff <blp@nicira.com>
2013-07-08 10:15:00 -07:00
ovs-ofctl: actions are invalid with specified match (OFPBAC_BAD_ARGUMENT)
Do not perform validation in learn_parse(); I believe this is consistent with the handling of all other action parsing called from parse_named_action(). Verification of all actions, including learn actions, occurs separately in ofpact_check__(). It also occurs via in a call to ofpacts_check() in parse_ofp_str(), This patch is larger than might otherwise be expected as the flow argument of learn_parse() is now unused and thus removed. This propagates up the call-chain some way. This implementation was suggested by Jesse Gross in response to an enhancement I made to the validation performed during parsing learn actions to allow it to correctly account for changes to the dl_type due to MPLS push and pop actions. Tests have also been updated to check for the less specific messages generated by the call to ofpacts_check() in parse_ofp_str() which at the suggestion of Ben Pfaff was added by a prior patch for this purpose. Cc: Jesse Gross <jesse@nicira.com> Cc: Ben Pfaff <blp@nicira.com> Signed-off-by: Simon Horman <horms@verge.net.au> Signed-off-by: Ben Pfaff <blp@nicira.com>
2013-05-08 10:50:15 +09:00
]], [[]])
Implement new "learn" action. There are a few loose ends here. First, learning actions cause too much flow revalidation. Upcoming commits will fix that problem. The following additional issues have not yet been addressed: * Resource limits: nothing yet limits the maximum number of flows that can be learned. It is possible to exhaust all system memory. * Age reporting: there is no way to find out how soon a learned table entry is due to be evicted. To try this action out, here's a recipe for a very simple-minded MAC learning switch. It uses a 10-second MAC expiration time to make it easier to see what's going on: ovs-vsctl del-controller br0 ovs-ofctl del-flows br0 ovs-ofctl add-flow br0 "table=0 actions=learn(table=1, hard_timeout=10, \ NXM_OF_VLAN_TCI[0..11], NXM_OF_ETH_DST[]=NXM_OF_ETH_SRC[], \ output:NXM_OF_IN_PORT[]), resubmit(,1)" ovs-ofctl add-flow br0 "table=1 priority=0 actions=flood" You can then dump the MAC learning table with: ovs-ofctl dump-flows br0 table=1
2011-09-12 16:19:57 -07:00
AT_CHECK([[ovs-ofctl parse-flow 'actions=learn(load:NXM_OF_IP_DST[]->NXM_NX_REG1[])']],
Do not perform validation in learn_parse(); I believe this is consistent with the handling of all other action parsing called from parse_named_action(). Verification of all actions, including learn actions, occurs separately in ofpact_check__(). It also occurs via in a call to ofpacts_check() in parse_ofp_str(), This patch is larger than might otherwise be expected as the flow argument of learn_parse() is now unused and thus removed. This propagates up the call-chain some way. This implementation was suggested by Jesse Gross in response to an enhancement I made to the validation performed during parsing learn actions to allow it to correctly account for changes to the dl_type due to MPLS push and pop actions. Tests have also been updated to check for the less specific messages generated by the call to ofpacts_check() in parse_ofp_str() which at the suggestion of Ben Pfaff was added by a prior patch for this purpose. Cc: Jesse Gross <jesse@nicira.com> Cc: Ben Pfaff <blp@nicira.com> Signed-off-by: Simon Horman <horms@verge.net.au> Signed-off-by: Ben Pfaff <blp@nicira.com>
2013-05-08 10:50:15 +09:00
[1], [], [stderr])
AT_CHECK([sed -e 's/.*|meta_flow|WARN|//' < stderr], [0],
[[source field ip_dst lacks correct prerequisites
ofp-parse: Do not exit() upon a parse error. Until now, failure to parse a flow in the ofp-parse module has caused the program to abort immediately with a fatal error. This makes it hard to use these functions from any long-lived program. This commit fixes the problem. Signed-off-by: Ben Pfaff <blp@nicira.com>
2013-07-08 10:15:00 -07:00
ovs-ofctl: actions are invalid with specified match (OFPBAC_BAD_ARGUMENT)
Implement new "learn" action. There are a few loose ends here. First, learning actions cause too much flow revalidation. Upcoming commits will fix that problem. The following additional issues have not yet been addressed: * Resource limits: nothing yet limits the maximum number of flows that can be learned. It is possible to exhaust all system memory. * Age reporting: there is no way to find out how soon a learned table entry is due to be evicted. To try this action out, here's a recipe for a very simple-minded MAC learning switch. It uses a 10-second MAC expiration time to make it easier to see what's going on: ovs-vsctl del-controller br0 ovs-ofctl del-flows br0 ovs-ofctl add-flow br0 "table=0 actions=learn(table=1, hard_timeout=10, \ NXM_OF_VLAN_TCI[0..11], NXM_OF_ETH_DST[]=NXM_OF_ETH_SRC[], \ output:NXM_OF_IN_PORT[]), resubmit(,1)" ovs-ofctl add-flow br0 "table=1 priority=0 actions=flood" You can then dump the MAC learning table with: ovs-ofctl dump-flows br0 table=1
2011-09-12 16:19:57 -07:00
]])
AT_CLEANUP
AT_SETUP([learning action - standard VLAN+MAC learning])
test-openflowd: Remove. Some users were still confused by its presence.
2011-10-24 10:36:01 -07:00
OVS_VSWITCHD_START(
tests: Rewrite unit tests to not expect bridge with odp zero. A future commit will make all bridges of a particular type share a single backing datapath. That backing datapath will have a datapath port number of zero and bridges will be assigned other numbers. This commit modifies the tests so that they don't expect port zero. It adopts the convention that bridges of type "dummy" with a name of the form "br<n>" will be assigned a port number of 100+<n>. Signed-off-by: Justin Pettit <jpettit@nicira.com>
2012-10-13 17:45:00 -07:00
[add-port br0 p1 -- set Interface p1 type=dummy ofport_request=1 -- \
add-port br0 p2 -- set Interface p2 type=dummy ofport_request=2 -- \
add-port br0 p3 -- set Interface p3 type=dummy ofport_request=3])
Implement new "learn" action. There are a few loose ends here. First, learning actions cause too much flow revalidation. Upcoming commits will fix that problem. The following additional issues have not yet been addressed: * Resource limits: nothing yet limits the maximum number of flows that can be learned. It is possible to exhaust all system memory. * Age reporting: there is no way to find out how soon a learned table entry is due to be evicted. To try this action out, here's a recipe for a very simple-minded MAC learning switch. It uses a 10-second MAC expiration time to make it easier to see what's going on: ovs-vsctl del-controller br0 ovs-ofctl del-flows br0 ovs-ofctl add-flow br0 "table=0 actions=learn(table=1, hard_timeout=10, \ NXM_OF_VLAN_TCI[0..11], NXM_OF_ETH_DST[]=NXM_OF_ETH_SRC[], \ output:NXM_OF_IN_PORT[]), resubmit(,1)" ovs-ofctl add-flow br0 "table=1 priority=0 actions=flood" You can then dump the MAC learning table with: ovs-ofctl dump-flows br0 table=1
2011-09-12 16:19:57 -07:00
# Set up flow table for VLAN+MAC learning.
AT_DATA([flows.txt], [[
table=0 actions=learn(table=1, hard_timeout=60, NXM_OF_VLAN_TCI[0..11], NXM_OF_ETH_DST[]=NXM_OF_ETH_SRC[], output:NXM_OF_IN_PORT[]), resubmit(,1)
table=1 priority=0 actions=flood
]])
AT_CHECK([ovs-ofctl add-flows br0 flows.txt])
# Trace an ARP packet arriving on port 3, to create a MAC learning entry.
tests: Rewrite unit tests to not expect bridge with odp zero. A future commit will make all bridges of a particular type share a single backing datapath. That backing datapath will have a datapath port number of zero and bridges will be assigned other numbers. This commit modifies the tests so that they don't expect port zero. It adopts the convention that bridges of type "dummy" with a name of the form "br<n>" will be assigned a port number of 100+<n>. Signed-off-by: Justin Pettit <jpettit@nicira.com>
2012-10-13 17:45:00 -07:00
flow="in_port(3),eth(src=50:54:00:00:00:05,dst=ff:ff:ff:ff:ff:ff),eth_type(0x0806),arp(sip=192.168.0.1,tip=192.168.0.2,op=1,sha=50:54:00:00:00:05,tha=00:00:00:00:00:00)"
ofproto/ofproto-dpif.c: Re-implement the ofproto/trace command Since the use of single datapath, all bridges belonging to the same type of datapath will use the same (single) datapath. This causes confusion in the current 'ofproto/trace' command. Especially, when given the unrelated 'bridge' and 'in_port' combination, the current implementation will still be able to process and give misleading output. Thusly, this patch changes the 'ofproto/trace' command syntax to formats shown as follow. ofproto/trace [datapath] odp_flow [-generate|packet] ofproto/trace bridge br_flow [-generate|packet] Also, this patch updates the tests and the manpages accordingly. Co-authored-by: Ben Pfaff <blp@nicira.com> Signed-off-by: Alex Wang <alexw@nicira.com> Signed-off-by: Ben Pfaff <blp@nicira.com>
2013-05-20 11:36:05 -07:00
AT_CHECK([ovs-appctl ofproto/trace ovs-dummy "$flow" -generate], [0], [stdout])
tests: Rewrite unit tests to not expect bridge with odp zero. A future commit will make all bridges of a particular type share a single backing datapath. That backing datapath will have a datapath port number of zero and bridges will be assigned other numbers. This commit modifies the tests so that they don't expect port zero. It adopts the convention that bridges of type "dummy" with a name of the form "br<n>" will be assigned a port number of 100+<n>. Signed-off-by: Justin Pettit <jpettit@nicira.com>
2012-10-13 17:45:00 -07:00
actual=`tail -1 stdout | sed 's/Datapath actions: //'`
expected="1,2,100"
AT_CHECK([ovs-dpctl normalize-actions "$flow" "$expected"], [0], [stdout])
mv stdout expout
AT_CHECK([ovs-dpctl normalize-actions "$flow" "$actual"], [0], [expout])
Implement new "learn" action. There are a few loose ends here. First, learning actions cause too much flow revalidation. Upcoming commits will fix that problem. The following additional issues have not yet been addressed: * Resource limits: nothing yet limits the maximum number of flows that can be learned. It is possible to exhaust all system memory. * Age reporting: there is no way to find out how soon a learned table entry is due to be evicted. To try this action out, here's a recipe for a very simple-minded MAC learning switch. It uses a 10-second MAC expiration time to make it easier to see what's going on: ovs-vsctl del-controller br0 ovs-ofctl del-flows br0 ovs-ofctl add-flow br0 "table=0 actions=learn(table=1, hard_timeout=10, \ NXM_OF_VLAN_TCI[0..11], NXM_OF_ETH_DST[]=NXM_OF_ETH_SRC[], \ output:NXM_OF_IN_PORT[]), resubmit(,1)" ovs-ofctl add-flow br0 "table=1 priority=0 actions=flood" You can then dump the MAC learning table with: ovs-ofctl dump-flows br0 table=1
2011-09-12 16:19:57 -07:00
# Check for the MAC learning entry.
tests: Use ofctl_strip consistently. The ofctl_strip shell function was introduced a little while ago. It makes test results easier to read, in my opinion, by removing uninteresting bits. This commit adopts ofctl_strip throughout the tests. This is useful in an upcoming commit that adds additional fields that should also be stripped to ovs-ofctl output. Signed-off-by: Ben Pfaff <blp@nicira.com>
2012-02-01 12:45:32 -08:00
AT_CHECK([ovs-ofctl dump-flows br0 table=1 | ofctl_strip | sort], [0], [dnl
ofp-print: Add some more white space to flow dumps. Before idle_age and hard_age were added, in the absence of timeouts there was a space between the statistics for a flow and the start of the flow match. This restores that space. Requested-by: Paul Ingram <paul@nicira.com> Signed-off-by: Ben Pfaff <blp@nicira.com>
2012-04-26 15:54:54 -07:00
table=1, hard_timeout=60, vlan_tci=0x0000/0x0fff,dl_dst=50:54:00:00:00:05 actions=output:3
tests: Use ofctl_strip consistently. The ofctl_strip shell function was introduced a little while ago. It makes test results easier to read, in my opinion, by removing uninteresting bits. This commit adopts ofctl_strip throughout the tests. This is useful in an upcoming commit that adds additional fields that should also be stripped to ovs-ofctl output. Signed-off-by: Ben Pfaff <blp@nicira.com>
2012-02-01 12:45:32 -08:00
table=1, priority=0 actions=FLOOD
Implement new "learn" action. There are a few loose ends here. First, learning actions cause too much flow revalidation. Upcoming commits will fix that problem. The following additional issues have not yet been addressed: * Resource limits: nothing yet limits the maximum number of flows that can be learned. It is possible to exhaust all system memory. * Age reporting: there is no way to find out how soon a learned table entry is due to be evicted. To try this action out, here's a recipe for a very simple-minded MAC learning switch. It uses a 10-second MAC expiration time to make it easier to see what's going on: ovs-vsctl del-controller br0 ovs-ofctl del-flows br0 ovs-ofctl add-flow br0 "table=0 actions=learn(table=1, hard_timeout=10, \ NXM_OF_VLAN_TCI[0..11], NXM_OF_ETH_DST[]=NXM_OF_ETH_SRC[], \ output:NXM_OF_IN_PORT[]), resubmit(,1)" ovs-ofctl add-flow br0 "table=1 priority=0 actions=flood" You can then dump the MAC learning table with: ovs-ofctl dump-flows br0 table=1
2011-09-12 16:19:57 -07:00
NXST_FLOW reply:
])
# Trace a packet arrival destined for the learned MAC.
# (This will also learn a MAC.)
ofproto/ofproto-dpif.c: Re-implement the ofproto/trace command Since the use of single datapath, all bridges belonging to the same type of datapath will use the same (single) datapath. This causes confusion in the current 'ofproto/trace' command. Especially, when given the unrelated 'bridge' and 'in_port' combination, the current implementation will still be able to process and give misleading output. Thusly, this patch changes the 'ofproto/trace' command syntax to formats shown as follow. ofproto/trace [datapath] odp_flow [-generate|packet] ofproto/trace bridge br_flow [-generate|packet] Also, this patch updates the tests and the manpages accordingly. Co-authored-by: Ben Pfaff <blp@nicira.com> Signed-off-by: Alex Wang <alexw@nicira.com> Signed-off-by: Ben Pfaff <blp@nicira.com>
2013-05-20 11:36:05 -07:00
AT_CHECK([ovs-appctl ofproto/trace ovs-dummy 'in_port(1),eth(src=50:54:00:00:00:06,dst=50:54:00:00:00:05),eth_type(0x0806),arp(sip=192.168.0.2,tip=192.168.0.1,op=2,sha=50:54:00:00:00:06,tha=50:54:00:00:00:05)' -generate], [0], [stdout])
Implement new "learn" action. There are a few loose ends here. First, learning actions cause too much flow revalidation. Upcoming commits will fix that problem. The following additional issues have not yet been addressed: * Resource limits: nothing yet limits the maximum number of flows that can be learned. It is possible to exhaust all system memory. * Age reporting: there is no way to find out how soon a learned table entry is due to be evicted. To try this action out, here's a recipe for a very simple-minded MAC learning switch. It uses a 10-second MAC expiration time to make it easier to see what's going on: ovs-vsctl del-controller br0 ovs-ofctl del-flows br0 ovs-ofctl add-flow br0 "table=0 actions=learn(table=1, hard_timeout=10, \ NXM_OF_VLAN_TCI[0..11], NXM_OF_ETH_DST[]=NXM_OF_ETH_SRC[], \ output:NXM_OF_IN_PORT[]), resubmit(,1)" ovs-ofctl add-flow br0 "table=1 priority=0 actions=flood" You can then dump the MAC learning table with: ovs-ofctl dump-flows br0 table=1
2011-09-12 16:19:57 -07:00
AT_CHECK([tail -1 stdout], [0], [Datapath actions: 3
])
# Check for both MAC learning entries.
tests: Use ofctl_strip consistently. The ofctl_strip shell function was introduced a little while ago. It makes test results easier to read, in my opinion, by removing uninteresting bits. This commit adopts ofctl_strip throughout the tests. This is useful in an upcoming commit that adds additional fields that should also be stripped to ovs-ofctl output. Signed-off-by: Ben Pfaff <blp@nicira.com>
2012-02-01 12:45:32 -08:00
AT_CHECK([ovs-ofctl dump-flows br0 table=1 | ofctl_strip |sort], [0], [dnl
ofp-print: Add some more white space to flow dumps. Before idle_age and hard_age were added, in the absence of timeouts there was a space between the statistics for a flow and the start of the flow match. This restores that space. Requested-by: Paul Ingram <paul@nicira.com> Signed-off-by: Ben Pfaff <blp@nicira.com>
2012-04-26 15:54:54 -07:00
table=1, hard_timeout=60, vlan_tci=0x0000/0x0fff,dl_dst=50:54:00:00:00:05 actions=output:3
table=1, hard_timeout=60, vlan_tci=0x0000/0x0fff,dl_dst=50:54:00:00:00:06 actions=output:1
tests: Use ofctl_strip consistently. The ofctl_strip shell function was introduced a little while ago. It makes test results easier to read, in my opinion, by removing uninteresting bits. This commit adopts ofctl_strip throughout the tests. This is useful in an upcoming commit that adds additional fields that should also be stripped to ovs-ofctl output. Signed-off-by: Ben Pfaff <blp@nicira.com>
2012-02-01 12:45:32 -08:00
table=1, priority=0 actions=FLOOD
Implement new "learn" action. There are a few loose ends here. First, learning actions cause too much flow revalidation. Upcoming commits will fix that problem. The following additional issues have not yet been addressed: * Resource limits: nothing yet limits the maximum number of flows that can be learned. It is possible to exhaust all system memory. * Age reporting: there is no way to find out how soon a learned table entry is due to be evicted. To try this action out, here's a recipe for a very simple-minded MAC learning switch. It uses a 10-second MAC expiration time to make it easier to see what's going on: ovs-vsctl del-controller br0 ovs-ofctl del-flows br0 ovs-ofctl add-flow br0 "table=0 actions=learn(table=1, hard_timeout=10, \ NXM_OF_VLAN_TCI[0..11], NXM_OF_ETH_DST[]=NXM_OF_ETH_SRC[], \ output:NXM_OF_IN_PORT[]), resubmit(,1)" ovs-ofctl add-flow br0 "table=1 priority=0 actions=flood" You can then dump the MAC learning table with: ovs-ofctl dump-flows br0 table=1
2011-09-12 16:19:57 -07:00
NXST_FLOW reply:
])
# Trace a packet arrival that updates the first learned MAC entry.
tests: Rewrite unit tests to not expect bridge with odp zero. A future commit will make all bridges of a particular type share a single backing datapath. That backing datapath will have a datapath port number of zero and bridges will be assigned other numbers. This commit modifies the tests so that they don't expect port zero. It adopts the convention that bridges of type "dummy" with a name of the form "br<n>" will be assigned a port number of 100+<n>. Signed-off-by: Justin Pettit <jpettit@nicira.com>
2012-10-13 17:45:00 -07:00
flow="in_port(2),eth(src=50:54:00:00:00:05,dst=ff:ff:ff:ff:ff:ff),eth_type(0x0806),arp(sip=192.168.0.1,tip=192.168.0.2,op=1,sha=50:54:00:00:00:05,tha=00:00:00:00:00:00)"
ofproto/ofproto-dpif.c: Re-implement the ofproto/trace command Since the use of single datapath, all bridges belonging to the same type of datapath will use the same (single) datapath. This causes confusion in the current 'ofproto/trace' command. Especially, when given the unrelated 'bridge' and 'in_port' combination, the current implementation will still be able to process and give misleading output. Thusly, this patch changes the 'ofproto/trace' command syntax to formats shown as follow. ofproto/trace [datapath] odp_flow [-generate|packet] ofproto/trace bridge br_flow [-generate|packet] Also, this patch updates the tests and the manpages accordingly. Co-authored-by: Ben Pfaff <blp@nicira.com> Signed-off-by: Alex Wang <alexw@nicira.com> Signed-off-by: Ben Pfaff <blp@nicira.com>
2013-05-20 11:36:05 -07:00
AT_CHECK([ovs-appctl ofproto/trace ovs-dummy "$flow" -generate], [0], [stdout])
tests: Rewrite unit tests to not expect bridge with odp zero. A future commit will make all bridges of a particular type share a single backing datapath. That backing datapath will have a datapath port number of zero and bridges will be assigned other numbers. This commit modifies the tests so that they don't expect port zero. It adopts the convention that bridges of type "dummy" with a name of the form "br<n>" will be assigned a port number of 100+<n>. Signed-off-by: Justin Pettit <jpettit@nicira.com>
2012-10-13 17:45:00 -07:00
actual=`tail -1 stdout | sed 's/Datapath actions: //'`
expected="1,3,100"
AT_CHECK([ovs-dpctl normalize-actions "$flow" "$expected"], [0], [stdout])
mv stdout expout
AT_CHECK([ovs-dpctl normalize-actions "$flow" "$actual"], [0], [expout])
Implement new "learn" action. There are a few loose ends here. First, learning actions cause too much flow revalidation. Upcoming commits will fix that problem. The following additional issues have not yet been addressed: * Resource limits: nothing yet limits the maximum number of flows that can be learned. It is possible to exhaust all system memory. * Age reporting: there is no way to find out how soon a learned table entry is due to be evicted. To try this action out, here's a recipe for a very simple-minded MAC learning switch. It uses a 10-second MAC expiration time to make it easier to see what's going on: ovs-vsctl del-controller br0 ovs-ofctl del-flows br0 ovs-ofctl add-flow br0 "table=0 actions=learn(table=1, hard_timeout=10, \ NXM_OF_VLAN_TCI[0..11], NXM_OF_ETH_DST[]=NXM_OF_ETH_SRC[], \ output:NXM_OF_IN_PORT[]), resubmit(,1)" ovs-ofctl add-flow br0 "table=1 priority=0 actions=flood" You can then dump the MAC learning table with: ovs-ofctl dump-flows br0 table=1
2011-09-12 16:19:57 -07:00
# Check that the MAC learning entry was updated.
tests: Use ofctl_strip consistently. The ofctl_strip shell function was introduced a little while ago. It makes test results easier to read, in my opinion, by removing uninteresting bits. This commit adopts ofctl_strip throughout the tests. This is useful in an upcoming commit that adds additional fields that should also be stripped to ovs-ofctl output. Signed-off-by: Ben Pfaff <blp@nicira.com>
2012-02-01 12:45:32 -08:00
AT_CHECK([ovs-ofctl dump-flows br0 table=1 | ofctl_strip | sort], [0], [dnl
ofp-print: Add some more white space to flow dumps. Before idle_age and hard_age were added, in the absence of timeouts there was a space between the statistics for a flow and the start of the flow match. This restores that space. Requested-by: Paul Ingram <paul@nicira.com> Signed-off-by: Ben Pfaff <blp@nicira.com>
2012-04-26 15:54:54 -07:00
table=1, hard_timeout=60, vlan_tci=0x0000/0x0fff,dl_dst=50:54:00:00:00:05 actions=output:2
table=1, hard_timeout=60, vlan_tci=0x0000/0x0fff,dl_dst=50:54:00:00:00:06 actions=output:1
tests: Use ofctl_strip consistently. The ofctl_strip shell function was introduced a little while ago. It makes test results easier to read, in my opinion, by removing uninteresting bits. This commit adopts ofctl_strip throughout the tests. This is useful in an upcoming commit that adds additional fields that should also be stripped to ovs-ofctl output. Signed-off-by: Ben Pfaff <blp@nicira.com>
2012-02-01 12:45:32 -08:00
table=1, priority=0 actions=FLOOD
Implement new "learn" action. There are a few loose ends here. First, learning actions cause too much flow revalidation. Upcoming commits will fix that problem. The following additional issues have not yet been addressed: * Resource limits: nothing yet limits the maximum number of flows that can be learned. It is possible to exhaust all system memory. * Age reporting: there is no way to find out how soon a learned table entry is due to be evicted. To try this action out, here's a recipe for a very simple-minded MAC learning switch. It uses a 10-second MAC expiration time to make it easier to see what's going on: ovs-vsctl del-controller br0 ovs-ofctl del-flows br0 ovs-ofctl add-flow br0 "table=0 actions=learn(table=1, hard_timeout=10, \ NXM_OF_VLAN_TCI[0..11], NXM_OF_ETH_DST[]=NXM_OF_ETH_SRC[], \ output:NXM_OF_IN_PORT[]), resubmit(,1)" ovs-ofctl add-flow br0 "table=1 priority=0 actions=flood" You can then dump the MAC learning table with: ovs-ofctl dump-flows br0 table=1
2011-09-12 16:19:57 -07:00
NXST_FLOW reply:
])
test-openflowd: Remove. Some users were still confused by its presence.
2011-10-24 10:36:01 -07:00
OVS_VSWITCHD_STOP
Implement new "learn" action. There are a few loose ends here. First, learning actions cause too much flow revalidation. Upcoming commits will fix that problem. The following additional issues have not yet been addressed: * Resource limits: nothing yet limits the maximum number of flows that can be learned. It is possible to exhaust all system memory. * Age reporting: there is no way to find out how soon a learned table entry is due to be evicted. To try this action out, here's a recipe for a very simple-minded MAC learning switch. It uses a 10-second MAC expiration time to make it easier to see what's going on: ovs-vsctl del-controller br0 ovs-ofctl del-flows br0 ovs-ofctl add-flow br0 "table=0 actions=learn(table=1, hard_timeout=10, \ NXM_OF_VLAN_TCI[0..11], NXM_OF_ETH_DST[]=NXM_OF_ETH_SRC[], \ output:NXM_OF_IN_PORT[]), resubmit(,1)" ovs-ofctl add-flow br0 "table=1 priority=0 actions=flood" You can then dump the MAC learning table with: ovs-ofctl dump-flows br0 table=1
2011-09-12 16:19:57 -07:00
AT_CLEANUP
Implement new "fin_timeout" action and "learn" feature. The "learn" action can create matching return flows. If those have a long timeout then it's a good idea to have a way to notice when in fact the flows have terminated. This new action and matching "learn" feature provides that way. Feature #8603. Signed-off-by: Ben Pfaff <blp@nicira.com>
2012-02-15 10:37:03 -08:00
ofproto: Properly refresh rule modified time when nothing else changes. In Open vSwitch, a "modify" or "modify_strict" flow_mod is supposed to refresh the flow's last-modified time even if nothing else changes, because this interpretation makes the "learn" action more useful. As commit 308881afb (ofproto: Reinterpret meaning of OpenFlow hard timeouts with OFPFC_MODIFY.) notes: I finally found a good use for hard timeouts in OpenFlow, but they require a slight reinterpretation of the meaning of hard timeouts. Until now, a hard timeout meant that a flow would be removed the specified number of seconds after a flow was created. Intervening modifications with OFPFC_MODIFY(_STRICT) had no effect on the hard timeout; the flow would still be deleted the specified number of seconds after its original creation. This commit changes the effect of OFPFC_MODIFY(_STRICT). Now, modifying a flow resets its hard timeout counter. A flow will time out the specified number of seconds after creation or after the last time it is modified, whichever comes later. However, commit 080437614b (ofproto: Represent flow cookie changes as operations too.) broke this behavior because it incorrectly optimized out "modify" operations that didn't change the flow's actions or flow cookie. This commit fixes the problem, and adds a test to prevent future regression. Thanks to Amar Padmanabhan <amar@nicira.com> for helping to track this down. Bug #14841. Reported-by: Hiroshi Tanaka <htanaka@vmware.com> CC: Amar Padmanabhan <amar@nicira.com> Signed-off-by: Ben Pfaff <blp@nicira.com>
2013-01-25 15:07:36 -08:00
dnl This test checks that repeated uses of a "learn" action cause the
dnl modified time of the learned flow to advance. Otherwise, the
dnl learned flow will expire after its hard timeout even though it's
dnl supposed to be refreshed. (The expiration can be hard to see since
dnl it gets re-learned again the next time a packet appears, but
dnl sometimes the expiration can cause temporary flooding etc.)
AT_SETUP([learning action - learn refreshes hard_age])
OVS_VSWITCHD_START(
[add-port br0 p1 -- set Interface p1 type=dummy ofport_request=1 -- \
add-port br0 p2 -- set Interface p2 type=dummy ofport_request=2 -- \
add-port br0 p3 -- set Interface p3 type=dummy ofport_request=3])
ovs-appctl time/stop
# Set up flow table for MAC learning.
AT_DATA([flows.txt], [[
table=0 actions=learn(table=1, hard_timeout=10, NXM_OF_ETH_DST[]=NXM_OF_ETH_SRC[], output:NXM_OF_IN_PORT[]), resubmit(,1)
table=1 priority=0 actions=flood
]])
AT_CHECK([ovs-ofctl add-flows br0 flows.txt])
# Trace an ICMP packet arriving on port 3, to create a MAC learning entry.
flow="in_port(3),eth(src=50:54:00:00:00:07,dst=50:54:00:00:00:05),eth_type(0x0800),ipv4(src=192.168.0.2,dst=192.168.0.1,proto=1,tos=0,ttl=64,frag=no),icmp(type=0,code=0)"
ofproto/ofproto-dpif.c: Re-implement the ofproto/trace command Since the use of single datapath, all bridges belonging to the same type of datapath will use the same (single) datapath. This causes confusion in the current 'ofproto/trace' command. Especially, when given the unrelated 'bridge' and 'in_port' combination, the current implementation will still be able to process and give misleading output. Thusly, this patch changes the 'ofproto/trace' command syntax to formats shown as follow. ofproto/trace [datapath] odp_flow [-generate|packet] ofproto/trace bridge br_flow [-generate|packet] Also, this patch updates the tests and the manpages accordingly. Co-authored-by: Ben Pfaff <blp@nicira.com> Signed-off-by: Alex Wang <alexw@nicira.com> Signed-off-by: Ben Pfaff <blp@nicira.com>
2013-05-20 11:36:05 -07:00
AT_CHECK([ovs-appctl ofproto/trace ovs-dummy "$flow" -generate], [0], [stdout])
ofproto: Properly refresh rule modified time when nothing else changes. In Open vSwitch, a "modify" or "modify_strict" flow_mod is supposed to refresh the flow's last-modified time even if nothing else changes, because this interpretation makes the "learn" action more useful. As commit 308881afb (ofproto: Reinterpret meaning of OpenFlow hard timeouts with OFPFC_MODIFY.) notes: I finally found a good use for hard timeouts in OpenFlow, but they require a slight reinterpretation of the meaning of hard timeouts. Until now, a hard timeout meant that a flow would be removed the specified number of seconds after a flow was created. Intervening modifications with OFPFC_MODIFY(_STRICT) had no effect on the hard timeout; the flow would still be deleted the specified number of seconds after its original creation. This commit changes the effect of OFPFC_MODIFY(_STRICT). Now, modifying a flow resets its hard timeout counter. A flow will time out the specified number of seconds after creation or after the last time it is modified, whichever comes later. However, commit 080437614b (ofproto: Represent flow cookie changes as operations too.) broke this behavior because it incorrectly optimized out "modify" operations that didn't change the flow's actions or flow cookie. This commit fixes the problem, and adds a test to prevent future regression. Thanks to Amar Padmanabhan <amar@nicira.com> for helping to track this down. Bug #14841. Reported-by: Hiroshi Tanaka <htanaka@vmware.com> CC: Amar Padmanabhan <amar@nicira.com> Signed-off-by: Ben Pfaff <blp@nicira.com>
2013-01-25 15:07:36 -08:00
actual=`tail -1 stdout | sed 's/Datapath actions: //'`
expected="1,2,100"
AT_CHECK([ovs-dpctl normalize-actions "$flow" "$expected"], [0], [stdout])
mv stdout expout
AT_CHECK([ovs-dpctl normalize-actions "$flow" "$actual"], [0], [expout])
# Check that the MAC learning entry appeared.
AT_CHECK([ovs-ofctl dump-flows br0 table=1 | ofctl_strip | sort], [0], [dnl
table=1, hard_timeout=10, dl_dst=50:54:00:00:00:07 actions=output:3
table=1, priority=0 actions=FLOOD
NXST_FLOW reply:
])
# For 25 seconds, make sure that the MAC learning entry doesn't
# disappear as long as we refresh it every second.
for i in 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25; do
ovs-appctl time/warp 1000
ofproto/ofproto-dpif.c: Re-implement the ofproto/trace command Since the use of single datapath, all bridges belonging to the same type of datapath will use the same (single) datapath. This causes confusion in the current 'ofproto/trace' command. Especially, when given the unrelated 'bridge' and 'in_port' combination, the current implementation will still be able to process and give misleading output. Thusly, this patch changes the 'ofproto/trace' command syntax to formats shown as follow. ofproto/trace [datapath] odp_flow [-generate|packet] ofproto/trace bridge br_flow [-generate|packet] Also, this patch updates the tests and the manpages accordingly. Co-authored-by: Ben Pfaff <blp@nicira.com> Signed-off-by: Alex Wang <alexw@nicira.com> Signed-off-by: Ben Pfaff <blp@nicira.com>
2013-05-20 11:36:05 -07:00
AT_CHECK([ovs-appctl ofproto/trace ovs-dummy "$flow" -generate], [0], [stdout])
ofproto: Properly refresh rule modified time when nothing else changes. In Open vSwitch, a "modify" or "modify_strict" flow_mod is supposed to refresh the flow's last-modified time even if nothing else changes, because this interpretation makes the "learn" action more useful. As commit 308881afb (ofproto: Reinterpret meaning of OpenFlow hard timeouts with OFPFC_MODIFY.) notes: I finally found a good use for hard timeouts in OpenFlow, but they require a slight reinterpretation of the meaning of hard timeouts. Until now, a hard timeout meant that a flow would be removed the specified number of seconds after a flow was created. Intervening modifications with OFPFC_MODIFY(_STRICT) had no effect on the hard timeout; the flow would still be deleted the specified number of seconds after its original creation. This commit changes the effect of OFPFC_MODIFY(_STRICT). Now, modifying a flow resets its hard timeout counter. A flow will time out the specified number of seconds after creation or after the last time it is modified, whichever comes later. However, commit 080437614b (ofproto: Represent flow cookie changes as operations too.) broke this behavior because it incorrectly optimized out "modify" operations that didn't change the flow's actions or flow cookie. This commit fixes the problem, and adds a test to prevent future regression. Thanks to Amar Padmanabhan <amar@nicira.com> for helping to track this down. Bug #14841. Reported-by: Hiroshi Tanaka <htanaka@vmware.com> CC: Amar Padmanabhan <amar@nicira.com> Signed-off-by: Ben Pfaff <blp@nicira.com>
2013-01-25 15:07:36 -08:00
# Check that the entry is there.
AT_CHECK([ovs-ofctl dump-flows br0 table=1], [0], [stdout])
AT_CHECK([ofctl_strip < stdout | sort], [0], [dnl
table=1, hard_timeout=10, dl_dst=50:54:00:00:00:07 actions=output:3
table=1, priority=0 actions=FLOOD
NXST_FLOW reply:
])
if test $i != 1; then
# Check that hard_age has appeared. We need to do this separately
# from the above check because ofctl_strip removes it. dump-flows
# only prints hard_age when it is different from the flow's duration
# (that is, the number of seconds from the time it was created),
# so we only check for it after we've refreshed the flow once.
AT_CHECK([grep dl_dst=50:54:00:00:00:07 stdout | grep -c hard_age],
[0], [1
])
fi
done
# Make sure that 15 seconds without refreshing makes the flow time out.
ovs-appctl time/warp 5000
ovs-appctl time/warp 5000
ovs-appctl time/warp 5000
AT_CHECK([ovs-ofctl dump-flows br0 table=1 | ofctl_strip | sort], [0], [dnl
table=1, priority=0 actions=FLOOD
NXST_FLOW reply:
])
OVS_VSWITCHD_STOP
AT_CLEANUP
learn: Fix bugs when learn actions use subfields wider than 64 bits. Bug #10576. Reported-by: James Schmidt <jschmidt@nicira.com> Signed-off-by: Ben Pfaff <blp@nicira.com>
2012-04-11 17:08:13 -07:00
AT_SETUP([learning action - TCPv4 port learning])
OVS_VSWITCHD_START(
tests: Rewrite unit tests to not expect bridge with odp zero. A future commit will make all bridges of a particular type share a single backing datapath. That backing datapath will have a datapath port number of zero and bridges will be assigned other numbers. This commit modifies the tests so that they don't expect port zero. It adopts the convention that bridges of type "dummy" with a name of the form "br<n>" will be assigned a port number of 100+<n>. Signed-off-by: Justin Pettit <jpettit@nicira.com>
2012-10-13 17:45:00 -07:00
[add-port br0 p1 -- set Interface p1 type=dummy -- \
add-port br0 p2 -- set Interface p2 type=dummy -- \
add-port br0 p3 -- set Interface p3 type=dummy])
learn: Fix bugs when learn actions use subfields wider than 64 bits. Bug #10576. Reported-by: James Schmidt <jschmidt@nicira.com> Signed-off-by: Ben Pfaff <blp@nicira.com>
2012-04-11 17:08:13 -07:00
# Set up flow table for TCPv4 port learning.
AT_CHECK([[ovs-ofctl add-flow br0 'table=0 tcp actions=learn(table=1, hard_timeout=60, eth_type=0x800, nw_proto=6, NXM_OF_IP_SRC[]=NXM_OF_IP_DST[], NXM_OF_IP_DST[]=NXM_OF_IP_SRC[], NXM_OF_TCP_SRC[]=NXM_OF_TCP_DST[], NXM_OF_TCP_DST[]=NXM_OF_TCP_SRC[]), flood']])
# Trace a TCPv4 packet arriving on port 3.
tests: Rewrite unit tests to not expect bridge with odp zero. A future commit will make all bridges of a particular type share a single backing datapath. That backing datapath will have a datapath port number of zero and bridges will be assigned other numbers. This commit modifies the tests so that they don't expect port zero. It adopts the convention that bridges of type "dummy" with a name of the form "br<n>" will be assigned a port number of 100+<n>. Signed-off-by: Justin Pettit <jpettit@nicira.com>
2012-10-13 17:45:00 -07:00
flow="in_port(3),eth(src=50:54:00:00:00:05,dst=50:54:00:00:00:06),eth_type(0x0800),ipv4(src=192.168.0.2,dst=192.168.0.1,proto=6,tos=0,ttl=64,frag=no),tcp(src=40000,dst=80)"
ofproto/ofproto-dpif.c: Re-implement the ofproto/trace command Since the use of single datapath, all bridges belonging to the same type of datapath will use the same (single) datapath. This causes confusion in the current 'ofproto/trace' command. Especially, when given the unrelated 'bridge' and 'in_port' combination, the current implementation will still be able to process and give misleading output. Thusly, this patch changes the 'ofproto/trace' command syntax to formats shown as follow. ofproto/trace [datapath] odp_flow [-generate|packet] ofproto/trace bridge br_flow [-generate|packet] Also, this patch updates the tests and the manpages accordingly. Co-authored-by: Ben Pfaff <blp@nicira.com> Signed-off-by: Alex Wang <alexw@nicira.com> Signed-off-by: Ben Pfaff <blp@nicira.com>
2013-05-20 11:36:05 -07:00
AT_CHECK([ovs-appctl ofproto/trace ovs-dummy "$flow" -generate], [0], [stdout])
tests: Rewrite unit tests to not expect bridge with odp zero. A future commit will make all bridges of a particular type share a single backing datapath. That backing datapath will have a datapath port number of zero and bridges will be assigned other numbers. This commit modifies the tests so that they don't expect port zero. It adopts the convention that bridges of type "dummy" with a name of the form "br<n>" will be assigned a port number of 100+<n>. Signed-off-by: Justin Pettit <jpettit@nicira.com>
2012-10-13 17:45:00 -07:00
actual=`tail -1 stdout | sed 's/Datapath actions: //'`
expected="1,2,100"
AT_CHECK([ovs-dpctl normalize-actions "$flow" "$expected"], [0], [stdout])
mv stdout expout
AT_CHECK([ovs-dpctl normalize-actions "$flow" "$actual"], [0], [expout])
learn: Fix bugs when learn actions use subfields wider than 64 bits. Bug #10576. Reported-by: James Schmidt <jschmidt@nicira.com> Signed-off-by: Ben Pfaff <blp@nicira.com>
2012-04-11 17:08:13 -07:00
# Check for the learning entry.
AT_CHECK([ovs-ofctl dump-flows br0 table=1 | ofctl_strip | sort], [0], [dnl
ofp-print: Add some more white space to flow dumps. Before idle_age and hard_age were added, in the absence of timeouts there was a space between the statistics for a flow and the start of the flow match. This restores that space. Requested-by: Paul Ingram <paul@nicira.com> Signed-off-by: Ben Pfaff <blp@nicira.com>
2012-04-26 15:54:54 -07:00
table=1, hard_timeout=60, tcp,nw_src=192.168.0.1,nw_dst=192.168.0.2,tp_src=80,tp_dst=40000 actions=drop
learn: Fix bugs when learn actions use subfields wider than 64 bits. Bug #10576. Reported-by: James Schmidt <jschmidt@nicira.com> Signed-off-by: Ben Pfaff <blp@nicira.com>
2012-04-11 17:08:13 -07:00
NXST_FLOW reply:
])
OVS_VSWITCHD_STOP
AT_CLEANUP
AT_SETUP([learning action - TCPv6 port learning])
OVS_VSWITCHD_START(
tests: Rewrite unit tests to not expect bridge with odp zero. A future commit will make all bridges of a particular type share a single backing datapath. That backing datapath will have a datapath port number of zero and bridges will be assigned other numbers. This commit modifies the tests so that they don't expect port zero. It adopts the convention that bridges of type "dummy" with a name of the form "br<n>" will be assigned a port number of 100+<n>. Signed-off-by: Justin Pettit <jpettit@nicira.com>
2012-10-13 17:45:00 -07:00
[add-port br0 p1 -- set Interface p1 type=dummy -- \
add-port br0 p2 -- set Interface p2 type=dummy -- \
add-port br0 p3 -- set Interface p3 type=dummy])
learn: Fix bugs when learn actions use subfields wider than 64 bits. Bug #10576. Reported-by: James Schmidt <jschmidt@nicira.com> Signed-off-by: Ben Pfaff <blp@nicira.com>
2012-04-11 17:08:13 -07:00
# Set up flow table for TCPv6 port learning.
learn: Make it possible to parse "load" actions wider than 64 bits. The implementation of the "learn" action now properly implements specifications such as 0x20010db885a308d313198a2e03707348->NXM_NX_IPV6_DST but the parser used in ovs-ofctl and elsewhere could not generate such specifications. This commit adds that support. Signed-off-by: Ben Pfaff <blp@nicira.com>
2012-04-13 21:24:17 -07:00
# Also add a 128-bit-wide "load" action and a 128-bit literal match to check
# that they work.
AT_CHECK([[ovs-ofctl add-flow br0 'table=0 tcp6 actions=learn(table=1, hard_timeout=60, eth_type=0x86dd, nw_proto=6, NXM_NX_IPV6_SRC[]=NXM_NX_IPV6_DST[], ipv6_dst=2001:0db8:85a3:0000:0000:8a2e:0370:7334, NXM_OF_TCP_SRC[]=NXM_OF_TCP_DST[], NXM_OF_TCP_DST[]=NXM_OF_TCP_SRC[], load(0x20010db885a308d313198a2e03707348->NXM_NX_IPV6_DST[])), flood']])
learn: Fix bugs when learn actions use subfields wider than 64 bits. Bug #10576. Reported-by: James Schmidt <jschmidt@nicira.com> Signed-off-by: Ben Pfaff <blp@nicira.com>
2012-04-11 17:08:13 -07:00
# Trace a TCPv6 packet arriving on port 3.
tests: Rewrite unit tests to not expect bridge with odp zero. A future commit will make all bridges of a particular type share a single backing datapath. That backing datapath will have a datapath port number of zero and bridges will be assigned other numbers. This commit modifies the tests so that they don't expect port zero. It adopts the convention that bridges of type "dummy" with a name of the form "br<n>" will be assigned a port number of 100+<n>. Signed-off-by: Justin Pettit <jpettit@nicira.com>
2012-10-13 17:45:00 -07:00
flow="in_port(3),eth(src=50:54:00:00:00:05,dst=50:54:00:00:00:06),eth_type(0x86dd),ipv6(src=fec0::2,dst=fec0::1,label=0,proto=6,tclass=0,hlimit=255,frag=no),tcp(src=40000,dst=80)"
ofproto/ofproto-dpif.c: Re-implement the ofproto/trace command Since the use of single datapath, all bridges belonging to the same type of datapath will use the same (single) datapath. This causes confusion in the current 'ofproto/trace' command. Especially, when given the unrelated 'bridge' and 'in_port' combination, the current implementation will still be able to process and give misleading output. Thusly, this patch changes the 'ofproto/trace' command syntax to formats shown as follow. ofproto/trace [datapath] odp_flow [-generate|packet] ofproto/trace bridge br_flow [-generate|packet] Also, this patch updates the tests and the manpages accordingly. Co-authored-by: Ben Pfaff <blp@nicira.com> Signed-off-by: Alex Wang <alexw@nicira.com> Signed-off-by: Ben Pfaff <blp@nicira.com>
2013-05-20 11:36:05 -07:00
AT_CHECK([ovs-appctl ofproto/trace ovs-dummy "$flow" -generate], [0], [stdout])
tests: Rewrite unit tests to not expect bridge with odp zero. A future commit will make all bridges of a particular type share a single backing datapath. That backing datapath will have a datapath port number of zero and bridges will be assigned other numbers. This commit modifies the tests so that they don't expect port zero. It adopts the convention that bridges of type "dummy" with a name of the form "br<n>" will be assigned a port number of 100+<n>. Signed-off-by: Justin Pettit <jpettit@nicira.com>
2012-10-13 17:45:00 -07:00
actual=`tail -1 stdout | sed 's/Datapath actions: //'`
expected="1,2,100"
AT_CHECK([ovs-dpctl normalize-actions "$flow" "$expected"], [0], [stdout])
mv stdout expout
AT_CHECK([ovs-dpctl normalize-actions "$flow" "$actual"], [0], [expout])
learn: Fix bugs when learn actions use subfields wider than 64 bits. Bug #10576. Reported-by: James Schmidt <jschmidt@nicira.com> Signed-off-by: Ben Pfaff <blp@nicira.com>
2012-04-11 17:08:13 -07:00
# Check for the learning entry.
learn: Make it possible to parse "load" actions wider than 64 bits. The implementation of the "learn" action now properly implements specifications such as 0x20010db885a308d313198a2e03707348->NXM_NX_IPV6_DST but the parser used in ovs-ofctl and elsewhere could not generate such specifications. This commit adds that support. Signed-off-by: Ben Pfaff <blp@nicira.com>
2012-04-13 21:24:17 -07:00
AT_CHECK([ovs-ofctl dump-flows br0 | ofctl_strip | sort], [0], [dnl
ofp-print: Add some more white space to flow dumps. Before idle_age and hard_age were added, in the absence of timeouts there was a space between the statistics for a flow and the start of the flow match. This restores that space. Requested-by: Paul Ingram <paul@nicira.com> Signed-off-by: Ben Pfaff <blp@nicira.com>
2012-04-26 15:54:54 -07:00
table=1, hard_timeout=60, tcp6,ipv6_src=fec0::1,ipv6_dst=2001:db8:85a3::8a2e:370:7334,tp_src=80,tp_dst=40000 actions=load:0x13198a2e03707348->NXM_NX_IPV6_DST[[0..63]],load:0x20010db885a308d3->NXM_NX_IPV6_DST[[64..127]]
learn: Make it possible to parse "load" actions wider than 64 bits. The implementation of the "learn" action now properly implements specifications such as 0x20010db885a308d313198a2e03707348->NXM_NX_IPV6_DST but the parser used in ovs-ofctl and elsewhere could not generate such specifications. This commit adds that support. Signed-off-by: Ben Pfaff <blp@nicira.com>
2012-04-13 21:24:17 -07:00
tcp6 actions=learn(table=1,hard_timeout=60,eth_type=0x86dd,nw_proto=6,NXM_NX_IPV6_SRC[[]]=NXM_NX_IPV6_DST[[]],ipv6_dst=2001:db8:85a3::8a2e:370:7334,NXM_OF_TCP_SRC[[]]=NXM_OF_TCP_DST[[]],NXM_OF_TCP_DST[[]]=NXM_OF_TCP_SRC[[]],load:0x20010db885a308d313198a2e03707348->NXM_NX_IPV6_DST[[]]),FLOOD
learn: Fix bugs when learn actions use subfields wider than 64 bits. Bug #10576. Reported-by: James Schmidt <jschmidt@nicira.com> Signed-off-by: Ben Pfaff <blp@nicira.com>
2012-04-11 17:08:13 -07:00
NXST_FLOW reply:
])
OVS_VSWITCHD_STOP
AT_CLEANUP
tests: Add test for self-modifying learn action. CC: Paul Ingram <paul@nicira.com> Signed-off-by: Ben Pfaff <blp@nicira.com> Acked-by: Ethan Jackson <ethan@nicira.com>
2013-01-31 16:27:14 -08:00
# In this use of a learn action, the first packet in the flow creates
# a new flow that changes the behavior of subsequent packets in the
# flow.
AT_SETUP([learning action - self-modifying flow])
OVS_VSWITCHD_START
ADD_OF_PORTS([br0], 1, 2, 3)
# Set up flow table for TCPv4 port learning.
AT_CHECK([[ovs-ofctl add-flow br0 'actions=load:3->NXM_NX_REG0[0..15],learn(table=0,priority=65535,NXM_OF_ETH_SRC[],NXM_OF_VLAN_TCI[0..11],output:NXM_NX_REG0[0..15]),output:2']])
# Trace some packets arriving. The particular packets don't matter.
for i in 1 2 3 4 5 6 7 8 9 10; do
ovs-appctl netdev-dummy/receive p1 'in_port(1),eth(src=50:54:00:00:00:05,dst=50:54:00:00:00:07),eth_type(0x0800),ipv4(src=192.168.0.1,dst=192.168.0.2,proto=6,tos=0,ttl=64,frag=no),tcp(src=8,dst=9)'
done
# Check for the learning entry.
AT_CHECK([ovs-ofctl dump-flows br0 | ofctl_strip | sort], [0],
[[ n_packets=1, n_bytes=60, actions=load:0x3->NXM_NX_REG0[0..15],learn(table=0,priority=65535,NXM_OF_ETH_SRC[],NXM_OF_VLAN_TCI[0..11],output:NXM_NX_REG0[0..15]),output:2
priority=65535,vlan_tci=0x0000/0x0fff,dl_src=50:54:00:00:00:05 actions=output:3
NXST_FLOW reply:
]])
# Check that the first packet went out port 2 and the rest out port 3.
AT_CHECK(
[(ovs-ofctl dump-ports br0 2; ovs-ofctl dump-ports br0 3) | STRIP_XIDS], [0],
[OFPST_PORT reply: 1 ports
port 2: rx pkts=0, bytes=0, drop=0, errs=0, frame=0, over=0, crc=0
tx pkts=1, bytes=60, drop=0, errs=0, coll=0
OFPST_PORT reply: 1 ports
port 3: rx pkts=0, bytes=0, drop=0, errs=0, frame=0, over=0, crc=0
tx pkts=9, bytes=540, drop=0, errs=0, coll=0
])
OVS_VSWITCHD_STOP
AT_CLEANUP
Implement new "fin_timeout" action and "learn" feature. The "learn" action can create matching return flows. If those have a long timeout then it's a good idea to have a way to notice when in fact the flows have terminated. This new action and matching "learn" feature provides that way. Feature #8603. Signed-off-by: Ben Pfaff <blp@nicira.com>
2012-02-15 10:37:03 -08:00
AT_SETUP([learning action - fin_timeout feature])
# This is a totally artificial use of the "learn" action. The only purpose
# is to check that specifying fin_idle_timeout or fin_hard_timeout causes
# a corresponding fin_timeout action to end up in the learned flows.
Separate OpenFlow port numbers from datapath ones. In a future commit, we will make multiple bridges share a single backing datapath. Our simple mapping from datapath to OpenFlow port numbers won't work, since we'll want the same OpenFlow port numbers on different bridges. For example, the OFPP_LOCAL port must be the same on all bridges, but will have to be a different datapath port on the converged datapath. This commit makes it the responsibility of ofproto to assign the OpenFlow port numbers instead of doing a simple translation from the datapath ones. Signed-off-by: Justin Pettit <jpettit@nicira.com>
2012-09-28 17:56:07 -07:00
OVS_VSWITCHD_START(
[add-port br0 p1 -- set Interface p1 type=dummy ofport_request=1])
Implement new "fin_timeout" action and "learn" feature. The "learn" action can create matching return flows. If those have a long timeout then it's a good idea to have a way to notice when in fact the flows have terminated. This new action and matching "learn" feature provides that way. Feature #8603. Signed-off-by: Ben Pfaff <blp@nicira.com>
2012-02-15 10:37:03 -08:00
AT_CHECK([[ovs-ofctl add-flow br0 'actions=learn(fin_hard_timeout=10, fin_idle_timeout=5, NXM_OF_ETH_DST[]=NXM_OF_ETH_SRC[], output:NXM_OF_IN_PORT[])']])
ofproto/ofproto-dpif.c: Re-implement the ofproto/trace command Since the use of single datapath, all bridges belonging to the same type of datapath will use the same (single) datapath. This causes confusion in the current 'ofproto/trace' command. Especially, when given the unrelated 'bridge' and 'in_port' combination, the current implementation will still be able to process and give misleading output. Thusly, this patch changes the 'ofproto/trace' command syntax to formats shown as follow. ofproto/trace [datapath] odp_flow [-generate|packet] ofproto/trace bridge br_flow [-generate|packet] Also, this patch updates the tests and the manpages accordingly. Co-authored-by: Ben Pfaff <blp@nicira.com> Signed-off-by: Alex Wang <alexw@nicira.com> Signed-off-by: Ben Pfaff <blp@nicira.com>
2013-05-20 11:36:05 -07:00
AT_CHECK([ovs-appctl ofproto/trace ovs-dummy 'in_port(1),eth(src=50:54:00:00:00:05,dst=ff:ff:ff:ff:ff:ff),eth_type(0x0806),arp(sip=192.168.0.1,tip=192.168.0.2,op=1,sha=50:54:00:00:00:05,tha=00:00:00:00:00:00)' -generate], [0], [ignore])
Implement new "fin_timeout" action and "learn" feature. The "learn" action can create matching return flows. If those have a long timeout then it's a good idea to have a way to notice when in fact the flows have terminated. This new action and matching "learn" feature provides that way. Feature #8603. Signed-off-by: Ben Pfaff <blp@nicira.com>
2012-02-15 10:37:03 -08:00
AT_CHECK([ovs-ofctl dump-flows br0 table=1 | ofctl_strip], [0],
[NXST_FLOW reply:
table=1, dl_dst=50:54:00:00:00:05 actions=fin_timeout(idle_timeout=5,hard_timeout=10),output:1
])
OVS_VSWITCHD_STOP
AT_CLEANUP
Reference in New Issue Copy Permalink