In xlate_actions in ofproto-dpif-xlate.c, after thawing from frozen state,
it currently retrieves the tunnel metadata table from the original xbridge.
It should retrieve the tunnel metadata table from the thawed xbridge.

In OVN, this manifested as missing geneve option fields when receiving a
packet from localnet to br-int, then freezing (e.g. for NAT on a gateway
router or for distributed NAT), then attempting to send out a tunnel.

Signed-off-by: Mickey Spiegel <mickeys....@gmail.com>
---
 ofproto/ofproto-dpif-xlate.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/ofproto/ofproto-dpif-xlate.c b/ofproto/ofproto-dpif-xlate.c
index 2977be5..44fe3d1 100644
--- a/ofproto/ofproto-dpif-xlate.c
+++ b/ofproto/ofproto-dpif-xlate.c
@@ -5543,7 +5543,8 @@ xlate_actions(struct xlate_in *xin, struct xlate_out 
*xout)
 
     /* Tunnel metadata in udpif format must be normalized before translation. 
*/
     if (flow->tunnel.flags & FLOW_TNL_F_UDPIF) {
-        const struct tun_table *tun_tab = 
ofproto_dpif_get_tun_tab(xin->ofproto);
+        const struct tun_table *tun_tab =
+                                ofproto_dpif_get_tun_tab(ctx.xbridge->ofproto);
         int err;
 
         err = tun_metadata_from_geneve_udpif(tun_tab, 
&xin->upcall_flow->tunnel,
@@ -5558,7 +5559,8 @@ xlate_actions(struct xlate_in *xin, struct xlate_out 
*xout)
         /* If the original flow did not come in on a tunnel, then it won't have
          * FLOW_TNL_F_UDPIF set. However, we still need to have a metadata
          * table in case we generate tunnel actions. */
-        flow->tunnel.metadata.tab = ofproto_dpif_get_tun_tab(xin->ofproto);
+        flow->tunnel.metadata.tab =
+                                ofproto_dpif_get_tun_tab(ctx.xbridge->ofproto);
     }
     ctx.wc->masks.tunnel.metadata.tab = flow->tunnel.metadata.tab;
 
-- 
1.9.1

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

Reply via email to