Device catalog¶

Before you add devices, it helps to define the catalog they draw from: who makes the hardware, what models exist, and how you classify devices. You build this once and reuse it across every device.

There are four catalog objects, each with its own sidebar page:

Manufacturers¶

The vendor. Create a manufacturer with a name (and optional URL and description) before — or while — creating its device types.

Device types¶

A device type is the reusable hardware template — "a Catalyst 9300-48P is 1U tall, made by Cisco, model C9300-48P." Every device of that model points at the same type, so you describe the hardware once.

Fields:

• Manufacturer, model, part number
• Height (U) — how many rack units it occupies
• Rack width — full (default) or half, for gear like a Mellanox SN2010 where two units mount side-by-side in one U (see half-width devices)
• Full depth — occupies both rack faces (default). Shallow gear unticks this and frees the opposite face in rack elevations
• Airflow, weight — hardware facts (airflow also exists per device as an override)
• Description, tags, custom fields

Device types accept custom fields (target Device types) — handy for catalog-level attributes such as a warranty window or an end-of-life date that belongs to the model, not the individual device.

Importing from the NetBox devicetype-library¶

You rarely have to type a hardware model in by hand. The community devicetype-library (public domain) holds thousands of ready-made definitions, and Danbyte's component templates use the same taxonomy — so they import 1:1. Click Import on the Device types page and either:

