Got it, so no way to do this in current ovs, thanks a lot. -----Original Message----- From: Pravin Shelar [mailto:pshe...@ovn.org] Sent: Monday, December 5, 2016 11:16 AM To: Yang, Yi Y <yi.y.y...@intel.com> Cc: Gerhard Stenzel <gsten...@linux.vnet.ibm.com>; Ben Pfaff <b...@ovn.org>; d...@openvswitch.org; ovs-discuss@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 Sun, Dec 4, 2016 at 5:57 PM, Yang, Yi Y <yi.y.y...@intel.com> wrote: > Let me explain my point in details. > > > +-------------------+ > +-------------------+ +-------------------+ > | vxlanX |<------------------------- >| vxlanY > | > |dst_port:6633 | |dst_port:6634 > | > +-------------------+ > +-------------------+ +--------------------+ > ^ > ^ > \ > / > \ > / > \ > / > \ > / > \ > / > \ > / > \ / > v v > +----------------------------------------+ > | vxlanZ | > | dst_port:6635 | > +-----------------------------------------+ > > I mean we should let openflow set dst_port in tunnel metadata although we > only can have one default dst_port in configuration, this will make the above > use case possible. Otherwise do we have any way to make sure the above case > can work? > > So I think it is important to use dst_port in tunnel metadata if have. > This is already there. Kernel interface for vxlan allows setting dst-port from tunnel metadata. But I do not think there is anyway to configure such tunnels using OVS. You can not control UDP port of the tunnel header using flow APIs. There is single port number (ingress and egress) associated with a tunnel port using OVSDB configuration. > -----Original Message----- > From: Pravin Shelar [mailto:pshe...@ovn.org] > Sent: Monday, December 5, 2016 9:01 AM > To: Yang, Yi Y <yi.y.y...@intel.com> > Cc: Gerhard Stenzel <gsten...@linux.vnet.ibm.com>; Ben Pfaff > <b...@ovn.org>; d...@openvswitch.org; ovs-discuss@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 Sat, Dec 3, 2016 at 10:05 PM, Yang, Yi Y <yi.y.y...@intel.com> wrote: >> 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. >> > I am not sure if I understand your concern. But let me clarify that all UDP > based tunnels need to create separate netdevice for each dst port. I do not > think we can handle multiple UDP ports on single tunnel device. > >> -----Original Message----- >> From: Pravin Shelar [mailto:pshe...@ovn.org] >> Sent: Friday, December 2, 2016 3:54 PM >> To: Yang, Yi Y <yi.y.y...@intel.com> >> Cc: Gerhard Stenzel <gsten...@linux.vnet.ibm.com>; Ben Pfaff >> <b...@ovn.org>; d...@openvswitch.org; ovs-discuss@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.y...@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. _______________________________________________ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
