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: <20130523121804.6b7450a3@nehalam.linuxnetplumber.net>
Date:	Thu, 23 May 2013 12:18:04 -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 Thu, 23 May 2013 14:45:51 -0400
David Stevens <dlstevens@...ibm.com> wrote:

> Stephen Hemminger <stephen@...workplumber.org> wrote on 05/23/2013 
> 01:08:54 PM:
> 
> > 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.
> 
> This does not "work" in net-next, either. If you set the one-and-only bind
> port to one port and the one and only send port to another port on both
> systems, they can't talk to each other in net-next, either. If you 
> separately
> have it listen on multiple ports, and if potential non-linux systems 
> you're
> talking to can do that too, then you can configure it to work, but the 
> extra
> listen ports are entirely unnecessary.

With the patch davem already included, the dstport is enough
to add additional listener.


> 
> You're starting with the assumption, which I disagree with, that the 
> receive
> and send ports need to be the same. In fact, for two systems listening on
> different ports to talk to each other, they *must* be different. It 
> doesn't
> require multiple ports, it only requires the listen and send ports be 
> *different*.


Another use case is:
 # ip link add vxlan-old type vxlan id 42 group 239.1.1.1 dev eth0
 # ip link add vxlan-new type vxlan id 42 group 239.1.1.1 dev eth0 dstport 4789

This also works with net-next and not with 3.10



> 
> If I have two existing systems, one listening on port 8472 and one 
> listening
> on port 4789, and I want to connect them, how would you do that?

You can either do:
 A. Define two vxlan's and route or bridge them
 B. Define one vxlan with a destination port and add exception FDB entry
    to talk to the outlier


 Yes, you
> *can* add individual MAC entries with different ports for all VMs 
> connected
> on both machines, but if you have 2 hosts and 10,000 MAC addresses, that's
> a ridiculous waste. If you simply don't know all the MAC addresses on the
> remote machine, you can't do it. But if you can set the destination port 
> for
> the default fdb entry, which is what dstport does, then you can do both.

User's may reasonably want to define multiple overlay VXLAN's each
on a different port, or create one VXLAN and add excptions.


> 
> The dstport and dst are simply the default entry for the fdb table, used 
> if
> there is no exact match in the fdb. They should have every capability to 
> use
> alternate data that the fdb table does.
> 
> > 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.
> 
> I don't know what confusion you're concerned about here. How can anyone
> be confused by packets going to a different destination port when they use
> an option "dstport XXXX"? (!?!?!?!?)

The dstport option is not in a released kernel or iproute.

> 
> You can't really prohibit people from using VXLAN however they choose to.
> It simply means people wanting to do more interesting things will
> have to patch your code, jump through hoops to edit packets with 
> netfilter,
> or use alternative implementations that are more flexible. None of those
> things benefits VXLAN on linux.
> 
>                                                                 +-DLS
> 

--
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