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:	Mon, 20 May 2013 19:53:59 -0700
From:	Sridhar Samudrala <samudrala.sridhar@...il.com>
To:	Stephen Hemminger <stephen@...workplumber.org>
CC:	David Stevens <dlstevens@...ibm.com>,
	David Miller <davem@...emloft.net>, netdev@...r.kernel.org,
	netdev-owner@...r.kernel.org
Subject: Re: [PATCH net]  vxlan: revert per-vxlan port

On 5/20/2013 5:13 PM, Stephen Hemminger wrote:
> On Mon, 20 May 2013 16:59:44 -0700
> Sridhar Samudrala <samudrala.sridhar@...il.com> wrote:
>
>> On 5/20/2013 11:30 AM, Stephen Hemminger wrote:
>>> On Mon, 20 May 2013 14:15:59 -0400
>>> David Stevens <dlstevens@...ibm.com> wrote:
>>>
>>>>> From: Stephen Hemminger <stephen@...workplumber.org>
>>>>    
>>>>> \This commit 823aa873bc782f1c51b1ce8ec6da7cfcaf93836e
>>>>> Author: stephen hemminger <stephen@...workplumber.org>
>>>>> Date:   Sat Apr 27 11:31:57 2013 +0000
>>>>>
>>>>>       vxlan: allow choosing destination port per vxlan
>>>>>
>>>>> is broken revert it. The change allowed setting per port for transmit
>>>>> but did not add additional listening sockets, which made any vxlan's
>>>>> defined with non-default port send only.
>>>> This allows you to specify a different default port for
>>>> transmits, which is what you want to do if your own instance
>>>> of VXLAN is the odd one. I don't see any requirement for multiple
>>>> listen ports for that to be useful, since those sending to you
>>>> can have complete fdb tables even if the local instance doesn't
>>>> and relies on the default. Not to mention using an agent to
>>>> fill the fdb triggered by packets sent to the default, so the
>>>> receiver is not necessarily even a VXLAN instance. The receiver
>>>> side and transmit side ports can be completely independent of
>>>> each other, as in any other client-server system.
>>> Vxlan's are a weird beast. They can be viewed as either bridge like
>>> entities or tunnel like entities. I view them more as bridge type
>>> devices where user configures two hosts with equivalent values and
>>> they learn about each other. In that case the code in 3.10 is broken;
>>> but the version with the learning in net-next works.
>>>
>>> Your view is that VXLAN's are more like tunnels, where each host
>>> has static entries to know about every other host. In that mode,
>>> 3.10 is useable, but the same effect can be had by defining static
>>> neighbour entries.
>> how can we send to a different dst port using static neighbor entries?
>>
>> Thanks
>> Sridhar
> It is part of this commit in 3.10 already.
>
> commit 6681712d67eef14c4ce793561c3231659153a320
> Author: David Stevens <dlstevens@...ibm.com>
> Date:   Fri Mar 15 04:35:51 2013 +0000
>
>      vxlan: generalize forwarding tables
>      
>      This patch generalizes VXLAN forwarding table entries allowing an administrator
>      to:
>          1) specify multiple destinations for a given MAC
>          2) specify alternate vni's in the VXLAN header
>          3) specify alternate destination UDP ports
>          4) use multicast MAC addresses as fdb lookup keys
>          5) specify multicast destinations
>          6) specify the outgoing interface for forwarded packets
>      
>
OK. I am aware of specifying dst port via static fdb(forwarding table) 
entries.
I was confused when you said neighbor entries.

Thanks
Sridhar

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