[ovs-discuss] Anybody knows how we can dynamically change vxlan dst_port by openflow load, move or set_field action?

Yang, Yi Y yi.y.yang at intel.com
Sun Dec 4 06:05:35 UTC 2016


Hi, Pravin

I'm confused, I think dst_port is also for local UDP socket for vxlan port, what if I have dst_port 6634 on one side (machine A) vxlan port and have dts_port 6635 on the other side (machine B)?

My point is vxlan should have ability to set different dst_port for different counterparts, in that way, one vxlan port can communicate with multiple counterpart vxlan ports with different dst_ports.

Otherwise, we only can use the same dst_port for all the vxlan ports.

-----Original Message-----
From: Pravin Shelar [mailto:pshelar at ovn.org] 
Sent: Friday, December 2, 2016 3:54 PM
To: Yang, Yi Y <yi.y.yang at intel.com>
Cc: Gerhard Stenzel <gstenzel at linux.vnet.ibm.com>; Ben Pfaff <blp at ovn.org>; dev at openvswitch.org; ovs-discuss at openvswitch.org
Subject: Re: [ovs-discuss] Anybody knows how we can dynamically change vxlan dst_port by openflow load, move or set_field action?

On Wed, Nov 30, 2016 at 4:41 PM, Yang, Yi Y <yi.y.yang at intel.com> wrote:
> I think this issue is not that simple. It depends on how you use it.
>
> For normal use cases, a tunnel port will terminate the tunnel traffic, so a packet sent to a tunnel port will never be from another tunnel port, so no tunnel metadata is available for the first packet, but for the packets which are from the counterpart tunnel port (which is another host), I think this tunnel port will keep the tunnel metadata for the traffic so that it can use src_port as dst_port for the packets sent back to the counterpart tunnel port. So the original source code makes sense, it works well.
>
> But for your use case (including the case I reported), you're send the 
> packet from GENEVE port to VXLAN or from VXLAN to GENEVE, the tunnel 
> metadata for GENEVE shouldn't be used by VXLAN, vice versa, but how 
> can we pull this off? Actually this is a special use case, ovs doesn't 
> realize we can use it in this way :-)
>
>
I think there are two issues.
1. vxlan should not use dst-port from tunnel metadata.
2. vswitchd should set correct dst-port for tunnel metadata.

We can not change vxlan at this point since it is userspace API. But it is easy to fix userspace to set consistent dst-port for given tunnel port.
Can you try attached patch? If it works I will submit formal patch.

Thanks.


More information about the discuss mailing list