[ovs-discuss] ovs-conntrack action ordering?

Joe Stringer joestringer at nicira.com
Thu Jun 25 09:05:20 UTC 2015


Hi John,

Thanks for reporting this. It sounds like a bug. As an OpenFlow user,
It would be surprising for the order of these actions in the action
list to be rearranged like you report. For many fields this doesn't
matter (eg, if you only write IP then write TCP port), however for
conntrack, the order is more important - when you change the IP
address affects how the connection is tracked.  So the flow generation
for the first rule looks wrong from that perspective.

The core problem here is that while processing the actions list, many
of the "set_field" operations are deferred until the end of the
processing, whereas conntrack action is not. I think we need to come
up with some way to ensure that the flow changes are committed before
adding the conntrack action to the datapath actions list. I suspect
much of the code is already there for this, it just needs to be hooked
up correctly.

For the second flow, in some ways I'm inclined to go with the same
approach - Commit the MPLS before committing the conntrack action.
Also, I don't know what you're expecting the connection tracker to do
when it receives MPLS packets. I doubt that the connection tracker
would understand how to track MPLS packets or associate them with
connections. I'm not sure what behaviour you're getting today, but I
would expect all such packets to come back with conn_state=+trk+inv
(ie, invalid). What does it even mean to connection-track MPLS
packets?

On 24 June 2015 at 18:12, John Hurley <john.hurley at netronome.com> wrote:
> Hi,
>
> I have been playing about with ovs-conntrack and noticed an issue that could
> be a bug. Either that or my understanding is incorrect and would appreciate
> clarification.
>
> When we add a rule with a ct(recirc) action I notice that the call to
> Conntrack is always the first action in the kernel rule that is created. In
> ofproto-dpif-xlate.c a call to compose_conntrack_action() will append a
> nl_msg for this action, then call recirculate which uses
> commit_odp_actions() to add messages for previous actions before adding its
> own recirc action to kernel rule action list.  However, I have also noticed
> that when a push mpls action is added that this commit_odp_actions()
> function is also called which can affect the tuples sent to nf_conntrack.
>
> e.g. adding the rule:
> ovs-ofctl add-flow br0
> "conn_state=-trk,action=set_field:1.2.3.4->nw_dst,ct(recirc)"
>
> will result in a kernel rule with actions of order 'ct, set dst ip, recirc'
> and the sk_buff sent to nf_conntrack_in will have the source and destination
> IP addresses of the matching packet.
>
>
> adding the rule:
> ovs-ofctl add-flow br0
> "conn_state=-trk,action=set_field:1.2.3.4->nw_dst,push_mpls:0x8847,ct(recirc)"
>
> will have actions ordered 'set dst ip, ct, push mpls, recirc' and the
> destination IP sent into nf_conntrack will be 1.2.3.4
>
> Can you clarify if this discrepancy is a bug? Also, can you clarify what is
> the correct way ovs should support Conntrack in an action list? For example,
> in the first rule, is it correct that Conntrack should be applied on the
> input packet tuples or should the set field be applied before Conntrack as
> it appears before it in the ovs-ofctl rule?
>
> Thanks,
> John
>
>
>
> _______________________________________________
> discuss mailing list
> discuss at openvswitch.org
> http://openvswitch.org/mailman/listinfo/discuss
>



More information about the discuss mailing list