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

173 lines
9.5 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)
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 actions=learn(table=1,NXM_OF_VLAN_TCI[0..11],NXM_OF_ETH_DST[]=NXM_OF_ETH_SRC[],output:NXM_OF_IN_PORT[],load:0x000a->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
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],
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: OpenFlow10+table_id,NXM+table_id
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[])
ip,actions=learn(eth_type=0x800,NXM_OF_IP_DST[])
]])
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,eth_type=0x800,load:0x00000005->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[])']],
[1], [],
[[ovs-ofctl: load:5->NXM_OF_IP_DST[]: cannot specify destination field ip_dst because prerequisites are not satisfied
]])
AT_CHECK([[ovs-ofctl parse-flow 'actions=learn(load:NXM_OF_IP_DST[]->NXM_NX_REG1[])']],
[1], [],
[[ovs-ofctl: load:NXM_OF_IP_DST[]->NXM_NX_REG1[]: cannot specify source field ip_dst because prerequisites are not satisfied
]])
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(
[add-port br0 eth0 -- set Interface eth0 type=dummy -- \
add-port br0 eth1 -- set Interface eth1 type=dummy -- \
add-port br0 eth2 -- set Interface eth2 type=dummy])
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.
test-openflowd: Remove. Some users were still confused by its presence.
2011-10-24 10:36:01 -07:00
AT_CHECK([ovs-appctl ofproto/trace br0 '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)' -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: 2,0,1
])
# 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
table=1, hard_timeout=60,vlan_tci=0x0000/0x0fff,dl_dst=50:54:00:00:00:05 actions=output:3
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.)
test-openflowd: Remove. Some users were still confused by its presence.
2011-10-24 10:36:01 -07:00
AT_CHECK([ovs-appctl ofproto/trace br0 '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
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
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.
test-openflowd: Remove. Some users were still confused by its presence.
2011-10-24 10:36:01 -07:00
AT_CHECK([ovs-appctl ofproto/trace br0 '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)' -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,0,1
])
# 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
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
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
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(
[add-port br0 eth0 -- set Interface eth0 type=dummy -- \
add-port br0 eth1 -- set Interface eth1 type=dummy -- \
add-port br0 eth2 -- set Interface eth2 type=dummy])
# 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.
AT_CHECK([ovs-appctl ofproto/trace br0 '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)' -generate], [0], [stdout])
AT_CHECK([tail -1 stdout], [0], [Datapath actions: 2,0,1
])
# Check for the learning entry.
AT_CHECK([ovs-ofctl dump-flows br0 table=1 | ofctl_strip | sort], [0], [dnl
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
NXST_FLOW reply:
])
OVS_VSWITCHD_STOP
AT_CLEANUP
AT_SETUP([learning action - TCPv6 port learning])
OVS_VSWITCHD_START(
[add-port br0 eth0 -- set Interface eth0 type=dummy -- \
add-port br0 eth1 -- set Interface eth1 type=dummy -- \
add-port br0 eth2 -- set Interface eth2 type=dummy])
# 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.
AT_CHECK([ovs-appctl ofproto/trace br0 '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)' -generate], [0], [stdout])
AT_CHECK([tail -1 stdout], [0], [Datapath actions: 2,0,1
])
# 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
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]]
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
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.
OVS_VSWITCHD_START
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[])']])
AT_CHECK([ovs-appctl ofproto/trace br0 '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])
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