On Thu, 24 Nov 2016 12:57:40 +0000, Yang, Yi Y wrote: > I noticed vxlan module always uses tp_dst from tunnel metadata in > preference to vxlan->cfg.dst_port, this isn't the result we want in > some use cases, for example, if we create two vxlan port which have > different dst_port, when we forward the packet from the first vxlan > port to the second one, we need the packet should be sent out with > the second vxlan port's dst_port as tp_dst, but current vxlan module > will use that one from the first vxlan port, the source code in vxlan > module and our experiment have confirmed this.
Ah, okay. That was not clear from the previous mail. And I don't follow the ovs-discussion list. > The line in file datapath/linux/compat/vxlan.c is here: > > dst_port = info->key.tp_dst ? : vxlan->cfg.dst_port; > > Anybody knows how we can change this? The below change seems more > reasonable to me, or do we have some ways to dynamically change it by > openflow actions? > > dst_port = vxlan->cfg.dst_port ? : info->key.tp_dst; As I explained, this is wrong. Probably ovs should clear the metadata that don't have "flow" specified in the tunnel options when outputting to a tunnel. But that's a job for the openflow translation layer, not for the kernel datapath. Meanwhile, as a workaround, you should be able to set the destination port in the openflow rule. Won't help for the NORMAL action, though. Jiri _______________________________________________ sfc-dev mailing list [email protected] https://lists.opendaylight.org/mailman/listinfo/sfc-dev
