netdev - Re: [PATCH net] vxlan: revert per-vxlan port

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20130523100854.6c9749d6@nehalam.linuxnetplumber.net>
Date:	Thu, 23 May 2013 10:08:54 -0700
From:	Stephen Hemminger <stephen@...workplumber.org>
To:	David Stevens <dlstevens@...ibm.com>
Cc:	David Miller <davem@...emloft.net>, netdev@...r.kernel.org,
	netdev-owner@...r.kernel.org
Subject: Re: [PATCH net] vxlan: revert per-vxlan port

On Wed, 22 May 2013 22:14:39 -0400
David Stevens <dlstevens@...ibm.com> wrote:

> Stephen Hemminger <stephen@...workplumber.org> wrote on 05/22/2013 
> 08:39:54 PM:
> 
> > The per-vxlan device stuff is the issue. I don't think it works
> > as is in 3.10 because there is no real way to use it to receive.
> > And don't want to let it out broken. By reverting that part, we avoid
> > raising false expectations.
> > 
> 
> Of course you can use it to receive; the remote hosts can be
> listening on a different port and this is the only mechanism
> to send to those if there are not fdb entries on the local machine.
> 
> So, for example, host A:
> binds to 1234
> has no fdb entries, but sets the default remote port to 4789
> 
> host B
> binds to 4789
> has no fdb entries and sets the default remote port to 1234
> 
> ...or you have an agent listening on a multicast address with port 5429
> and the agent's job is to dynamically populate the fdb tables of any
> hosts that don't have matching entries. All the VXLAN instances bind
> to, say 4789, and the agent binds to port 5429. The agent receives a
> packet, and adds an entry to the fdb table on the sending host where
> the destination is the actual VXLAN receiver with port 4789. But the
> default port on all of them for this kind of set-up is correctly the
> different 5429, not 4789.
> 
> These configurations have nothing to do with multiple listen ports,
> and reverting the patch prohibits an admin from doing it at all.
> In the first set up, you can link two segments on different ports
> without knowing any destination MAC addresses. In the second, you
> can separate traffic not matching any destination MAC from traffic
> with a known destination, and use that to fill forwarding tables.
> 
> I know these configurations don't match your sense of how VXLAN
> should be used, but these are not "broken", do receives perfectly fine,
> and have no dependency at all on multiple listen ports. I don't know
> what  "false expectations" you think are there-- I think anyone
> changing the default destination port to a different value from
> the binding port simply expects that transmits using the default
> will go to one port and received packets will go to another. Deciding
> in advance that that is never appropriate is short-sighted; that
> decision belongs with the admin setting it up. Reverting the patch
> removes that choice.
> 
> 
>                                                         +-DLS
> 

Let's go back to basic use cases.
User wants to setup a vxlan between two hosts with custom port
   On both hosts, he/she does:
 # ip li add vxlan0 type vxlan id 42 group 239.1.1.1 dev eth0 dstport 4789

With net-next it works, with 3.10 it doesn't.

Sure it works if they have your agent, or manually configure N-M static FDB
entries, but that is corner case.

No matter if Dave decides to the revert the kernel part or not, I am pulling the option
from 3.10 version of iproute to avoid user confusion.




--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html