All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alex Zeffertt <ajz@cambridgebroadband.com>
To: Alexander Indenbaum <alexander.indenbaum@gmail.com>
Cc: bridge@lists.osdl.org, shemminger@osdl.org
Subject: Re: [Bridge] Link fail over - bridge slow learning !?!
Date: Wed, 11 Oct 2006 09:57:04 +0100	[thread overview]
Message-ID: <452CB1E0.9020008@cambridgebroadband.com> (raw)
In-Reply-To: <cab05a880610090952g2e94b7aka84ccb0ef8fd8013@mail.gmail.com>

Alexander Indenbaum wrote:
> Hello,
> 
> I'm playing with dual-port NIC driver level link failover:
> * Driver exposes single network interface to the OS and operates both
> ports in active-passive failover mode.
> * Upon Link down event on active port, driver switches active and
> passive ports transparently for the OS.
> 
> I'm testing the driver using Linux bridge module: "failover" dual-port
> NIC connected with two cables back-to-back to eth0 and eth1 which are
> part of br0 bridge.
> 
> I simulate link fail with following scenario:
> * At t0 both eth0 and eth1 port links are UP, traffic is accepted by
> eth0 and forwarded to br0
> * At t1 I manually unplug eth0 cable, causing link to go down.
> "Failover" driver switches the traffic immediately from eth0 to eth1,
> while using the same MAC address.
> * From t1 till t1+12 secs packets are accepted by eth1 but dropped by
> bridge and not forwarded to br0.
> * At t1+12 secs bridge starts forwarding packets from eth1 to br0
> 
> Hmm... I would expect that eth0 link down event would flush from
> bridge's table any MAC address associated with the port and that the
> bridge would start forwarding packets from eth1 to br0 immediately.
> 
> Why does it take ~12 secs for bridge to learn that MAC address moved
> from eth0 to eth1 in the described scenario?
> 

It may be spanning tree, rather than MAC address learning that takes
so long.  Bridges spend a while just listening before forwarding, to
avoid becoming part of a bridging loop.

Experiment with:

   brctl showstp br0
   brctl stp br0 off
   brctl setfd br0 1

Alex


  reply	other threads:[~2006-10-11  8:57 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-10-09 16:52 [Bridge] Link fail over - bridge slow learning !?! Alexander Indenbaum
2006-10-11  8:57 ` Alex Zeffertt [this message]
2006-10-11  9:33   ` Alexander Indenbaum
2006-10-11 10:23     ` Alex Zeffertt
2006-10-12 16:15       ` Alexander Indenbaum
2006-10-12 16:32         ` Alex Zeffertt
2006-10-11 17:32     ` Stephen Hemminger

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=452CB1E0.9020008@cambridgebroadband.com \
    --to=ajz@cambridgebroadband.com \
    --cc=alexander.indenbaum@gmail.com \
    --cc=bridge@lists.osdl.org \
    --cc=shemminger@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.