From: Sridhar Samudrala <samudrala.sridhar@gmail•com>
To: Stephen Hemminger <stephen@networkplumber•org>
Cc: David Stevens <dlstevens@us•ibm.com>,
David Miller <davem@davemloft•net>,
netdev@vger•kernel.org, netdev-owner@vger•kernel.org
Subject: Re: [PATCH net] vxlan: revert per-vxlan port
Date: Mon, 20 May 2013 19:53:59 -0700 [thread overview]
Message-ID: <519AE1C7.5060807@gmail.com> (raw)
In-Reply-To: <20130520171304.06c6ed00@nehalam.linuxnetplumber.net>
On 5/20/2013 5:13 PM, Stephen Hemminger wrote:
> On Mon, 20 May 2013 16:59:44 -0700
> Sridhar Samudrala <samudrala.sridhar@gmail•com> wrote:
>
>> On 5/20/2013 11:30 AM, Stephen Hemminger wrote:
>>> On Mon, 20 May 2013 14:15:59 -0400
>>> David Stevens <dlstevens@us•ibm.com> wrote:
>>>
>>>>> From: Stephen Hemminger <stephen@networkplumber•org>
>>>>
>>>>> \This commit 823aa873bc782f1c51b1ce8ec6da7cfcaf93836e
>>>>> Author: stephen hemminger <stephen@networkplumber•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@us•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
next prev parent reply other threads:[~2013-05-21 2:54 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-20 17:30 [PATCH net] vxlan: revert per-vxlan port Stephen Hemminger
2013-05-20 18:15 ` David Stevens
2013-05-20 18:30 ` Stephen Hemminger
2013-05-20 23:59 ` Sridhar Samudrala
2013-05-21 0:13 ` Stephen Hemminger
2013-05-21 2:53 ` Sridhar Samudrala [this message]
2013-05-22 22:08 ` David Miller
2013-05-22 23:18 ` David Stevens
2013-05-23 0:39 ` Stephen Hemminger
2013-05-23 2:14 ` David Stevens
2013-05-23 17:08 ` Stephen Hemminger
2013-05-23 18:45 ` David Stevens
2013-05-23 19:18 ` Stephen Hemminger
2013-05-23 20:06 ` David Stevens
2013-05-23 22:35 ` Sridhar Samudrala
2013-06-03 5:40 ` David Miller
2013-06-03 15:15 ` Stephen Hemminger
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=519AE1C7.5060807@gmail.com \
--to=samudrala.sridhar@gmail$(echo .)com \
--cc=davem@davemloft$(echo .)net \
--cc=dlstevens@us$(echo .)ibm.com \
--cc=netdev-owner@vger$(echo .)kernel.org \
--cc=netdev@vger$(echo .)kernel.org \
--cc=stephen@networkplumber$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox