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.
next prev parent 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).