Setting up a virtual environment for STP testing

I'm looking to create a test environment for STP / RSTP. I eventually came by this post that suggested using namespaces. It seemed like that was exactly what I'd wanted to create the simplest STP environment. I ended up writing a script like this:

#!/bin/bash
 
if [ "$EUID" -ne 0 ]
then echo "Please run as root"
    exit
fi
 
# First case: Try a single veth pair
ip netns add blue
 
ip link add veth0 type veth peer veth1 netns blue
ip link add veth2 type veth peer veth3 netns blue
 
ip link set veth0 up
ip netns exec blue ip link set veth1 up
ip link set veth2 up
ip netns exec blue ip link set veth3 up
 
ip link add mybridge type bridge
ip link set veth0 master mybridge
ip link set veth2 master mybridge
 
ip netns exec blue ip link add bluebridge type bridge
ip netns exec blue ip link set veth1 master bluebridge
ip netns exec blue ip link set veth3 master bluebridge

ip addr add 10.200.0.1/24 dev mybridge
 
#brctl stp mybridge on
ip link set mybridge type bridge stp_state 1

ip link set mybridge up

# start recording packets here
echo "Start recording packets. Press any key to continue"
read -n 1

ip netns exec blue ip addr add 10.200.0.2/24 dev bluebridge

#ip netns exec blue brctl stp bluebridge on
ip netns exec blue ip link set bluebridge type bridge stp_state 1

ip netns exec blue ip link set bluebridge up

Almost all the time I end up getting in a state where both veth0 and veth2 are forwarding, and I'll get a storm that makes my machine work until I bring any of the interfaces down.

My hope would be the kernel itself (4.19.128 running in WSL 2.0 for my current test) could detect these and... not cause a storm. Further, I'd hope to be able to use a user-space RSTP program like mstpd (commit f55f783610e65149) on one or both of these bridges and grow the network architecture, capturing packets on any of the interfaces along the way.

Is there something I'm missing? I've tried this with three network namespaces as well - still seemed to almost always lead to a storm.

I have seen a couple instances where one port becomes blocking and the other forwards, as I'd expect. That seems to be the exception rather than the rule.

For those playing at home, a simple script to undo all the interfaces:

#!/bin/bash

if [ "$EUID" -ne 0 ]
then echo "Please run as root"
    exit
fi

# Kill blue
ip netns exec blue ip link del bluebridge
ip netns exec blue ip link del veth1
ip netns exec blue ip link del veth3

ip netns del blue

ip link del mybridge