[prev in list] [next in list] [prev in thread] [next in thread]
List: openvswitch-discuss
Subject: [ovs-discuss] surprising effects with exit v's drop
From: billy.o.mahony () intel ! com (O Mahony, Billy)
Date: 2015-06-30 14:46:59
Message-ID: 03135AEA779D444E90975C2703F148DC15A300CF () IRSMSX107 ! ger ! corp ! intel ! com
[Download RAW message or body]
Hi All,
I am getting very surprising (to me at least) effects with the following
flows installed.
I am seeing packets forwarded when I expect them to be dropped and dropped
when I expect them to be forwarded.
Here is my flow table:
[14:22 ]$ ovs-ofctl -O OpenFlow13 dump-flows br0
OFPST_FLOW reply (OF1.3) (xid=0x2):
cookie=0x0, duration=2.860s, table=0, n_packets=0, n_bytes=0, priority=1 \
actions=goto_table:1 cookie=0x0, duration=2.845s, table=1, n_packets=0, n_bytes=0, \
priority=1,in_port=1 actions=write_actions(output:2),write_metadata:0x2,goto_table:2 \
cookie=0x0, duration=2.834s, table=1, n_packets=0, n_bytes=0, priority=1,in_port=2 \
actions=write_actions(output:1),write_metadata:0x1,goto_table:2 cookie=0x0, \
duration=2.815s, table=2, n_packets=0, n_bytes=0, priority=1 actions=exit
For a packet ingressing on port1 I'm expecting it to be egressed on port2.
This does not happen however (using a hardware traffic generator) and the
packet is dropped. ofproto/trace seems to expect this to happen as it says
"Datapath actions: drop" at the end of its output:
[14:22 ]$ ovs-appctl -t /usr/local/var/run/openvswitch/ovs-vswitchd.61474.ctl \
ofproto/trace br0 in_port=1
Bridge: br0
Flow: in_port=1,vlan_tci=0x0000,dl_src=00:00:00:00:00:00,dl_dst=00:00:00:00:00:00,dl_type=0x0000
Rule: table=0 cookie=0 priority=1
OpenFlow actions=goto_table:1
Resubmitted flow: \
in_port=1,vlan_tci=0x0000,dl_src=00:00:00:00:00:00,dl_dst=00:00:00:00:00:00,dl_type=0x0000
Resubmitted regs: reg0=0x0 reg1=0x0 reg2=0x0 reg3=0x0 reg4=0x0 reg5=0x0 \
reg6=0x0 reg7=0x0 Resubmitted odp: drop
Resubmitted megaflow: recirc_id=0,in_port=1,dl_type=0x0000
Rule: table=1 cookie=0 priority=1,in_port=1
OpenFlow actions=write_actions(output:2),write_metadata:0x2,goto_table:2
Resubmitted flow: \
metadata=0x2,in_port=1,vlan_tci=0x0000,dl_src=00:00:00:00:00:00,dl_dst=00:00:00:00:00:00,dl_type=0x0000
Resubmitted regs: reg0=0x0 reg1=0x0 reg2=0x0 reg3=0x0 reg4=0x0 \
reg5=0x0 reg6=0x0 reg7=0x0 Resubmitted odp: drop
Resubmitted megaflow: recirc_id=0,in_port=1,dl_type=0x0000
Rule: table=2 cookie=0 priority=1
OpenFlow actions=exit
Final flow: metadata=0x2,in_port=1,vlan_tci=0x0000,dl_src=00:00:00:00:00:00,dl_dst=00:00:00:00:00:00,dl_type=0x0000
Megaflow: recirc_id=0,in_port=1,dl_type=0x0000
Datapath actions: drop <<<< SURPRISE!
If I then replace the action in table 2 to 'exit', packets from port1 are indeed
egressed on port2 (again verified by hardware packet generator) and apparently
as predicted by ofproto/trace.
[14:22 ]$ ovs-ofctl -O OpenFlow13 add-flow br0 "table=2,priority=1 actions=drop"
[14:25 ]$ ovs-appctl -t /usr/local/var/run/openvswitch/ovs-vswitchd.61474.ctl \
ofproto/trace br0 in_port=1
Bridge: br0
Flow: in_port=1,vlan_tci=0x0000,dl_src=00:00:00:00:00:00,dl_dst=00:00:00:00:00:00,dl_type=0x0000
Rule: table=0 cookie=0 priority=1
OpenFlow actions=goto_table:1
Resubmitted flow: \
in_port=1,vlan_tci=0x0000,dl_src=00:00:00:00:00:00,dl_dst=00:00:00:00:00:00,dl_type=0x0000
Resubmitted regs: reg0=0x0 reg1=0x0 reg2=0x0 reg3=0x0 reg4=0x0 reg5=0x0 \
reg6=0x0 reg7=0x0 Resubmitted odp: drop
Resubmitted megaflow: recirc_id=0,in_port=1,dl_type=0x0000
Rule: table=1 cookie=0 priority=1,in_port=1
OpenFlow actions=write_actions(output:2),write_metadata:0x2,goto_table:2
Resubmitted flow: \
metadata=0x2,in_port=1,vlan_tci=0x0000,dl_src=00:00:00:00:00:00,dl_dst=00:00:00:00:00:00,dl_type=0x0000
Resubmitted regs: reg0=0x0 reg1=0x0 reg2=0x0 reg3=0x0 reg4=0x0 \
reg5=0x0 reg6=0x0 reg7=0x0 Resubmitted odp: drop
Resubmitted megaflow: recirc_id=0,in_port=1,dl_type=0x0000
Rule: table=2 cookie=0 priority=1
OpenFlow actions=drop
Final flow: metadata=0x2,in_port=1,vlan_tci=0x0000,dl_src=00:00:00:00:00:00,dl_dst=00:00:00:00:00:00,dl_type=0x0000
Megaflow: recirc_id=0,in_port=1,dl_type=0x0000
Datapath actions: 3
This is all pretty surprising to me though obviously there could be some
subtleties I am missing. I'd appreciate and thoughts or tips from the
community.
Finally, I am using dpdk enabled NICs.
[14:25 ]$ ovs-ofctl show br0
OFPT_FEATURES_REPLY (xid=0x2): dpid:000090e2ba69d620
n_tables:254, n_buffers:256
capabilities: FLOW_STATS TABLE_STATS PORT_STATS QUEUE_STATS ARP_MATCH_IP
actions: output enqueue set_vlan_vid set_vlan_pcp strip_vlan mod_dl_src mod_dl_dst \
mod_nw_src mod_nw_dst mod_nw_tos mod_tp_src mod_tp_dst 1(dpdk0): \
addr:90:e2:ba:69:d6:20 config: 0
state: 0
current: 10GB-FD
supported: 1GB-HD 1GB-FD 10GB-FD COPPER FIBER AUTO_PAUSE
speed: 10000 Mbps now, 10000 Mbps max
2(dpdk1): addr:90:e2:ba:69:d6:21
config: 0
state: 0
current: 10GB-FD
supported: 1GB-HD 1GB-FD 10GB-FD COPPER FIBER AUTO_PAUSE
speed: 10000 Mbps now, 10000 Mbps max
LOCAL(br0): addr:90:e2:ba:69:d6:20
config: PORT_DOWN
state: LINK_DOWN
current: 10MB-FD COPPER
speed: 10 Mbps now, 0 Mbps max
OFPT_GET_CONFIG_REPLY (xid=0x4): frags=normal miss_send_len=0
[14:38 ]$ ovs-vsctl show
290a84b5-431a-4f1f-ac17-df82abd72bba
Bridge "br0"
Port "dpdk0"
Interface "dpdk0"
type: dpdk
Port "br0"
Interface "br0"
type: internal
Port "dpdk1"
Interface "dpdk1"
type: dpdk
[14:38 ]$ \
Thanks,
Billy O'Mahony.
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic