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 11:23:06 +0100 [thread overview]
Message-ID: <452CC60A.3090509@cambridgebroadband.com> (raw)
In-Reply-To: <cab05a880610110233u2d48c96ena9915cf2bb3cb682@mail.gmail.com>
It still uses a forwarding delay. Try "brctl setfd br0 1" to set it to
1 second.
Alexander Indenbaum wrote:
> Alex,
>
> That was my first thought too, but STP is disabled.
>
> On 10/11/06, Alex Zeffertt <ajz@cambridgebroadband.com> wrote:
>> 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
>>
>>
>
>
next prev parent reply other threads:[~2006-10-11 10:23 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
2006-10-11 9:33 ` Alexander Indenbaum
2006-10-11 10:23 ` Alex Zeffertt [this message]
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=452CC60A.3090509@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox