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 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 move to register use case. 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 <[email protected]> Signed-off-by: Jesse Gross <[email protected]> --- ofproto/ofproto-dpif.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/ofproto/ofproto-dpif.c b/ofproto/ofproto-dpif.c index bc54122..c0a54f3 100644 --- a/ofproto/ofproto-dpif.c +++ b/ofproto/ofproto-dpif.c @@ -6094,11 +6094,14 @@ action_xlate_ctx_init(struct action_xlate_ctx *ctx, ovs_be16 initial_tci, struct rule_dpif *rule, uint8_t tcp_flags, const struct ofpbuf *packet) { + ovs_be64 initial_tun_id = flow->tunnel.tun_id; + ctx->ofproto = ofproto; ctx->flow = *flow; memset(&ctx->flow.tunnel, 0, sizeof ctx->flow.tunnel); ctx->base_flow = ctx->flow; ctx->base_flow.vlan_tci = initial_tci; + ctx->flow.tunnel.tun_id = initial_tun_id; ctx->rule = rule; ctx->packet = packet; ctx->may_learn = packet != NULL; -- 1.7.9.5 _______________________________________________ dev mailing list [email protected] http://openvswitch.org/mailman/listinfo/dev
