How the unmanaged-switch detector decides
Every inventory system knows the switches it was told about. The interesting question is the inverse: what’s forwarding frames on the fabric that nobody registered. l2trace can answer it because it already collects two things that, joined, give the gap away — the MAC tables of the switches it does poll, and the LLDP/CDP neighbors those switches announce. An unmanaged switch leaves a footprint in both.
The gate is known-ness, not “does it have a neighbor”
Section titled “The gate is known-ness, not “does it have a neighbor””The naive version of this detector would flag any port with no LLDP neighbor. That’s wrong in both directions: plenty of legitimate endpoints announce nothing (a printer, a NIC), and — more dangerously — a switch that does announce itself over LLDP would sail through, because it has a neighbor. The neighbor’s mere presence proves nothing.
So the detector asks a different question. A port is cleared as managed
only when its adjacency resolves to a device that has an enabled
device_collector row — something l2trace actively collects from. A
neighbor l2trace can see but doesn’t poll is not cleared; it’s the whole
point. Known-ness means “we collect from it,” not “we can see it” and not
“it’s in inventory.” That single rule is what makes the two categories below
fall out.
Two shapes of the same gap
Section titled “Two shapes of the same gap”Silent hubs — footprint without identity
Section titled “Silent hubs — footprint without identity”A dumb switch or hub speaks no LLDP or CDP. It has no management identity to find; from the fabric’s side it’s invisible except for one tell. Every device plugged into it learns its MAC on the upstream switch’s single access port, so that one port accumulates a pile of MACs with no neighbor announced. One access port, many MACs, silence — that’s a hub.
The detector looks at candidate edge ports (physical, not trunk-roled, and not named like an uplink/port-channel/SVI/loopback/tunnel/AP), counts the current-belief MACs learned there, and flags a silent port once it clears the min-MACs threshold. MACs that are themselves a registered device’s chassis are excluded first, so the fabric’s own gear never counts toward a hub finding.
Unmonitored switches — identity without collection
Section titled “Unmonitored switches — identity without collection”The opposite shape: a box that does announce itself over LLDP/CDP, so l2trace sees its sysname and knows it exists, but that has no enabled collector. This is shadow infrastructure — a switch someone racked and cabled but never onboarded, or one inventory records but that was never pointed at a collector. Here the flag doesn’t depend on MAC count at all; an announced-but-uncollected neighbor is worth surfacing the moment it appears, empty or not, because the fix is to start collecting from it.
The sharpest version is a neighbor that resolves to nothing in inventory at all — l2trace hears the announcement but has no device record to match it to. That’s a switch that’s fully off the books, and it scores highest.
Confidence: telling switches from hosts
Section titled “Confidence: telling switches from hosts”A raw flag has false-friends. A workstation with two NICs looks like a two-MAC silent port. A hypervisor uplink looks like a pile of MACs. The confidence band exists to sort the switch-shaped findings above the host-shaped ones, and it’s built from signals that actually distinguish them.
For silent ports, the tells are how many MACs and how varied their
vendors are. A real downstream switch fans out to many devices from many
manufacturers, so a high MAC count and several distinct vendor OUIs push
confidence up. A pile of MACs that are all one OUI is more likely a single
multi-NIC host or a bonded server. And MACs that belong to VMware OUIs (or
that l2trace has correlated to VM placements) read as a hypervisor, not a
hub — when they dominate the port, confidence is floored to low, because
a virtualization host presenting many vNIC MACs on one uplink is normal, not
a rogue switch.
For unmonitored ports, the tell is how off-the-books the neighbor is.
A neighbor matching no inventory device at all is high. One that’s in
inventory but simply lacks a collector is medium — a smaller gap, since
someone at least recorded it — but it’s promoted to high once it’s
carrying enough downstream MACs to be actively load-bearing.
The bands are heuristics, and the detector says so by attaching a reasons
list to every finding: the specific signals that set the score, in plain
language, so an operator can see why a port was called switch-like before
walking to it.
Current belief only
Section titled “Current belief only”Unlike traces, history, and the change views — all of which scrub both time axes — this detector reads current belief only. It answers “what looks unmanaged right now,” a live operational question, not a historical one. The bitemporal machinery that anchors the rest of l2trace isn’t wired into it, which is why the time-circuits control doesn’t change what it shows. That’s a deliberate scoping choice, not an oversight: “was there an unmanaged switch here last Tuesday” is a question the raw observation log can already answer if you need it, and folding a second time axis into the heuristic would complicate it for a question operators rarely ask.
Related, but not the same: rogue APs
Section titled “Related, but not the same: rogue APs”The word “rogue” also names a wireless feature — rogue AP detection — and the two are independent. Rogue APs are access points a wireless controller hears over the air and reports; l2trace’s job there is to locate the ones on the wire by matching their MAC to a switch CAM, and those findings are persisted and bitemporal. The unmanaged-switch detector is a read-only heuristic over the wired fabric with no persisted table of its own. They share a noun and nothing else.
See also
Section titled “See also”- Find an unmanaged switch — running the detector in the browser, the TUI, and the API.
- How virtual switches work — what to do with an unmonitored box you can’t poll: model it as a passthrough.
- How peer resolution works — how a neighbor announcement becomes (or fails to become) a resolved device, the match that “known-ness” is built on.