bridge.lists.linux.dev archive mirror
 help / color / mirror / Atom feed
From: Brett Worth <brett.worth@gmail.com>
To: bridge@lists.linux-foundation.org
Subject: Re: [Bridge] bridge port number changing - FIXED
Date: Thu, 26 Mar 2015 08:34:50 +1100	[thread overview]
Message-ID: <551329FA.9040105@gmail.com> (raw)
In-Reply-To: <550BABAA.10803@gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2483 bytes --]

On 20/03/15 16:10, Brett Worth wrote:
> Hi all.  This is my first post to this list and I hope you'll be able to help.
>
> I have been using the Linux bridge module for a long time under kvm on centos.  This has
> not given me any problems until now.
>
> I'm adding some host servers and am using HP BL660 blades.
>
> The kvm nic script in /etc/kvm creates a tap device then assigns a MAC address after
> modifying the first byte to FE.  This is so the port 1 host mac doesn't change.
>
> On a working host server when running brctl showmacs br0 I see the tap mac address and the
> mac address assigned to the vm on the same port. The tap mac shows as local and the vm mac
> is not.
>
> The problem:
>
> Intermittently (once a minute or so) the port number shown for the VM will switch to port
> 1.  During this time the VM cannot be contacted. The tap device mac remains at it's
> original value.  If I wait it will switch back to the correct port number i.e. the one
> associated with the tap device at which point network connectivity is re-established.
>
> I have looked for the VM mac address on the LAN but cannot see it so it seems to be
> something internal to the bridge.
>
> Can anyone offer a suggestion as to what might be happening?
>
> I'm running centos 6.6 and the bridge is 2.3.

I have finally found a solution to this problem which I thought might be of interest to 
the list.

The HP BL660 blades I am using have an Emulex NIC which used the be2net driver.  Between 
RHEL 6.5 and RHEL 6.6 the be2net modules was upgraded from 4.x to a 10.x version.

In the release notes 
(http://www-dl.emulex.com/support/lenovo/rt10.3.0/ga/Docs/linux/linux_relnotes_elx.pdf) I 
found this:

    "2. PING is not working when attempting to bridge the 1G or 10G ports to the virtual
    machines when SR-IOV is enabled for 10 G ports in the BIOS.
    This issue occurs due to limitations of the virtual Ethernet bridge. All transmitted
    broadcast packets are looped back by the controller. This affects the functionality of the
    Linux bridge, as it appears as if the same ARP broadcast packets are received on two
    different interfaces.
    Workaround
    a) Set the aging of the bridge to 0 using the following command:
    “brctl setageing <bridge> 0”

    "

Is it normal for the controller to loop back broadcast packets?

Is it going to make much of a difference to the the ageing set to zero?

Brett

-- 
   /) _ _ _/_/ / / /  _ _//
  /_)/</= / / (_(_/()/< ///


[-- Attachment #2: Type: text/html, Size: 3179 bytes --]

      parent reply	other threads:[~2015-03-25 21:34 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-20  5:10 [Bridge] bridge port number changing Brett Worth
2015-03-20 19:51 ` Stephen Hemminger
2015-03-25 21:34 ` Brett Worth [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=551329FA.9040105@gmail.com \
    --to=brett.worth@gmail.com \
    --cc=brett@worth.id.au \
    --cc=bridge@lists.linux-foundation.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).