Find an unmanaged switch

When you need this

“Someone daisy-chained a desk switch off a wall jack. Which port?”
“There’s a switch in that closet nobody put in inventory — where does it hang off the fabric?”
“We onboard by collecting from every switch. What are we not collecting from that’s still forwarding traffic?”

An unauthorized or forgotten switch is the gap between the fabric you manage and the fabric that actually exists. The detector finds those gaps by asking one question of every edge port: is whatever is on the far side of this port something we know and collect from? If not, it flags the port and tells you which of two shapes it is.

Silent hubs — a dumb switch or hub that never speaks LLDP or CDP. It has no management identity at all; its only fingerprint is a pile of MAC addresses learned on a single access port with no neighbor announced.
Unmonitored switches — a box that does announce itself over LLDP/CDP, so l2trace can see it exists, but that has no enabled collector. Shadow infrastructure, or a device inventory knows about that was never onboarded.

The line between “fine” and “flagged” is known-ness, not neighbor presence. A port is cleared only when its neighbor resolves to a device that has an enabled device_collector row. A neighbor l2trace can see but doesn’t poll is exactly the thing worth surfacing. The reasoning behind the heuristic and its confidence scoring lives in how the unmanaged-switch detector decides; this page is how to run it.

In the browser

Open Rogue Switches. The findings split into the same two categories, worst-first:

Unmonitored switches — each row names the announced neighbor (its sysname and the protocol that carried it), whether that neighbor is in inventory at all, the count of downstream MACs, and a confidence band. A neighbor that matches nothing in inventory is the strongest signal (high); one that’s in inventory but has no collector is medium, and gets promoted to high once it’s carrying four or more MACs.
Silent hubs — ports with no neighbor but multiple live MACs. The row shows the MAC count, the distinct vendor OUIs behind those MACs, the VLANs involved, and a confidence band. More MACs and more different vendors read as more switch-like; a pile of MACs that are all one VMware OUI reads as a hypervisor and is floored to low.

High-confidence rows carry a red left border. Both sections have honest empty states — “every announced neighbor is one we collect from” and “no silent multi-MAC ports above the threshold” — so a clean board says so plainly rather than just showing nothing.

The min-MACs threshold

A control at the top sets the minimum distinct MACs a silent port needs before it’s flagged, with presets 2 / 3 / 5 (default 2). Raise it to cut noise on a fabric where two-MAC ports are common (a phone with a PC hanging off its dumb passthrough switch, say). The threshold gates only the silent category — unmonitored switches are flagged regardless of MAC count, because a switch that announces itself and isn’t collected is worth seeing even with nothing behind it yet.

In the TUI

Press Ctrl+W from the home screen (ROGUE-SW) to open the same detector. Columns: a confidence marker (! high / • medium / · low), kind (hub for silent, unmon for unmonitored), the switch and port, the MAC count, a detail column, and the leading reason. The Min MACs buttons (2 / 3 / 5) re-query on change; Ctrl+R refreshes. Like the other operational screens it’s operator-refreshed, not a live tail.

From the API (for automation)

curl -s "https://l2trace.example.net/api/rogue-switches?min_macs=2"

min_macs defaults to 2 and is clamped to 2..100. The response is a JSON array, worst-first, one object per flagged port:

{
  "switch", "port", "category",              // "silent" | "unmonitored"
  "mac_count", "vlan_count", "distinct_ouis",
  "vendors", "vlans", "sample_macs",         // sample_macs capped at 16
  "vm_macs", "has_neighbor", "has_unknown_neighbor",
  "neighbor_names", "neighbor_protocols",
  "confidence",                              // "high" | "medium" | "low"
  "reasons", "first_seen"
}

The high-confidence unmonitored feed — announced neighbors you don’t collect from, most urgent first — is:

curl -s ".../api/rogue-switches" \
  | jq '.[] | select(.category=="unmonitored" and .confidence=="high")'

What to do about a finding

The two categories point at two different fixes.

An unmonitored switch that’s real infrastructure should be onboarded: register it with an enabled collector and it stops being a gap (register a switch). If you genuinely can’t poll it — vendor-managed, no credentials — but it’s carrying traffic you need to trace across, register a passthrough placeholder instead so a trace crosses it explicitly rather than dead-ending (mark an unknown switch). Either way the port clears on the next detector run.

A silent hub is a physical-security question, not an onboarding one: walk to the switch and port the row names and find out what’s plugged into that jack. The sample_macs and their vendor OUIs are your lead for what you’ll find on the other end.

Reading it honestly

The detector reads current belief only — there’s no as-of / valid-time axis here, unlike most l2trace surfaces. It answers “what looks unmanaged now,” so the shared time-circuits control doesn’t drive it.

A flag is a lead, not a verdict. A single multi-NIC host (one MAC per interface) can look like a two-MAC silent port; a hypervisor uplink looks like a pile of MACs until you notice they’re all one virtualization OUI, which is exactly why those are scored down rather than up. The confidence band and the reasons list exist to tell the switch-shaped findings from the host-shaped ones — trust them, and start with the high rows.