[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1136817119.4224160.1359142921330.JavaMail.root@redhat.com>
Date: Fri, 25 Jan 2013 14:42:01 -0500 (EST)
From: Pavel Simerda <psimerda@...hat.com>
To: Jay Vosburgh <fubar@...ibm.com>
Cc: netdev@...r.kernel.org, davem@...emloft.net, andy@...yhouse.net,
stephen@...workplumber.org, dcbw@...hat.com,
Jiri Pirko <jiri@...nulli.us>
Subject: Re: [patch net-next V2] bond: have random dev address by default
instead of zeroes
----- Original Message -----
> From: "Jay Vosburgh" <fubar@...ibm.com>
> To: "Pavel Simerda" <psimerda@...hat.com>
> Cc: netdev@...r.kernel.org, davem@...emloft.net, andy@...yhouse.net, stephen@...workplumber.org, dcbw@...hat.com,
> "Jiri Pirko" <jiri@...nulli.us>
> Sent: Friday, January 25, 2013 7:31:32 PM
> Subject: Re: [patch net-next V2] bond: have random dev address by default instead of zeroes
>
> Pavel Simerda <psimerda@...hat.com> wrote:
>
> >----- Original Message -----
> >> From: "Jay Vosburgh" <fubar@...ibm.com>
> >> but I don't think it should be changed.
> >
> >Just a short question. Is there any reason for bonding interfaces to
> >behave differently from bridging interfaces in this respect?
>
> To clarify, what I don't think should change is that a manually
> set MAC on the bonding master should override the automatic copy of
> the
> first slave's MAC to the bonding master. The fail_over_mac active
> and
> follow settings are an exception to this, but those are special cases
> for unusual network hardware.
>
> As for the random MAC vs. zero MAC, I've always thought that the
> all zero MAC was a clear indicator that the device (the bonding
> master
> in this case) was not in a usable state (in the sense that it could
> not
> send or receive actual traffic). It's not a really big deal, though,
> so
Thanks for clarification.
> if the trend these days is for everything to have a MAC all the time,
> that's fine, as long as doing so doesn't break anything.
>
> I think the patch under discussion should be fine with the
> addition of the last notifier call previously discussed. Some
> documentation updates would be nice, too.
>
> -J
>
> ---
> -Jay Vosburgh, IBM Linux Technology Center, fubar@...ibm.com
>
>
--
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