From: Stephen Hemminger <shemminger@vyatta.com>
To: David Stevens <dlstevens@us.ibm.com>
Cc: David Miller <davem@davemloft.net>, netdev@vger.kernel.org
Subject: Re: [PATCH net-next] add DOVE extensions for VXLAN
Date: Tue, 13 Nov 2012 14:41:48 -0800 [thread overview]
Message-ID: <20121113144148.66a86bc7@nehalam.linuxnetplumber.net> (raw)
In-Reply-To: <OFD9622F46.08427B4F-ON85257AB5.00792B0C-85257AB5.007B6F17@us.ibm.com>
On Tue, 13 Nov 2012 17:28:17 -0500
David Stevens <dlstevens@us.ibm.com> wrote:
> Stephen Hemminger <shemminger@vyatta.com> wrote on 11/13/2012 04:28:42 PM:
>
> >
> > There are some issues with this.
> > 1. DOVE flag is mixing multiple functions (arp and route) together,
> > users may want one without the other.
>
> I can separate these.
>
> > 2. There is an implicit assumption that IP stack has valid IP address
> > in the tenant network (vxlan). This is rarely the case. For security
> > and other reasons, in my opinion the best practice is not to have
> > the bridge as part of the tenant network.
>
> No, actually for testing I didn't set an IP address on the tunnel
> endpoint at all. The neighbor table entries must be in the domain, but
> they are only used within the domain when the tunnel endpoint is on a
> bridge and the host has no IP address on that interface.
>
> > 3. Misses might be common and this could easily be used to DoS the host
> > from a malicious guest.
>
> Yes. The management piece can add forwarding table entries with
> "0.0.0.0" as the dst IP address to disable MAC misses, and neighbor
> table entries to disable IP misses, but it is our intention to have all
> reachable destinations with both forwarding table and neighbor table
> entries and no learning or multicast address (ie, no forwarding of
> anything
> that isn't in the forwarding table). And yes, we want a notification
> for every miss packet.
> Someone who doesn't want all of them shouldn't use this feature.
> If we're dropping the "dove" flag in favor of individual flags for each
> feature, then I could make this into "l2miss" and "l3miss" flags and
> they should default off, of course.
>
> +-DLS
Maybe a OVS style "here is the homeless packet" message is needed.
That would allow for controller in user space to populate table
on as needed basis.
next prev parent reply other threads:[~2012-11-13 22:42 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-11-13 20:21 [PATCH net-next] add DOVE extensions for VXLAN David L Stevens
2012-11-13 21:28 ` Stephen Hemminger
2012-11-13 22:28 ` David Stevens
2012-11-13 22:41 ` Stephen Hemminger [this message]
2012-11-14 10:02 ` David Stevens
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=20121113144148.66a86bc7@nehalam.linuxnetplumber.net \
--to=shemminger@vyatta.com \
--cc=davem@davemloft.net \
--cc=dlstevens@us.ibm.com \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
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;
as well as URLs for NNTP newsgroup(s).