Switch Port Documentation: The Port Schedule
By VJ Ries · Published 2026-07-12 · Updated 2026-08-01 · 9 min read
A switch port schedule is one row per switch port that records its untagged VLAN, any tagged VLANs, whether the port supplies PoE, the device (and port) on the far end, and the cable ID. It is the trace map for the network. Someone says "something's wrong," and you go from a symptom to the exact port, VLAN and cable in about two minutes instead of unplugging things until the fault moves. Build it in preproduction from the same diagram that already holds your IP and cable schedules, then keep it as-built. There is a free CSV port schedule template below.
Why document switch ports? The trace map
Every port is configured for a VLAN, maybe supplying power, maybe a trunk. None of it is visible from the front panel. An undocumented managed switch is a black box with blinking lights. When a device drops off the network, the only tools you have left are guesswork and unplugging cables until the problem moves. That is how a two-minute fault turns into an hour with the show clock running.
Which VLAN is Camera 2 on? Does port 6 actually supply PoE, or is the panel dead for a different reason? Is the link to the stage switch a trunk, and does it carry the audio VLAN? What is the cable ID so the field tech can find the run? A port schedule turns every one of those questions into a lookup. The schedule answers all of it without touching the switch.
The columns, and which are mandatory
One row per physical port, and only the fields that let a stranger trace or rebuild the port: a port schedule is deliberately narrow. These are the columns that earn their place.
| Column | What it records | Mandatory? |
|---|---|---|
| Switch | Which switch or stack member, so the port number is unambiguous across the rack | Yes |
| Port | The physical port label exactly as printed on the switch face | Yes |
| Untagged VLAN | The access (or native) VLAN the port sits on | Yes |
| Tagged VLANs | VLANs carried tagged on a trunk; blank on an access port | Trunks only |
| PoE | The class or planning draw the port supplies, or None; this column feeds the PoE budget | Where PoE exists |
| Connected device / port | The far end, down to its port, so tracing works in both directions | Yes |
| Cable ID | The permanent ID printed on the cable; the join key to the cable schedule | Yes |
| Notes | Anything non-default: forced speed/duplex, LACP group, storm control, a reserved spare | Optional |
Mandatory on every row: switch, port, untagged VLAN, connected device and port, cable ID. Those five are the trace path. Tagged VLANs matter only on trunks. PoE matters only where a port powers its device; Notes only when the port does something a fresh tech would not assume. Everything WireFlow tracks about connecting devices lives in the port-level connection docs; the port schedule is the switch-side view of that same data.
Access ports vs. trunk ports
Every port runs in one of two modes, and the schedule has to say which. An access port belongs to exactly one VLAN and hands the device plain untagged frames; the device never knows VLANs exist. A trunk port carries several VLANs at once, each frame tagged (the mechanism is IEEE 802.1Q) so the far end can sort the traffic back out. Endpoints land on access ports; switch-to-switch links and the occasional VLAN-aware device land on trunks. The full treatment is in VLAN planning for AV systems.
In the schedule the distinction is visible at a glance. An access row has one untagged VLAN and None in the tagged column, while a trunk row lists every VLAN it carries. Get this wrong and the failure is quiet. A device patched into a trunk it does not understand, or a trunk mislabeled as access so it drops most of its VLANs, lands on the wrong network or on none at all. The link light stays green the whole time.
One system, three sheets: port, IP, and cable
One face of a single system documented three ways, the port schedule does not stand alone; each sheet owns a different question:
- IP schedule owns the addresses: hostname, IP, subnet, VLAN, static or DHCP. See how to create an IP schedule.
- Cable schedule owns the physical run: both endpoints, signal, type, length, loom, and the cable ID.
- Port schedule owns the switch side: which port, which VLAN mode, PoE, and the device on the end.
The join key that stitches them together is the cable ID plus the device-and-port endpoint. A device shows up by IP on the IP schedule, by cable ID on the cable schedule, by switch port here. The three cross-reference cleanly. The failure mode is maintaining three disconnected spreadsheets that drift out of sync the first time anything is re-patched; better to derive all three from one source, see port-to-port documentation: WireFlow documents switch ports on the diagram itself, so the port, VLAN, PoE and cable are attributes of a connection you can see, not rows you retype in a fourth file.
A worked port schedule
Here is a small managed core switch for a show network, using the same five-VLAN map as VLAN planning for AV systems (10 MGMT, 20 AUDIO, 30 VIDEO, 40 CONTROL, with 50 GUEST in the map but unused on this rig). Notice that ports 1 and 7 are trunks: they carry 10, 20, 30 and 40 tagged; their untagged (native) VLAN is 999, an id with nothing on it. That is deliberate. Anything that arrives on the trunk untagged lands on a VLAN that goes nowhere, instead of dropping onto management or onto a live show VLAN. The PoE ports feed the cameras and panel. Every cable ID matches a row in the cable schedule.
| Switch / Port | Untagged VLAN | Tagged VLANs | PoE | Connected device / port | Cable ID | Notes |
|---|---|---|---|---|---|---|
| CORE-SW1 / 1 | 999 UNUSED | 10, 20, 30, 40 | None | Gateway / LAN1 (uplink trunk) | N001 | Native VLAN parked on 999, an id with no devices and no gateway, so untagged frames on the trunk go nowhere |
| CORE-SW1 / 2 | 20 AUDIO | None | None | Audio console / Net A | N002 | |
| CORE-SW1 / 3 | 20 AUDIO | None | None | Stagebox / Net A | N003 | |
| CORE-SW1 / 4 | 30 VIDEO | None | PoE+ / ~25 W | PTZ Cam 1 / LAN | N004 | |
| CORE-SW1 / 5 | 30 VIDEO | None | PoE+ / ~25 W | PTZ Cam 2 / LAN | N005 | |
| CORE-SW1 / 6 | 40 CONTROL | None | PoE+ / ~30 W | Touch panel / PoE | N006 | |
| CORE-SW1 / 7 | 999 UNUSED | 10, 20, 30, 40 | None | STAGE-SW2 / Port 1 (trunk) | N007 | Same native-VLAN rule as port 1; 999 must match on both ends of the link |
| CORE-SW1 / 8 | 30 VIDEO | None | None | Record laptop / NIC | N008 | Record rig sits on the video VLAN with the sources it captures, never on MGMT |
Read it as a stranger would. Camera 2 is down: find it on port 5, VLAN 30, PoE+, cable N005, and you already know the three things that can be wrong (link, VLAN, or power) and the cable to check. No probing. No unplugging. No calling the person who built it.
PoE per port feeds the budget
Record the class or planning draw per port. The sum of those figures is the number you check against the switch's PoE budget, so the PoE column is not a yes/no checkbox. A switch that runs out of budget does not throw a clean error. It just stops powering the next device. An exhausted budget gets misdiagnosed as everything except what it is. The per-port math and how to size it live in PoE budget planning.
Keep it as-built
In preproduction, the schedule you write is the proposed network. What actually gets patched at load-in drifts from it: a port dies and the device moves to port 9, the house hands you a different uplink, a camera changes position. Update the schedule while the change is fresh, at load-in, not from memory a week later. Mark its state and date. The as-built is what you hand the client and what makes the next show at that venue start from truth.
Documenting ports on the diagram pays off here. Because the port, VLAN, PoE and cable are attributes of the connection in WireFlow, moving a wire updates the schedule instead of leaving a spreadsheet stale; you export the port schedule with the cable schedule and gear list from the same project. If you would rather start from a blank sheet, the free CSV port schedule template has the columns above ready to fill.
Frequently asked questions
- What is the difference between a port schedule and an IP schedule?
- They document different layers of the same network. The IP schedule owns addressing, hostname, IP, subnet, VLAN, static or DHCP status. The port schedule owns the physical switch side: which port a device lands on, its VLAN mode, PoE, the cable ID. They share the device and the cable ID as join keys, so you can pivot from an address to a physical port and back.
- Do I need to document every empty port?
- Not every empty port needs its own row. Record which ports are deliberately spare, disabled, or reserved for an uplink. A blank row is ambiguous: it could mean not-yet-documented or intentionally empty. That ambiguity is exactly what you cannot afford during a fault. A short note like "spare, disabled" removes the question.
- What about unmanaged switches?
- An unmanaged switch has no per-port VLAN or PoE configuration to document. It is still a node on the map. Record the switch. Record its uplink port on the managed switch, and what hangs off it. The unmanaged five-port switch someone added under a table is a classic mystery-fault source precisely because it never made it onto anyone's schedule.
- How do I label the ports physically so they match the schedule?
- Make the Port value in the schedule match the number printed on the switch exactly. Label the far end of each run with its cable ID. Where a device is remote, label the wall plate or patch point with the cable ID too, so the person standing at either end can tie back to the same row.
- Can I generate a port schedule instead of typing it?
- Yes. If your switch ports are documented on the diagram, WireFlow derives the port schedule alongside the cable schedule and gear list, so it stays consistent with the drawing. Otherwise, start from the free CSV template on the templates page and fill the columns by hand.
Document your AV network in WireFlow
VLANs, IPs, PoE, and switch ports live on the same diagram as your signal flow, one source of truth for the whole system.