skip to content

Your floor plan and your port database disagree about which socket feeds the visitor lounge — how do you get ground truth, and what does it cost?

level: seniorimportance: should knowfreq 38%

answer

  1. both records are claims, not evidence
  2. the switch never knows geography
  3. link down was only true when you looked
  4. tone and trace, plate by plate
  5. true on a date, then it decays

basics

~20 s

Neither record is evidence; both are typed by teams that do not talk. The switch proves a port is active, never which wall plate it feeds — so ground truth means an escorted, room-by-room cable trace that decays as the building changes.

solid answer

~50 s

Start by accepting that both records are claims. The facilities plan says what a room is called and was last surveyed years ago; the port database carries descriptions typed by whoever last patched something. The switch is the only live witness, and it is partial: link state, interface counters, the address table and neighbour discovery tell you a port is active and roughly what kind of device is attached — they never tell you which wall plate it terminates at. That last hop only exists in copper, so ground truth means a physical trace with a tone-and-probe set, socket by socket. Budget engineer-days per floor, escorts for secured rooms, bookings for occupied ones, and a re-labelling pass. Then budget the recurring part: the result is true on a date, and it decays the first time facilities repurposes a room unless the change process is attached to it.

code

text · 15 lines
text
FACILITIES SPACE PLAN            (owner: workplace services)
  Room 1.14  "Visitor Lounge"    outlets: 1.14-A, 1.14-B
  last surveyed: 2023-11         note: was "Training 2" until refit

PORT DATABASE                    (owner: network team)
  sw-fl1-a  port 22   desc "1.14-A training rm"   vlan 40 (staff)   admin: up
  sw-fl1-a  port 23   desc "spare"                vlan 40 (staff)   admin: up

SWITCH, LIVE
  port 22   link: down   last input: never
  port 23   link: up     last input: 00:00:02   1 address learned   no neighbour data
  ...

-> a plate the plan calls a lounge outlet, the database calls spare,
   and something unidentified is talking on it right now

go deeper

for a junior

Know that the network's record of what a port serves is typed by people and often wrong, and that the switch can tell you a port is active but never which room it reaches.

for a middle

Explain what each evidence source proves and stops short of: link state, counters, the address table, neighbour discovery. Be able to say why link down does not mean unused.

for a senior

Show you would build the evidence window rather than the snapshot, cost the walk including escorts and bookings, and stage the shutting with a fast restore path when you get one wrong.

for a principal

Own the durability question: a shared identifier across both systems, patching gated on the record, and a recurring diff that turns the audit into a control instead of a document with a date on it.

## Two records, no joint owner The facilities space plan and the network port database describe overlapping reality from opposite ends and are maintained by teams with different incentives, different change processes and no shared identifier. Facilities knows rooms and moves walls; the network team knows ports and moves patch leads. Neither is notified when the other acts. That is why a socket ends up described as "spare" in one system and as a lounge outlet in the other — and why the disagreement is normal rather than a sign of neglect. The operative point for an interview: **neither record is evidence.** Both are assertions typed by a person, and the port description field is the record already known to be wrong. A candidate who resolves the conflict by trusting one of them has not resolved anything. ## What the switch can and cannot prove The switch is the only witness that is generated rather than typed, and its testimony has a hard limit. | Signal | What it proves | What it does not prove | | --- | --- | --- | | Link state | Something was electrically connected when you looked | That the socket is unused, or where it is | | Interface counters and last-input time | Traffic passed, and roughly when | Which room, or whether the traffic was legitimate | | Address table entries | How many endpoints are speaking on the port | Their identity — addresses are asserted | | Neighbour discovery data | The attached device announced a name and type, if it announces at all | Anything about a device that stays quiet, or about the wall plate | | Address-assignment and authentication logs | An endpoint asked for and received service | The physical location it asked from | Every row stops short of the same thing: geography. The mapping from switchport to wall plate exists only as copper between a patch panel and a plate, so it can only be established physically — a tone injected at one end and traced at the other, plate by plate, with the panel re-labelled as you go. ## The direction-of-claim trap The most common error is concluding that a port with no link and no recent counters is unused. It proves only that nothing was transmitting at the moment you looked. Real counter-examples are everywhere: an AV cart wheeled in monthly, an auditor's desk occupied one week a quarter, a floor box under a carpet tile whose lead is coiled in a drawer. Any "unused ports" list built from a single snapshot will contain live business services, and the first outage from shutting one is what discredits the whole exercise. Evidence has to be a window — weeks of link and counter history — not a reading. ## What the walk actually costs - **Engineer time**, in days per floor, two people where rooms cannot be entered alone. - **Access**: escorts for secured areas and the comms cage, bookings for meeting rooms, out-of-hours slots for spaces you cannot disturb. - **Disruption risk**: tracing means unplugging things, and something always turns out to matter. - **A re-labelling pass**, which is the part that makes the result reusable and the part most likely to be cut. - **A recurring survey**, because the map is true on a date. Without a hook into the facilities change process, it is stale within a quarter. ## What the walk finds that no database has This is the value that justifies the cost, and it is worth naming in an interview because it is always the same list: desk-side unmanaged switches fanning one port into five; docking stations chained behind phones; floor boxes and under-desk plates that appear on no plan; ports labelled "spare" carrying traffic right now; and rooms whose designation changed without a single record being updated — the training room that became the visitor lounge with its staff-VLAN sockets intact. ## Turning the walk into something that survives A one-off audit produces a document; what you need is a control. Three things make the result durable: one identifier shared by both systems so a plate can be named the same way in each; a rule that no patching happens without the record being updated, enforced by whoever holds the closet key; and a cheap recurring diff — compare live link and counter evidence against the database and investigate anything that lights up on a port the database calls spare. That last check is also a detection: a "spare" port that starts passing traffic in a public room is exactly the event this whole topic exists to catch. ## What an interviewer is listening for That you refuse to treat either record as truth, that you know precisely where the switch's evidence stops, that you cost the walk honestly including access and escorts, and that you say out loud that the answer decays. Candidates who describe only the tracing have done the audit; candidates who describe the hook into the change process have kept it.

  • The walk finds a five-port unmanaged switch under a desk. What does that do to your model?
    It breaks the one-port-one-socket assumption the whole map rests on. That switchport now serves several plates, so the physical socket count exceeds the switchport count, any per-port address limit has to be widened to cover the fan-out, and a visitor plugging into the spare port on that box inherits the desk's VLAN. It has to be recorded as a fan-out point, not quietly removed, because removing it is a user-facing change someone must agree to.
  • How do you decide which ports to actually shut once the walk is done?
    By evidence over a window rather than a snapshot: weeks of link and counter history, cross-checked against address-assignment records, then a named owner for anything still ambiguous. Shut in stages, publicise the window, and keep a fast un-shut path with a known turnaround — the credibility of the whole exercise depends on the first wrongly-shut port being restored quickly rather than argued about.
  • What keeps the map true six months later?
    A hook into the processes that change reality. Patching only happens with a record update, enforced by whoever controls closet access; room re-designations by facilities trigger a review of that room's sockets; and a scheduled diff compares live link and counter evidence against the database so a "spare" port that starts carrying traffic surfaces on its own. Without those, you have a document, not a control.

saying these in an interview costs you the question

  • Trusts the port description field, the record already known to be wrong
  • Declares a port unused from a single link-state snapshot
  • Plans a building walk without escorts, bookings or out-of-hours slots
  • Treats the audit as one-off with no hook into the change process
  • Assumes one switchport always terminates at exactly one wall plate

context