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
