How to model racks, devices and cabling in DCIM

Someone asks "what's plugged into rack B12, position 24, port 7?" and the honest answer is a walk to the cage with a flashlight. A good DCIM model turns that walk into a lookup. Here's how to build one.

Start with the hierarchy

Every physical model is a nesting of the same idea: a bigger container holds a smaller one. Danbyte follows the familiar NetBox-inspired shape, so if you've used NetBox the vocabulary will feel like home:

Site  →  Location  →  Rack  →  Device  →  Interface/Port  →  Cable
(a building)  (a room/row)  (a cabinet)  (a box)  (a hole)  (a link)

The trick is to model top-down but populate bottom-up: define sites and racks first so there's somewhere to put things, then rack the devices, then cable them. Skip straight to devices without racks and you get an inventory that knows what you own but not where it is.

Sites and locations

A site is a physical boundary — a data center, a colo suite, a branch office. Give it real metadata: address, timezone, region, provider facility ID. That's what makes "show me everything in Frankfurt" a filter instead of a spreadsheet grep.

Inside a site, locations model the sub-structure: a floor, a room, a row, a cage. You don't need every closet on day one, but a shallow location tree pays off the moment you have more than one room: it scopes rack numbering and lets you delegate a room to a team without touching the rest of the site.

Racks and rack units

A rack is where DCIM gets specific. Model it with:

• Height in rack units (U) — usually 42U or 48U, but half-height and open frames matter too.
• Numbering direction — bottom-to-top or top-to-bottom. Pick one convention per site and never mix, or "U24" becomes ambiguous.
• Width and depth — so a 4-post 1000mm cabinet doesn't get modeled the same as a 2-post relay rack.
• Face — front and rear are distinct surfaces; devices occupy space on one or both.

The point of tracking U-height precisely is capacity: when the model knows a rack is 42U with 31U consumed, you can answer "where does this 2U server go?" without measuring anything. A good DCIM renders the rack elevation and refuses to seat a device in occupied units — a cheap guardrail against a physical collision.

Devices and their footprint

A device is any racked thing: server, switch, PDU, patch panel, firewall. Model each with a device type (make/model, U-height, whether it's full-depth) and then place the instance:

• Position — the starting rack unit. A 2U server at position 24 occupies U24–U25.
• Face — mounted on the front or rear.
• Role — access switch, spine, hypervisor, storage — so you can query by function, not just by hostname.

Model the device type once and every instance inherits its port layout and height — define fifty identical top-of-rack switches from one template.

Interfaces, ports, and the front/rear trick

This is where cabling either works or falls apart. A device has typed connection points:

• Interfaces — network ports (Ethernet, SFP+, QSFP) that carry traffic and hold IPs.
• Console and power ports — the out-of-band and electrical connections.
• Front and rear ports — the DCIM answer to patch panels.

A rear port is the permanent structured-cabling side; a front port maps to it as the patchable side. Model a patch panel this way and a cable can pass through it — your trace follows the front port to its rear port to the far end of the trunk, instead of dead-ending at the panel. Get this right and cross-connects stop being black holes.

Cabling: model both ends, including power

A cable connects two termination points — and both ends live in the model. It isn't an attribute of a port; it's an object with an A-side and a B-side, a type (Cat6, OM4, DAC), a length, and optionally a color and label. Model power the same way: PDU outlet to device power port — the connectivity everyone forgets until a feed trips and nobody can list what dies with it.

Because both terminations are first-class, the model walks the whole path — through patch panels — for an end-to-end trace:

srv-web-04  eth0  ──  patch-A  fp12 → rp12  ──  trunk  ──  patch-B  rp12 → fp12  ──  sw-tor-01  Gi1/0/12

Why the cabling work pays off

Modeling cables is the least glamorous step and the one that returns the most:

• Trace connectivity end to end — follow a link across every patch and trunk without touching a device.
• Impact analysis — before you pull a cable or power down a PDU, list exactly what depends on it.
• Faster troubleshooting — "which port?" is a query, and the on-call engineer finds it at 3am without a site visit.

Practical tips from the floor

• Name consistently. A scheme like site-role-nn (fra1-tor-03) sorts and filters cleanly; ad-hoc names don't.
• Label to match the model. The physical label on the cable should equal its DCIM ID. When they diverge, trust erodes and people stop updating either.
• Front vs rear discipline. Terminate structured cabling on rear ports, patch on front ports — always. Consistency here is what makes traces reliable.
• Automate the population. Danbyte exposes a REST API, so you can bulk-import racks and cables from an existing sheet, or reconcile against LLDP with a script rather than typing it all in.

Danbyte models this full stack — sites, racks, devices, ports, cables and power — as one connected graph, and every bit of it ships in the free, open-source release. Self-host it on your own hardware or run the identical software on Danbyte Cloud; either way the feature set behaves the same, and the docs walk you through your first rack.

Model the boring cable today, and thank yourself the next time a feed trips.