All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Osama Abu Elsorour" <osama@wayout.net>
To: bridge@lists.osdl.org
Subject: RE: [Bridge] ARP weirdness
Date: Tue, 7 Jun 2005 09:33:51 +0300	[thread overview]
Message-ID: <200506060635.j566ZijA028535@smtp.osdl.org> (raw)
In-Reply-To: <1118043051.2066.14.camel@juptop>

Actually

Giving it more thought I think the bridge is behaving, in a way, correctly.

From the bridge standpoint, there is no way for it to know that the
broadcast contains an ARP packet with the IP address of the br interface.
This is why it makes sense to flood.

However, VLANs should be, or at least optionally be, in a different
broadcast domain. The reason is, as I explained before, VLANs are an
exception in the sense of being logical interfaces shared on one physical
interface.

So, as in my setup case, it really confuses the switches directly connected
to the Linux box.

To solve the problem, I have made a small modification in the bridge code to
add a proc-controlled flag (/proc/sys/net/bridge/br*/no_vlan_nonlocal_flood)
to optionally put VLANs of a certain bridge in different broadcast domains.
What it does is it checks if this flag is set and the interface net_device
is VLAN and the source MAC address is not the br MAC. If all is true it does
not flood on this specific port. However, if the source MAC of the broadcast
is local (i.e. the br is, for example, sending ARP who-has) it is allowed.

I have tested the patch and it solved my switch-MAC confusion issue below.

If the above makes sense, I would be happy to clean up and post the patch.

Regards

-----Original Message-----
From: bridge-bounces@lists.osdl.org [mailto:bridge-bounces@lists.osdl.org]
On Behalf Of Oz
Sent: Monday, June 06, 2005 10:32 AM
To: bridge@lists.osdl.org
Subject: [Bridge] ARP weirdness

All

I have the following setup:

4 VLAN interfaces enslaved in a bridge interface. All VLAN interfaces
don't have IP address. The bridge interface has 192.168.1.1/24.

Now, when I try to ping from one of the VLAN interfaces, through a host
connected to a VLAN switch, while dumping the traffic, the following
happens:
- Host sends ARP who-has broadcast to the VLAN interface (tagged
correctly, originating from the host MAC)
- Linux receives the who-has and does 2 things:
	- It floods all VLAN interfaces with the same ARP who-has request
	- It responds with a unicast is-at on the correct VLAN interface

The question is: why does it flood while the ARP is destined to the
bridge interface?

The problem: I have a another switch connected passively between the
Linux box and the VLAN switch. When the bridge floods (which naturally
happens from the source of the originating box), it causes the switch to
be confused on where to find this specific MAC address and hence
dropping the frame.

Please advice.



      parent reply	other threads:[~2005-06-07  6:33 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-06-05  7:33 [Bridge] ARP weirdness Oz
2005-06-07  6:22 ` Osama Abu Elsorour
2005-06-07  6:33 ` Osama Abu Elsorour [this message]

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=200506060635.j566ZijA028535@smtp.osdl.org \
    --to=osama@wayout.net \
    --cc=bridge@lists.osdl.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.