SwitchBlox BB-SWB-E-2-NDAA: troubleshooting radio/Starlink link failover

An anonymized support email exchange, reproduced in chronological order with one post per email. Names, signatures, shipping details and private order arrangements have been removed. Investigation remains open; the later auto-negotiation explanation is a hypothesis, not a verified resolution.

Customer question — email 1 of 10

We’re using your SwitchBlox (BB-SWB-E-2-NDAA) in our ground station and
have run into an issue I’m hoping you can help us fix.

Setup:

  • Ground side: a laptop and our ground router both connect to the
    SwitchBlox. The ground router has a Silvus IP radio on a LAN port and a
    Starlink terminal on its WAN port.
  • Air side: the air router has a Starlink terminal on WAN, a Silvus radio
    paired with the ground radio on LAN, and a camera on LAN.
  • The laptop views the camera’s video feed over either link, with failover
    between the Silvus and Starlink paths.

The issue:
When the laptop connects directly to the ground router, failover works. If
I drop the active link, the feed recovers over the other one. When the
SwitchBlox sits between the laptop and the router, the feed never recovers
after the active link drops. The only change between the two cases is the
switch.

Our working theory is that the switch is unmanaged and the laptop’s link to
it never drops, so the laptop doesn’t get the link-state event that would
make it refresh its ARP and DHCP state. It’s also possible that MAC table
aging or spanning tree handling plays a part. We’d appreciate your input on
the following:

  1. What is the default MAC address table aging time on this model, and can
    it be changed?
  2. In unmanaged mode, does the switch forward, drop, or act on spanning
    tree BPDUs?
  3. Does the switch flush its MAC table on any event, such as a port link
    change?
  4. Is there firmware or a configuration for managed mode that would let us
    shorten MAC aging, flush the table, or propagate link state? If so, where
    can we get it, and how do we load it?
  5. Have you seen this behavior in other redundant-link or failover
    deployments, and is there a SwitchBlox model or configuration you’d
    recommend for this use case?