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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 20 May 2013 17:13:04 -0700
From:	Stephen Hemminger <stephen@...workplumber.org>
To:	Sridhar Samudrala <samudrala.sridhar@...il.com>
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 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
    
    The combination allows configuration of more complex topologies using VXLAN
    encapsulation.
    
    Changes since v1: rebase to 3.9.0-rc2
    
    Signed-Off-By: David L Stevens <dlstevens@...ibm.com>
    
    Signed-off-by: David S. Miller <davem@...emloft.net>
--
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