Numbering cables: why "highest plus one" is the wrong rule

Every datacenter team agrees that cables should be numbered. Far fewer agree on where the numbers come from, and that is where cable labelling quietly falls apart. The usual method is to look up the highest cable ID in the DCIM and add one. It looks safe. It is not. This article explains why, and how to run cable IDs so that a number always means exactly one cable, for good.

What a cable ID is for

A cable ID is a promise: this number refers to this cable and nothing else. The promise lets an engineer standing in front of a rack match a physical cable to a record in seconds, confirm both ends, and act without tracing anything by hand. It also lets old tickets, change records, photos and drawings keep meaning something years later.

The promise breaks the moment one number appears on two cables. From then on, every reference to that number is ambiguous, and an ambiguous cable label is how the wrong cable gets pulled.

Why "highest plus one" fails

The highest-plus-one rule assumes the DCIM's current list of links is the complete history of every number ever used. It almost never is.

• Deleted links. When a cable is removed, its link is deleted from the DCIM. If it happened to carry the highest number, the next engineer reuses that number, while the old label may still be on a cable in a drawer, in a photo, or in last year's ticket.
• Printed but not yet recorded. Labels are often printed before the work, and the DCIM is updated after. Between the two, the numbers exist on tape but not in the database, and someone else can take them.
• Two people at once. Two engineers planning two jobs on the same afternoon both read the same highest number and both add one.
• Free-text fields. In most DCIM tools the cable field is free text. Nothing in the database stops the same value from landing on two links, so uniqueness has to come from the process.

Each of these is rare on its own. Over years and thousands of cables, they are certain.

The rule that works: monotonic, reserved, never reused

Treat cable IDs like invoice numbers. They come from one allocator, they only go up, and a number that has been issued is never issued again.

Count everything that has ever existed. The allocator's idea of "highest number" must include the live links in the DCIM, links in the DCIM's change history that have since been deleted, every label print job on record, and the allocator's own reservations. The next number is one above the highest of all of those.

Reserve before you print. Nobody writes a label or a link until they have reserved a block of numbers for a named purpose ("rack build, row two, data cabling"). The reservation is recorded with who asked and why.

Void, never give back. If a reserved number is not used, mark it void. It stays burned. Gaps in the sequence are harmless; reuse is not.

Fail closed. The allocator re-reads the DCIM on every reservation. If it cannot, it issues nothing. A slightly slower afternoon is a far better outcome than a duplicate.

A minimal ledger is a single table where the cable ID is the primary key, so the database itself refuses a second use:

CREATE TABLE cable_id (
  cid        INTEGER PRIMARY KEY,
  status     TEXT NOT NULL CHECK (status IN ('RESERVED','IN_USE','VOID')),
  purpose    TEXT NOT NULL,
  reserved_by TEXT NOT NULL,
  reserved_at TEXT NOT NULL
);

Keep the DCIM honest

The allocator is only half the system. The other half is checking what actually lands in the DCIM.

Refuse unreserved writes. Whatever tool writes cable IDs into the DCIM should check the number is reserved first, and refuse if it is not, or if the allocator cannot be reached.

Watch for drift. Run a periodic check that reads every link and raises an alert on three conditions: a number on two or more links, a number above the allocator's high-water mark that was never reserved, and a voided number in use. On a RackTables-style schema, the duplicate check is one query:

SELECT cable, COUNT(*) AS links
FROM Link
WHERE cable IS NOT NULL AND cable <> ''
GROUP BY cable
HAVING COUNT(*) > 1;

Run it every few minutes, send any result to a person, and treat every alert as a finding to chase, not noise.

Store the bare number. Decide on one format for the stored value, such as bare digits, and stick to it. If some links say CID1234 and others say 1234, a uniqueness check on the text will miss the pair. When you introduce a rule like this on an existing estate, make the allocator and the checks read both forms so that historical values still count.

Labels that answer the next question

A label that says only "1234" tells an engineer which record to open. A label that also says where the other end goes often saves opening it at all. We print a two-row layout on laminated, flag-wrapped tape:

1234 RK-A SRV7 NIC1
RK-A SW1 Eth1/9 [2M]

The top row is the cable ID with this end's rack, device and port. The bottom row is the far end's rack, device and port, and the cable length. The same label goes on both ends, and the flag wrap means it can be read from either side of the cable.

Two practical points from many print runs: print one cable's labels per print job with a short pause between jobs, because large batches can overrun a label printer's buffer and produce blank tape; and save every print job as a script with the project, because those scripts are part of the record of which numbers exist.

Build on paper first

The strongest habit is to reserve the IDs, write the links into the DCIM as a plan and print the full label set before the hardware arrives. On the night, engineers cable against labels that already exist and a record that already matches. Verification afterwards becomes a comparison, not a reconstruction.

A checklist for your own estate

• Where do your cable IDs come from? If the answer is "the highest plus one", what about deleted links?
• Does anything stop the same number being stored on two links?
• When did you last search your DCIM for duplicate cable IDs?
• Do your labels tell an engineer where the other end goes?
• Are your label print jobs kept anywhere?

Cable numbering is not glamorous. Done properly, it is one of the cheapest ways to keep hands off the wrong cable.

If you would like help bringing order to cabling records, our engineers are happy to share the method. Talk to an engineer

Related: A unique ID on every cable, never reused · DCIM: every object, port, cable and address tracked