What happens when you stop receiving BPDUs with no L1 loss

802.1D STP has configuration BPDUs sent by the root bridge. The designated bridges relay these BPDUs on their designated ports. All BPDUs flow from the root. With 802.1D, a port going up or down will generate a topology change, unless portfast has been configured on the port.

When a switch detects a topology change it will generate a TCN BPDU, which is a special BPDU. This BPDU is sent on root port. This BPDU must be acknowledged by the upstream switch until the TCN eventually reaches the root.

After the TCN BPDU has reached the root bridge, the root bridge will send out configuration BPDU with TC bit set. The root does this for MaxAge + FWD_DELAY seconds which is 20 + 15 seconds by default, for a total of 35 seconds.

When the switches receive this BPDU with TC set, they will shorten the timeout of the MAC address table to flush out stale entries. The timeout is then set to 15 seconds, so stale entries will be removed but active flows will be relearned through the now active ports.

If using 802.1w then there is a synchronization process through a proposal and agreement mechanism. With RSTP, only ports moving to forwarding can create topology changes. This makes sense since only adding connectivity should be of concern.

With a RSTP switch, when it detects a change it will set the TC bit in its BPDUs, the switch receiving this BPDU will then flush all MACs learned except for the port on where the BPDU was received. This will repeat throughout the network until the topology has converged.

There are some more details in some of my blog posts:

Topology change

RSTP synchronization

MST convergence

STP convergence

I have seen this a few times, where manufacturers are lazy and store MAC addresses in CMOS or similar, and fall back to a common default. It would also be easy to arrange if using locally assigned addresses (e.g. when provisioning VMs)

1. I've not tested what individual OSs do. If your only problem is ARP, then static ARP entries might work for you.

   2. Some old DEC systems used to send loopback packets to their own address, as a duplicate address check. I believe some Cisco switches do the same for loop detection. Either way, it's a special case of destination MAC filtering. If the address wasn't in the cache, I wouldn't be sure that first packet would be dropped immediately: it might be added to the forwarding tables and forwarded. Otherwise, silently drop.

   3. The MAC address would flap; if you are running a stateless protocol at the higher levels, you may end up with something like a crude unicast load balancer. For something like TCP, you'll get a lot of RST's as well as packet loss. And as others have said, to an 'enterprise' switch it looks like MAC spoofing and some may log/trap on this event.