On 8 December 2016 at 13:43, Michael Kashin <[email protected]> wrote: > Hi, > I'm trying to use ofproto/trace to trace flows installed by OVN controller. > I start with a simple flow spec that I used in OVS before, I get to table 21 > when packet gets submitted to connection tracker and that's where trace > stops: > Datapath actions: ct(zone=2),recirc(0x9f) > > I've tried adding recirc_id along with the ct_state to the same flow but it > fails: > > # ovs-appctl ofproto/trace br-int > in_port=13,ip,dl_src=fa:16:3e:4f:2f:b8,nw_src=10.0.0.2,nw_dst=8.8.8.8,dl_dst=fa:16:3e:0d:df:ea,recirc_id=0x9f,ct_state="new|trk" > Bridge: br-int > Flow: > recirc_id=0x9f,ct_state=new|trk,ip,in_port=13,vlan_tci=0x0000,dl_src=fa:16:3e:4f:2f:b8,dl_dst=fa:16:3e:0d:df:ea,nw_src=10.0.0.2,nw_dst=8.8.8.8,nw_proto=0,nw_tos=0,nw_ecn=0,nw_ttl=0 > > Final flow: unchanged > Megaflow: recirc_id=0x9f,ip,in_port=13,nw_frag=no > Datapath actions: drop > Translation failed (No recirculation context), packet is dropped. > > > Am I on the right track? Is this something achievable?
I would suggest dropping the recirc_id; it is transient context that is kept around as long as a flow is flowing through OVS. You should be able to determine how your packets will flow through the tables by omitting recirc_id, and providing all of the flow fields that you know were available prior to the recirc() action. Depending on the flow table, often simply specifying the ct_state is enough. _______________________________________________ discuss mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
