Alex, That was my first thought too, but STP is disabled. On 10/11/06, Alex Zeffertt <ajz at 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 > > -- Alexander Indenbaum
