NetBox Device Type Library

About this Library

This library is intended to be used for populating device types in NetBox. It contains a set of device type definitions expressed in YAML and arranged by manufacturer. Each file represents a discrete physical device type (e.g. make and model). These definitions can be loaded into NetBox instead of creating new device type definitions manually.

If you would like to contribute to this library, please read through our contributing guide before submitting content.

If you would like to automate the import of these devicetype template files, there is a NetBox Community python script that will check for duplicates, allow you to selectively import vendors, etc. available here netbox-community/Device-Type-Library-Import.

Device Type Definitions

Each definition must include at minimum the following fields:

• manufacturer: The name of the manufacturer which produces this device type.
  • Type: String
• model: The model number of the device type. This must be unique per manufacturer.
  • Type: String
• slug: A URL-friendly representation of the model number. Like the model number, this must be unique per manufacturer. All slugs should have the manufacturers name prepended to it with a dash, please see the example below.
  • Type: String
  • Pattern: "^[-a-z0-9_]+$". Must match the following characters: -, Lowercase a to z, Numbers 0 to 9.
• u_height: The height of the device type in rack units. Increments of 0.5U are supported. (Note: For Child devices u_height must be 0)
  • Type: number (minimum of 0, multiple of 0.5
  • 🧪 Example: u_height: 12.5
• is_full_depth: A boolean which indicates whether the device type consumes both the front and rear rack faces. (Default: true)
  • Type: Boolean
  • 🧪 Example: is_full_depth: false

🧪 Example:

manufacturer: Dell
model: PowerEdge R670
slug: dell-poweredge-r670
u_height: 1
is_full_depth: true

Note: We are asking that all new deivces also include the following optional fields where possible: airflow, weight and weight_unit.

The following fields may optionally be declared:

• part_number: An alternative representation of the model number (e.g. a SKU). (Default: None)
  • Type: String
  • 🧪 Example: part_number: D109-C3
• airflow: A declaration of the airflow pattern for the device. (Default: None)
  • Type: String
  • Options:
    • front-to-rear
    • rear-to-front
    • left-to-right
    • right-to-left
    • side-to-rear
    • rear-to-side
    • bottom-to-top
    • top-to-bottom
    • passive
    • mixed
  • 🧪 Example: airflow: side-to-rear
• front_image: Indicates that this device has a front elevation image within the elevation-images folder. (Default: None)
  • NOTE: The elevation images folder requires the same folder name as this device. The file name must also adhere to <VALUE_IN_SLUG>.front.<acceptable_format>
  • Type: Boolean
  • 🧪 Example: front_image: true
• rear_image: Indicates that this device has a rear elevation image within the elevation-images folder. (Default: None)
  • NOTE: The elevation images folder requires the same folder name as this device. The file name must also adhere to <VALUE_IN_SLUG>.rear.<acceptable_format>
  • Type: Boolean
  • 🧪 Example: rear_image: true
• subdevice_role: Indicates that this is a parent or child device. (Default: None)
  • Type: String
  • Options:
    • parent
    • child
  • 🧪 Example: subdevice_role: parent
• comments: A string field which allows for comments to be added to the device. (Default: None)
  • Type: String
  • 🧪 Example: comments: This is a comment that will appear on all NetBox devices of this type
• is_powered: A boolean which indicates whether the device type does not take power. This is mainly used as a workaround for validation testing on non powered devices (i.e. rackmount kits or patch pannels.) (Default: True)
  • Type: Boolean
  • 🧪 Example: is_powered: false
• weight: A number representing the numeric weight value. Must be a multiple of 0.01 (2 decimal places). (Default: None)
  • Type: Number
  • Value: must be a multiple of 0.01
• weight_unit: A string defining the unit of measurement. It must be one of the supported values. (Default: None)

  • Type: String

  • Options:

    • kg
    • g
    • lb
    • oz

  • 🧪 Example:

    weight: 12.21
    weight_unit: lb
    

For further detail on these attributes and those listed below, please reference the schema definitions and the Component Definitions below.

Module Type Definitions

Each definition must include at minimum the following fields:

• manufacturer: The name of the manufacturer which produces this device type.
  • Type: String
• model: The model number of the device type. This must be unique per manufacturer.
  • Type: String

Note: We are asking that new modules also include the following optional fields where possible: airflow, weight and weight_unit.

The following fields may optionally be declared:

• profile: A declaration of the module profile for the device, only the default Netbox Module Profiles are supported. (Default: None)

  • Type: String
  • Options:
    • CPU
    • Fan
    • GPU
    • Hard disk
    • Memory
    • Power supply
    • Expansion card

• attribute_data: This is for the data associated with the module profile.

  • Type: Object

  • Options:

    • For: profile: CPU
      • architecture Type: string
      • cores Type: integer
      • speed Type: number
    • For: profile: Fan
      • rpm Type: integer
    • For: profile: GPU
      • gpu Type: string
      • interface Type: string (Options: PCIe 4.0, PCIe 4.0 x8, PCIe 4.0 x16, PCIe 5.0 x16)
      • memory Type: integer Required
    • For: profile: Hard disk
      • size Type: integer
      • speed Type: integer
      • disk_type Type: string (Options: HD, SSD, NVME) Required
    • For: profile: Memory
      • class Type: string (Options: DDR3, DDR4, DDR5) Required
      • data_rate Type: integer
      • ecc Type: boolean
      • size Type: integer Required
    • For: profile: Power supply
      • wattage Type: integer
      • hot_swappable Type: boolean Required
      • input_current Type: string (Options: AC, DC) Required
      • input_voltage Type: number Required
    • For: profile: Expansion card
      • bandwidth Type: integer
      • connector_type Type: string

  • 🧪 Example:

    profile: Power supply
    attribute_date:
      wattage: 550
      hot_swappable: true
      input_current: AC
      input_voltage: 240
    

• part_number: An alternative representation of the model number (e.g. a SKU). (Default: None)

  • Type: String
  • 🧪 Example: part_number: D109-C3

• airflow: A declaration of the airflow pattern for the device. (Default: None)

  • Type: String
  • Options:
    • front-to-rear
    • rear-to-front
    • left-to-right
    • right-to-left
    • side-to-rear
    • rear-to-side
    • bottom-to-top
    • top-to-bottom
    • passive
    • mixed
  • 🧪 Example: airflow: side-to-rear

• comments: A string field which allows for comments to be added to the device. (Default: None)

  • Type: String
  • 🧪 Example: comments: This is a comment that will appear on all NetBox devices of this type

• weight: A number representing the numeric weight value. Must be a multiple of 0.01 (2 decimal places). (Default: None)

  • Type: Number
  • Value: must be a multiple of 0.01

• weight_unit: A string defining the unit of measurement. It must be one of the supported values. (Default: None)

  • Type: String
  • Options:
    • kg
    • g
    • lb
    • oz

Rack Type Definitions

Each definition must include at minimum the following fields:

• manufacturer: The name of the manufacturer which produces this rack type.
  • Type: String
• model: The model number of the rack type. This must be unique per manufacturer.
  • Type: String
• slug: A URL-friendly representation of the model number. Like the model number, this must be unique per manufacturer. All slugs should have the manufacturers name prepended to it with a dash, please see the example below.
  • Type: String
  • Pattern: "^[-a-z0-9_]+$". Must match the following characters: -, Lowercase a to z, Numbers 0 to 9.
• form_factor: The form factor of the rack type. This is used to indicate the physical characteristics of the rack, such as whether it is a 4-post frame or a wall-cabinet etc.
  • Type: String
  • 🧪 Example: form_factor: 4-post-frame
• width: The width of the rack type in zoll/inches. This is used to indicate the physical width of the rack, such as whether it is a 19" or 23" rack.
  • Type: Integer
  • 🧪 Example: width: 19
• u_height: The height of the rack type in rack units.
  • Type: Number
  • 🧪 Example: u_height: 42
• starting_unit: The unit number at which the rack starts. This is used to indicate the starting unit number of the rack, such as whether it starts at 1 or 42. The starting unit is normally defined from bottom to top, with the bottom unit being 1.
  • Type: Number
  • 🧪 Example: starting_unit: 1

🧪 Example:

manufacturer: Startech
model: 4 Post 42U
slug: startech-4postrack42
form_factor: 4-post-frame
width: 19
u_height: 42
starting_unit: 1

Note: We are asking that all new racks also include the following optional fields: outer_width, outer_height, outer_depth, outer_unit, weight, max_weight, weight_unit, mounting_depth, and desc_units.

For further detail on these attributes and those listed below, please reference the racktype schema definition

Component Definitions

Valid component types are listed below. Each type of component must declare a list of the individual component templates to be added.

• console-ports
• console-server-ports
• power-ports
• power-outlets
• interfaces
• front-ports
• rear-ports
• module-bays
• device-bays
• inventory-items

The available fields for each type of component are listed below.

Console Ports

Documentation

A console port provides connectivity to the physical console of a device. These are typically used for temporary access by someone who is physically near the device, or for remote out-of-band access provided via a networked console server.

• name: Name
• label: Label
• type: Port type slug (Array)
• _is_power_source: Indicates that the port provides power to the device, only used internally for power validation (default: false)

Console Server Ports

Documentation

A console server is a device which provides remote access to the local consoles of connected devices. They are typically used to provide remote out-of-band access to network devices, and generally connect to console ports.

• name: Name
• label: Label
• type: Port type slug (Array)

Power Ports

Documentation

A power port is a device component which draws power from some external source (e.g. an upstream power outlet), and generally represents a power supply internal to a device. Note: Devices that have removeable Power Supplies, Like FRUs, should be modeled in the device as module-bays and then the PSU module should have the required power-port

• name: Name
• label: Label
• type: Port type slug (Array)
• maximum_draw: The port's maximum power draw, in watts (optional)
• allocated_draw: The port's allocated power draw, in watts (optional)

Power Outlets

Documentation

Power outlets represent the outlets on a power distribution unit (PDU) or other device that supplies power to dependent devices. Each power port may be assigned a physical type, and may be associated with a specific feed leg (where three-phase power is used) and/or a specific upstream power port. This association can be used to model the distribution of power within a device.

• name: Name
• label: Label
• type: Port type slug (Array)
• power_port: The name of the power port on the device which powers this outlet (optional)
• feed_leg: The phase (leg) of power to which this outlet is mapped; A, B, or C (optional)

Interfaces

Documentation

Interfaces in NetBox represent network interfaces used to exchange data with connected devices. On modern networks, these are most commonly Ethernet, but other types are supported as well. IP addresses and VLANs can be assigned to interfaces.

• name: Name
• label: Label
• type: Interface type slug (Array)
• mgmt_only: A boolean which indicates whether this interface is used for management purposes only (default: false)
• poe_mode : For if a device is POE powered (pd) or provides POE (pse)
• poe_type : The classification of PoE transmission supported, for PoE-enabled interfaces.

Front Ports

Documentation

Front ports are pass-through ports which represent physical cable connections that comprise part of a longer path. For example, the ports on the front face of a UTP patch panel would be modeled in NetBox as front ports. Each port is assigned a physical type, and must be mapped to a specific rear port on the same device. A single rear port may be mapped to multiple front ports, using numeric positions to annotate the specific alignment of each.

• name: Name
• label: Label
• type: Port type slug (Array)
• rear_port: The name of the rear port on this device to which the front port maps
• rear_port_position: The corresponding position on the mapped rear port (default: 1)

Rear Ports

Documentation

Like front ports, rear ports are pass-through ports which represent the continuation of a path from one cable to the next. Each rear port is defined with its physical type and a number of positions: Rear ports with more than one position can be mapped to multiple front ports. This can be useful for modeling instances where multiple paths share a common cable (for example, six discrete two-strand fiber connections sharing a 12-strand MPO cable).

• name: Name
• label: Label
• type: Port type slug (Array)
• positions: The number of front ports that can map to this rear port (default: 1)
• _is_power_source: Indicates that the port provides power to the device, only used internally for power validation (default: false)

Module Bays

Documentation

Module bays represent a space or slot within a device in which a field-replaceable module may be installed. A common example is that of a chassis-based switch such as the Cisco Nexus 9000 or Juniper EX9200. Modules in turn hold additional components that become available to the parent device. Note: Field Replacable Power Supply’s should also be modeled as module bays

• name: Name
• label: Label
• position: The alphanumeric position in which this module bay is situated within the parent device. When creating module components, the string {module} in the component name will be replaced with the module bay's position. See the NetBox Documentation for more details.

Device Bays

Documentation

Device bays represent a space or slot within a parent device in which a child device may be installed. For example, a 2U parent chassis might house four individual blade servers. The chassis would appear in the rack elevation as a 2U device with four device bays, and each server within it would be defined as a 0U device installed in one of the device bays. Child devices do not appear within rack elevations or count as consuming rack units.

Child devices are first-class Devices in their own right: That is, they are fully independent managed entities which don't share any control plane with the parent. Just like normal devices, child devices have their own platform (OS), role, tags, and components. LAG interfaces may not group interfaces belonging to different child devices.

• name: Name
• label: Label

Inventory Items

Documentation

As of Netbox 4.3 the use of Inventory Items has been deprecated therefore they are no longer going to be added to this repo, please use module-bays instead Inventory items represent hardware components installed within a device, such as a power supply or CPU or line card. They are intended to be used primarily for inventory purposes.

Inventory items are hierarchical in nature, such that any individual item may be designated as the parent for other items. For example, an inventory item might be created to represent a line card which houses several SFP optics, each of which exists as a child item within the device. An inventory item may also be associated with a specific component within the same device. For example, you may wish to associate a transceiver with an interface.

• name: Name
• label: Label
• manufacturer: The name of the manufacturer which produces this item
• part_id: The part ID assigned by the manufacturer

Module Type Images

Module type images are stored flat under module-images/<manufacturer>/ — images live directly in the manufacturer directory with no per-module subdirectories. A corresponding module-type definition must exist in module-types/ before adding images.

• Naming: <module-type>.(front|rear).<ext> (e.g. RMCARD205.front.png, RMCARD205.rear.png)
  • Filenames must include .front or .rear; bare names like VIC-1227.png (without a side qualifier) are not accepted.
• Content: Only clean orthogonal front or rear face views. Angled, marketing, or side/top shots are not accepted.
• Limit: Maximum 2 images per module type (one front, one rear)

Data Validation / Commit Quality Checks

There are two ways this repo focuses on keeping quality device-type definitions:

• Pre-Commit Checks - Optional, but highly recommended, for helping to identify simple issues before raising a PR. (trailing-whitespace, end-of-file-fixer, check-yaml, yamlfmt, yamllint)
  • Installation
    • Virtual Environment Route
      • It is recommended to create a virtual env for your repo (python3 -m venv venv)
      • Install the required pip packages (pip install -r requirements.txt)
      • Continue to the "Install pre-commit Hooks"
    • pre-commit Only Route
      • Install pre-commit (pip install pre-commit)
    • Install pre-commit Hooks
      • To install the pre-commit script: pre-commit install
  • Usage & Useful pre-commit Commands
    • After staging your files with git, to run the pre-commit script on changed files: pre-commit run
    • To run the pre-commit script on all files: pre-commit run -all
    • To uninstall the pre-commit script: pre-commit uninstall
  • Learn more about pre-commit
• GitHub Actions - Automatically run before a PR can be merged. Repeats yamllint & validates against NetBox Device-Type Schema, note that if this fails then the PR cannot be merged.