ofproto-dpif: Maintain tun_id across action lists.
authorJesse Gross <jesse@nicira.com>
Tue, 15 Jan 2013 21:45:41 +0000 (13:45 -0800)
committerJesse Gross <jesse@nicira.com>
Wed, 16 Jan 2013 00:11:30 +0000 (16:11 -0800)
commitef506a7c003232eba1e5eb16e7a774ab5afd24e1
treea7c59acc8a9609e854081644be649a3724f9df2f
parent5dd165d3d86094b7f094752b1e5e001f6bf5c1b7
ofproto-dpif: Maintain tun_id across action lists.

Previously, a tunnel ID received on input would be used by default
on output if the packet was later sent out a tunnel.  This was not
actually intentional behavior - tunnel information is not supposed
to carry over.  However, it is useful in the case where move actions
are used to load the original tunnel ID into registers for further
processing or additional lookups in resubmits since otherwise the
information is lost before handling actions.

When the initial components for flow based tunneling were introduced
this behavior for tunnel headers caused problems since it resulted
in packets being sent to the IP address they were originally received
on.  All of this behavior was "fixed" in commit
47d4a9db26329f9d93eb945c1fcc0e248cf2656a (ofproto-dpif: Initialize
tunnel metadata in both 'flow' and 'base_flow'.), breaking the use
cases the require tun_id during action processing.

For the time being, at least, this restores the original behavior
for tun_id, while keeping the new behavior for the rest of the
tunnel headers.  The latter are not exposed through OpenFlow and
therefore do not have similar complications.  If we do expose these
headers then we might have to revist this.

Thanks to Ben Pfaff for identifying the commit that introduced the
problem.

Bug #14625

Reported-by: Michael Hu <humichael@vmware.com>
Signed-off-by: Jesse Gross <jesse@nicira.com>
ofproto/ofproto-dpif.c