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]

Date:	Thu, 23 May 2013 14:45:51 -0400
From:	David Stevens <dlstevens@...ibm.com>
To:	Stephen Hemminger <stephen@...workplumber.org>
Cc:	David Miller <davem@...emloft.net>, netdev@...r.kernel.org,
	netdev-owner@...r.kernel.org
Subject: Re: [PATCH net] vxlan: revert per-vxlan port

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.

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

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

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"? (!?!?!?!?)

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