public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Patrick McHardy <kaber@trash.net>
To: Stefan Priebe - Profihost AG <s.priebe@profihost.ag>
Cc: Linux Netdev List <netdev@vger.kernel.org>,
	David Miller <davem@davemloft.net>,
	LKML <linux-kernel@vger.kernel.org>,
	Alexandre DERUMIER <aderumier@odiso.com>
Subject: Re: Problem with GVRP on eth while having a bridge
Date: Thu, 7 Feb 2013 14:02:30 +0100	[thread overview]
Message-ID: <20130207130227.GF13989@macbook.localnet> (raw)
In-Reply-To: <511396C9.2080106@profihost.ag>

On Thu, Feb 07, 2013 at 12:58:01PM +0100, Stefan Priebe - Profihost AG wrote:
> Hi Patrick,
> 
> thanks for your fast response.
> 
> > So please describe the entire GVRP message exchange that's going
> > on.
> I've attached two small pcap files.
> 
> has_bridge.pcap: is where eth1 has a bridge and the dynamic vlan
> disappears after a few seconds.
> 
> no_bridge.pcap: no bridge is assigned to eth1 - the dynamic vlan stays
> as long as i remove it
> 
> > Also you probably want to add the VLAN device on top of the bridge
> > device, otherwise it will get passed to the bridge after untagging,
> > which might not work, depending on the MAC addresses used.
> 
> That's working fine in vanilla kernel 3.7.6 but it does not with RHEL 6.
> Also i looks more complicated as i need another bridge on top of the
> vlan to assign the needed tap devices. I looked at ovirt for the network
> setup:
> http://www.ovirt.org/Vdsm_Network
> 
> and they also add the vlan directly on top of the nic and then the
> bridge on top of the VLANs.

What seems to be happening is that the switch is constantly requesting
GVRP updates. Once eth0 is added to the bridge, the bridge has preference
over local protocol (LLC) delivery. Since the packet has a link local
destination and your bridge doesn't seem to have STP enabled, the
bridge decides to forward the packet. Since its a multicast destination,
the packet is finally passed up to LLC, but the receiving device is
the bridge, not eth0. When the packet reaches the GARP input handler,
no garp_port is associated to the device and the packet is dropped.
This result is that the GARP protocol doesn't notice that the switch
expects an update and the switch finally removes the VLAN.

So the solution is: put the VLAN on the bridge device.

      reply	other threads:[~2013-02-07 13:02 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-02-07 10:56 Problem with GVRP on eth while having a bridge Stefan Priebe - Profihost AG
2013-02-07 11:22 ` Patrick McHardy
2013-02-07 11:58   ` Stefan Priebe - Profihost AG
2013-02-07 13:02     ` Patrick McHardy [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=20130207130227.GF13989@macbook.localnet \
    --to=kaber@trash.net \
    --cc=aderumier@odiso.com \
    --cc=davem@davemloft.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=s.priebe@profihost.ag \
    /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