We found this issue while running one of the inbound routing PTF tests in saidashvnet.py. Most likely the bug was introduced during refactoring of tunnel encapsulation code.
In case of inbound routing, overlay_dmac is not supposed to be modified. But, in inbound_routing.p4, when tunnel_encap action is called, the value of meta.overlay_data.dmac is zero and tunnel_encap action ends up incorrectly setting the overlay_dmac to zero.
We found this issue while running one of the inbound routing PTF tests in saidashvnet.py. Most likely the bug was introduced during refactoring of tunnel encapsulation code.
In case of inbound routing, overlay_dmac is not supposed to be modified. But, in inbound_routing.p4, when tunnel_encap action is called, the value of meta.overlay_data.dmac is zero and tunnel_encap action ends up incorrectly setting the overlay_dmac to zero.
tunnel_encap(hdr, meta, meta.overlay_data.dmac, meta.encap_data.underlay_dmac, meta.encap_data.underlay_smac, meta.encap_data.underlay_dip, meta.encap_data.underlay_sip, dash_encapsulation_t.VXLAN, meta.encap_data.vni);This fix will check for a non-zero overlay_dmac value before overwriting the customer dmac field in the packet header.