• paste GitHub links to .yaml files in the library (one per line — regular blob links work, they're converted automatically),
• paste the YAML itself, or
• upload the .yaml files.

Manufacturers are created as needed. Everything Danbyte models — interfaces, console/console-server ports, power ports/outlets, front/rear ports, module bays, device bays (+ subdevice role, exclude-from-utilisation), inventory items, plus full-depth, airflow, and weight — comes across, and the library's elevation images are downloaded automatically when the file declares them. Module-type files (module-types/…) import through the same dialog — auto-detected. Every construct in the library schema now maps — anything unrecognised in a file would still be reported, never silently dropped.

Stackable switches: the library targets NetBox, which has no stack-position concept, so its port names are literal (GigabitEthernet1/0/1). Tick Stackable during import and Danbyte rewrites the leading slot digit to the {position} token (1/… → {position}/…, Juniper-style 0/… → {position:0}/…) so one imported type serves every member of a stack.

Rack-face images¶

On a device type's detail page you can upload a front image and a rear image of the hardware. These get painted onto the device wherever it appears in a rack elevation, with the device name overlaid — so a rack diagram looks like the real thing. Use the Front / Rear toggle on the rack to switch faces. The same images also render read-only on each device's Overview tab, so you can see the hardware without opening the type.

Jumping to the devices¶

The Devices count on a device type's detail page is a link: it opens the Devices table pre-filtered to that type (the Type facet is seeded from the URL), so you land on exactly those devices — the same foreign-key linkage used throughout Danbyte to keep related objects one click apart.

Component templates¶

A device type owns component templates — the ports the hardware ships with: interfaces, console port(s), power inlets, PDU outlets, and patch-panel rear/front ports. When you create a device of the type, Danbyte stamps every template into a real component on the device, so a "C9300-48P" arrives with its 48 interfaces, console port, and two PSU inlets already in place — no hand-typing ports per device.

Manage them on the device type's Components tab, which splits the eight component kinds — Interfaces, Console ports, Console server ports, Power ports, Power outlets, Rear ports, Front ports, and Aux ports — into sub-tabs with counts. Aux ports are the catch-all for connectors the other kinds don't cover: USB (A/B/C/mini/micro), video outputs (HDMI, VGA, DVI, DisplayPort), SD/microSD slots, RJ11, audio jacks, and grounding lugs — so a device type can model everything on its panel. Template names support two shorthands: a [1-24] range creates one template per port in a single add, and a {position} token resolves to the device's stack member number when components are stamped (and renames ports when a device changes stack position) — see virtual chassis. Notes:

• Materialisation happens on device create (and skips any name the device already has, so imports that pre-create ports are safe). Existing devices are not retro-modified when you edit templates.
• Power outlet templates can reference the power inlet template that feeds them; front-port templates map onto rear-port template positions — the same relationships the concrete components carry.
• Per the zero-pre-filled-data rule, no templates ship — but the type/connector dropdowns follow the standard (NetBox-compatible) taxonomies, so imported device-type definitions carry over.

Faceplate builder¶

Every device draws its front panel at true physical scale — connector cages are sized from the real form-factor dimensions (an SFP28 cage renders narrower than the QSFP28 beside it; an RJ45 jack is taller than both), laid out on an EIA-310-proportioned 1U bar. With no configuration, Danbyte lays the panel out automatically: ports group by slot, split where the media type changes, fill two rows belly-to-belly (odd on top), and bank in twelves — the way real 1U hardware is built.

When the automatic layout isn't how your hardware looks, open the device type's Faceplate tab and build it yourself. The canvas is the panel — the same true-scale drawing devices render, with every cage draggable:

• Toggle between the Front and Rear sides — each is its own layout, and a port lives on exactly one of them.
• Drag templates from the palette (all eight component kinds — interfaces, console, power, aux, panel ports) onto the panel; reorder by dragging, drop onto the dashed + zone to start a new group, double-click a cage to remove it.
• Click a group to edit its label, 1 or 2 rows, and banking (visual gaps every N ports) in the toolbar, or add blank cages and silk-screen label text.
• Save stores the layout on the device type — every device of the type (including each member of a virtual chassis; {position} names resolve per member) renders it, and devices with a rear side get a Front / Rear toggle on their panel. Reset to auto deletes it.

Templates renamed or deleted after a layout was saved render as dashed ghost cages, and the tab counts them so you can tidy up. Interfaces the layout doesn't place are appended automatically — nothing silently disappears.

Device bays (chassis nesting)¶

A parent chassis (blade enclosure, FEX parent) declares device bays on its type (Components → Device bays) and sets Subdevice role: parent; blade/child models set child (usually 0U). Devices of the parent type get concrete bays stamped, and the device page's Ports tab shows a Device bays table — Install… puts a whole child device in a bay (it keeps its own ports, IPs and lifecycle; the bay records where it physically lives). Unlike modules, a bay's occupant is an independent device.

Types can also tick Exclude from utilisation (blanking panels, cable management): they render in elevations but don't count toward the rack's used-units number.

Inventory items¶

Inventory items are serial-tracked physical parts that aren't cabled components — PSUs, fans, CPUs, discrete SFPs. Templates on the device type (Components → Inventory) stamp onto new devices; on the device page's Hardware tab you can add/edit parts with manufacturer, part ID, serial and asset tag, and nest them one level (a fan tray containing fans). Roles are just tags — no pre-filled role catalog, per the zero-data rule.

Module types¶

A module type is a pluggable hardware model — a line card, uplink module, or PSU sled (e.g. a Cisco C9300-NM-8X). It lives under DCIM → Module types and carries its own interface templates, whose names may use the {module} token: when a module is installed into a device's bay, the token resolves to the bay's position (TenGigabitEthernet1/{module}/1 in bay position 1 → …1/1/1), and the {position} stack token still applies after.

The workflow:

1. Give a device type module bay templates (Components → Module bays) — each bay names the slot and sets its position.
2. Devices of the type get concrete bays stamped at creation.
3. On the device page's Ports tab, Install… a module type into an empty bay — its interfaces appear on the device (and its faceplate) instantly. Remove takes exactly those interfaces away again.

Module types have their own Faceplate tab — the same drag-and-drop builder device types get, with the module's interface templates as the palette. When a module with a saved faceplate is installed in a device, its layout is composed into the device's front-panel render at the bay it occupies ({module} in slot names resolves to the bay position, so the cages light up with the real interfaces' state).

Module-type YAMLs from the devicetype-library import through the same Import dialog — they're auto-detected (no u_height), so you can paste module-types/... links right next to device types.

Device roles¶

A role classifies what a device does — access switch, distribution, core, firewall, load balancer. Roles carry a color so devices group visually in lists. Roles also accept custom fields (target Device roles) — for example a service tier or an escalation team.

Platforms¶

A platform is the operating system / NOS a device runs — IOS-XE, JunOS, PAN-OS, Cumulus. Platforms are handy for filtering and for configuration rendering.

All four are yours to define — Danbyte ships none of them, so your catalog contains exactly the vendors, models, roles, and platforms your network uses.