On Tue, Mar 06, 2007 at 07:21:30PM -0800, David Stevens wrote:
> > >Marking the master down would, I believe, issue notifiers that
> > > the device has gone down. Various things, network manager sort of
> > > applications in particular, listen to those, so I'm not sure it's a
> good
> > > id
> >Marking the master down would, I believe, issue notifiers that
> > the device has gone down. Various things, network manager sort of
> > applications in particular, listen to those, so I'm not sure it's a
good
> > idea. I think there are other side effects as well, I'm thinking it
> > wo
On Tue, Mar 06, 2007 at 03:15:41PM -0800, Jay Vosburgh wrote:
>
> David Stevens <[EMAIL PROTECTED]> wrote:
>
> >It looks to me like "rejoin" is essentially ip_mc_up(), and it'd be better
> >to call that than add a nearly identical function.
>
> Won't ip_mc_up() acquire an additional refere
[EMAIL PROTECTED] wrote on 03/06/2007 03:15:41 PM:
>
> David Stevens <[EMAIL PROTECTED]> wrote:
>
> >It looks to me like "rejoin" is essentially ip_mc_up(), and it'd be
better
> >to call that than add a nearly identical function.
>
>Won't ip_mc_up() acquire an additional reference (via
> i
David Stevens <[EMAIL PROTECTED]> wrote:
>It looks to me like "rejoin" is essentially ip_mc_up(), and it'd be better
>to call that than add a nearly identical function.
Won't ip_mc_up() acquire an additional reference (via
ip_mc_inc_group) to the IGMP_ALL_HOSTS im->users that would never
It looks to me like "rejoin" is essentially ip_mc_up(), and it'd be better
to call that than add a nearly identical function.
Also, real interfaces already do gratuitous IGMP advertisements when
they are bounced (the reason there is an ip_mc_up()). Could bonding,
when failing over, simply mark the
On 3/6/07, Jay Vosburgh <[EMAIL PROTECTED]> wrote:
Brian Haley <[EMAIL PROTECTED]> wrote:
>Andy Gospodarek wrote:
>> If we are easily able to differentiate between the multicast addresses
>> in the mc_list as to which are for ipv4 and which are for ipv6 then it
>> would be easy to call-out to so
Brian Haley <[EMAIL PROTECTED]> wrote:
>Andy Gospodarek wrote:
>> If we are easily able to differentiate between the multicast addresses
>> in the mc_list as to which are for ipv4 and which are for ipv6 then it
>> would be easy to call-out to something in the ipv6 mcast code when
>> needed instead
Andy Gospodarek wrote:
If we are easily able to differentiate between the multicast addresses
in the mc_list as to which are for ipv4 and which are for ipv6 then it
would be easy to call-out to something in the ipv6 mcast code when
needed instead of always calling out to ipv4 code.
I've been un
Andy Gospodarek <[EMAIL PROTECTED]> wrote:
>On Thu, Mar 01, 2007 at 02:25:19PM -0500, Brian Haley wrote:
[...]
>> So forgive my naive question, but what would it take to make IPv6 work?
>> I know DAD fails on a test setup I have, but I haven't dug-into why
>> this is (I can guess), and I'd like
On Thu, Mar 01, 2007 at 02:25:19PM -0500, Brian Haley wrote:
> Jay Vosburgh wrote:
> >>My only concern is that this code assumes all mcast addresses stored in
> >>dev->mc-list list are for ipv4 igmp mcast addresses and nothing was done
> >>for ipv6.
> >>
> >>But this is much better than what we hav
Jay Vosburgh wrote:
My only concern is that this code assumes all mcast addresses stored in
dev->mc-list list are for ipv4 igmp mcast addresses and nothing was done
for ipv6.
But this is much better than what we have now, so...
Agreed, but there's no IPv6 support anywhere in bonding a
Andy Gospodarek <[EMAIL PROTECTED]> wrote:
>On Wed, Feb 28, 2007 at 05:03:37PM -0800, Jay Vosburgh wrote:
[...]
>My only concern is that this code assumes all mcast addresses stored in
>dev->mc-list list are for ipv4 igmp mcast addresses and nothing was done
>for ipv6.
>
>But this is much better t
On Wed, Feb 28, 2007 at 05:03:37PM -0800, Jay Vosburgh wrote:
>
> In active-backup mode, the current bonding code duplicates IGMP
> traffic to all slaves, so that switches are up to date in case of a
> failover from an active to a backup interface. If bonding then fails
> back to the origin
In active-backup mode, the current bonding code duplicates IGMP
traffic to all slaves, so that switches are up to date in case of a
failover from an active to a backup interface. If bonding then fails
back to the original active interface, it is likely that the "active
slave" switch's IGM
15 matches
Mail list logo
