[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAF1J0HO9USZXOj3nJnZ2Eup5Q4c2VhavgH0fmHFY1oUaWB+_UQ@mail.gmail.com>
Date: Wed, 5 Jun 2013 15:58:50 +0300
From: Mike Rapoport <mike.rapoport@...ellosystems.com>
To: Stephen Hemminger <stephen@...workplumber.org>
Cc: Thomas Graf <tgraf@...g.ch>, Cong Wang <xiyou.wangcong@...il.com>,
netdev@...r.kernel.org
Subject: Re: [PATCH iproute2] vxlan: allow specifying multiple default destinations
On Wed, Jun 5, 2013 at 7:30 AM, Stephen Hemminger
<stephen@...workplumber.org> wrote:
> On Sun, 2 Jun 2013 10:09:23 +0300
> Mike Rapoport <mike.rapoport@...ellosystems.com> wrote:
>
>> On Thu, May 30, 2013 at 6:57 PM, Thomas Graf <tgraf@...g.ch> wrote:
>> > On 05/30/13 at 03:46pm, Mike Rapoport wrote:
>> >> I'm feeling Ok about "ip link set [..] dstadd/dstdel". What does bother
>> >> me is that you can't have different parameters for "ip link add" and "ip
>> >> link set" for vxlan (and other iplink) utility. So, one can use
>> >> ip link add [..] dstdel
>> >> which does not make sense...
>> >
>> > You can easily pass an additional argument into iplink_modify()
>> > and exclude certain options in the "add" use case.
>>
>> I think there's no need to pass an additional argument to iplink_modify.
>> The vxlan_parse_opts may check the flags in nlmsghdr to distinguish
>> between the "add" and "set" cases.
>> Than we'll have 'ip link add [..]' as it was and the 'ip link set
>> [..]' will be used to manage default destinations.
>>
>> --
>> Sincerely yours,
>> Mike.
>
>
> I think multiple destinations should be handled like multipath routes.
> I.e you don't specify multiple destinations on the command line, you specify them
> individually and can add/delete them
>
> If you delete the last destination then the forwarding entry should disappear.
> The collapsing of multiple entries into one entry in table is an internal data structure
> choice of vxlan and shouldn't be part of the netlink API requirement.
>
> The API to iproute2/netlink should look like routing (through bridge fdb command).
> Feel free to reject this if since I don't actually use this stuff.
Well, if we're to follow David Stevens suggestion to make default
destination fdb entry with ALL_ZEROS_MAC (1), they surely can be
managed using 'bridge fdb'.
(1) http://thread.gmane.org/gmane.linux.network/270969/focus=271791
--
Sincerely yours,
Mike.
--
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
Powered by blists - more mailing lists