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 16:06:03 -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 
03:18:04 PM:

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

        If you're saying that using the dstport changes the
listen port, or adds another listen port, then I think that
behaviour is wrong and should be reverted.
        An admin should be able to specify the source and destination
ports independently of each other. If dstport has a side-effect that
is unrelated to changing the destination port, that's what I'd call
"confusing."
        IMHO, "port" should change the listen port (only) and "dstport"
should change the send port (only). And yes, both of those should allow
multiple ports, and destinations. So, binding should be a list of
the form: "[IP:]port[,[IP:]port]*" and destinations should be the same
as in the fdb, allowing multiple destinations and different ports, and
different vni's. It should be simply a "default" fdb entry in all 
respects.

> 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

        Yes, I wholeheartedly approve of this feature. It simply is
not the only use case for wanting different destination ports, so is
not linked to the dstport feature, in my opinion.

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

        So, you're requiring an extra bind port (and the specific port the
remote device is using may not be available on the local machine) and an
extra hop through a bridge, when all you really want as an admin is to say
"listen on this port, send on that port" without that also meaning you
have to know and specify the MAC address of every possible remote VM.

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

        Sure. I think multiple listen ports is a good idea, but it is
not the only reason for wanting a different destination port, and not
a reason to link destination and listen ports.
 
> The dstport option is not in a released kernel or iproute.

I don't think we're going to get consensus here. If you intend the
artificial requirement that the bind and listen ports be the same,
and that admins need to jump through hoops to get the reasonable
effect of making them different, then I simply disagree with you.

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