Re: [ovs-dev] Flow key update in conntrack/nat

[Valentine Sinitsyn]

Hi Joe,

On 11.01.2017 23:30, Joe Stringer wrote:

On 11 January 2017 at 02:47, Valentine Sinitsyn
 wrote:

Hi all,

I'm struggling to find an answer to a seemingly simple question: why does
"ct(nat)" action need to update the flow key after NAT (see
ovs_nat_update_key())?

My confusion comes from the following scenario. Consider the first
to-be-NATed packet coming. There is no datapath flow installed, so this
results in an upcall. The userspace part will then install a new datapath
flow (using original, unmodified flow key it got) and execute the action.
Subsequent packets will be handled in the kernel automatically, but again,
the ovs_nat_update_key() flow key will be silently discarded in
ovs_vport_receive().

So it looks like the modified flow key is never used. What am I missing
here?


This depends on your flow table. If another lookup needs to occur (eg,
ct(table=N,...) option), or the packet is sent to userspace
(sflow,ipfix, etc), then the updated flow key needs to be provided -
in datapath, recirc (if it triggers upcall) or userspace actions. Most
OVS actions in the datapath modify the key in-place so that it is
correct whenever it needs to be used; the key doesn't need to be
completely repopulated afresh when it is needed.

Thanks for answering.

So the point I was missing is that there could be other actions 
following 'ct(nat)', which may use the flow. Makes sense now.


Valentine
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] Flow key update in conntrack/nat

[Joe Stringer]

On 11 January 2017 at 02:47, Valentine Sinitsyn
 wrote:
> Hi all,
>
> I'm struggling to find an answer to a seemingly simple question: why does
> "ct(nat)" action need to update the flow key after NAT (see
> ovs_nat_update_key())?
>
> My confusion comes from the following scenario. Consider the first
> to-be-NATed packet coming. There is no datapath flow installed, so this
> results in an upcall. The userspace part will then install a new datapath
> flow (using original, unmodified flow key it got) and execute the action.
> Subsequent packets will be handled in the kernel automatically, but again,
> the ovs_nat_update_key() flow key will be silently discarded in
> ovs_vport_receive().
>
> So it looks like the modified flow key is never used. What am I missing
> here?

This depends on your flow table. If another lookup needs to occur (eg,
ct(table=N,...) option), or the packet is sent to userspace
(sflow,ipfix, etc), then the updated flow key needs to be provided -
in datapath, recirc (if it triggers upcall) or userspace actions. Most
OVS actions in the datapath modify the key in-place so that it is
correct whenever it needs to be used; the key doesn't need to be
completely repopulated afresh when it is needed.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] Flow key update in conntrack/nat

[Valentine Sinitsyn]

Hi all,

I'm struggling to find an answer to a seemingly simple question: why 
does "ct(nat)" action need to update the flow key after NAT (see 
ovs_nat_update_key())?


My confusion comes from the following scenario. Consider the first 
to-be-NATed packet coming. There is no datapath flow installed, so this 
results in an upcall. The userspace part will then install a new 
datapath flow (using original, unmodified flow key it got) and execute 
the action. Subsequent packets will be handled in the kernel 
automatically, but again, the ovs_nat_update_key() flow key will be 
silently discarded in ovs_vport_receive().


So it looks like the modified flow key is never used. What am I missing 
here?


Thanks,
Valentine Sinitsyn
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev