netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Nicolas de Pesloüan" <nicolas.2p.debian@gmail.com>
To: Andy Gospodarek <andy@greyhouse.net>
Cc: Jay Vosburgh <fubar@us.ibm.com>,
	netdev@vger.kernel.org, David Miller <davem@davemloft.net>,
	Herbert Xu <herbert@gondor.hengli.com.au>,
	Jiri Pirko <jpirko@redhat.com>
Subject: Re: [PATCH net-2.6] bonding: drop frames received with master's	source MAC
Date: Tue, 01 Mar 2011 22:30:52 +0100	[thread overview]
Message-ID: <4D6D658C.90300@gmail.com> (raw)
In-Reply-To: <20110301181624.GM11864@gospo.rdu.redhat.com>

Le 01/03/2011 19:16, Andy Gospodarek a écrit :

[snip]

> Knowing that I'm using an unmanaged switch with balance-rr probably
> helps understand how this is happening.  I'll clarify this however, so
> we are all on the same page.
>
> In my situation, eth2 and eth3 are in bond0.  When bond0 transmits the
> NS, let's say it goes out eth3.  Since it is a multicast frame my switch
> will broadcast this to all ports and eth2 will receive the frame with
> the source MAC address being the same as bond0's MAC address.  This
> frame is passed up the stack to the ipv6 layer and appears to be a
> response to the NS from another host and is dropped.

'sounds perfectly normal.

This problem is described in detail in chapter 5.4.3 and appendix A of RFC4862 "IPv6 Stateless 
Address Autoconfiguration".

As this is clearly IPv6 related, it sounds normal from my point of view to fix it at the 
ndisc_recv_ns() level.

Quoting the RFC:

   "In those cases where the hardware cannot suppress loopbacks, however,
    one possible software heuristic to filter out unwanted loopbacks is
    to discard any received packet whose link-layer source address is the
    same as the receiving interface's.  There is even a link-layer
    specification that requires that any such packets be discarded
    [IEEE802.11].  Unfortunately, use of that criteria also results in
    the discarding of all packets sent by another node using the same
    link-layer address.  Duplicate Address Detection will fail on
    interfaces that filter received packets in this manner:

    [snip]

    Thus, to perform Duplicate Address Detection correctly in the case
    where two interfaces are using the same link-layer address, an
    implementation must have a good understanding of the interface's
    multicast loopback semantics, and the interface cannot discard
    received packets simply because the source link-layer address is the
    same as the interface's."

So, simply dropping frames whose source MAC == local MAC is apparently not the right solution.

	Nicolas.

  reply	other threads:[~2011-03-01 21:31 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-02-25 21:13 [PATCH net-2.6] bonding: drop frames received with master's source MAC Andy Gospodarek
2011-02-25 22:04 ` Nicolas de Pesloüan
2011-02-25 22:24   ` Andy Gospodarek
2011-02-25 23:08     ` Nicolas de Pesloüan
2011-02-28 16:32       ` Andy Gospodarek
2011-02-28 21:45         ` Nicolas de Pesloüan
2011-03-01  2:35           ` Andy Gospodarek
2011-03-01  5:46             ` Jay Vosburgh
2011-03-01 18:16               ` Andy Gospodarek
2011-03-01 21:30                 ` Nicolas de Pesloüan [this message]
2011-03-01 22:25                   ` Jay Vosburgh
2011-03-01 23:08                     ` Nicolas de Pesloüan
     [not found]                       ` <AANLkTi=QTDNBf7Jskj55NP64Os8kgEs1WMpFGHMo+K3B@mail.gmail.com>
2011-03-02 12:30                         ` Herbert Xu
2011-03-02 20:30                           ` Nicolas de Pesloüan
2011-03-02 20:26                       ` Nicolas de Pesloüan
2011-02-25 22:28   ` Jay Vosburgh

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=4D6D658C.90300@gmail.com \
    --to=nicolas.2p.debian@gmail.com \
    --cc=andy@greyhouse.net \
    --cc=davem@davemloft.net \
    --cc=fubar@us.ibm.com \
    --cc=herbert@gondor.hengli.com.au \
    --cc=jpirko@redhat.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).