[ovs-discuss] tracing flows with ct state

[Joe Stringer]

On 8 December 2016 at 13:43, Michael Kashin <mmkashin at gmail.com> 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.