|
|
|
@@ -4,12 +4,6 @@ A device type represents a particular make and model of hardware that exists in
|
|
|
|
|
|
|
|
|
|
Device types are instantiated as devices installed within racks. For example, you might define a device type to represent a Juniper EX4300-48T network switch with 48 Ethernet interfaces. You can then create multiple devices of this type named "switch1," "switch2," and so on. Each device will inherit the components (such as interfaces) of its device type at the time of creation. (However, changes made to a device type will **not** apply to instances of that device type retroactively.)
|
|
|
|
|
|
|
|
|
|
The device type model includes three flags which inform what type of components may be added to it:
|
|
|
|
|
|
|
|
|
|
* `is_console_server`: This device type has console server ports
|
|
|
|
|
* `is_pdu`: This device type has power outlets
|
|
|
|
|
* `is_network_device`: This device type has network interfaces
|
|
|
|
|
|
|
|
|
|
Some devices house child devices which share physical resources, like space and power, but which functional independently from one another. A common example of this is blade server chassis. Each device type is designated as one of the following:
|
|
|
|
|
|
|
|
|
|
* A parent device (which has device bays)
|
|
|
|
@@ -32,6 +26,8 @@ Each device type is assigned a number of component templates which define the ph
|
|
|
|
|
* Power ports
|
|
|
|
|
* Power outlets
|
|
|
|
|
* Network interfaces
|
|
|
|
|
* Front ports
|
|
|
|
|
* Rear ports
|
|
|
|
|
* Device bays (which house child devices)
|
|
|
|
|
|
|
|
|
|
Whenever a new device is created, its components are automatically created per the templates assigned to its device type. For example, a Juniper EX4300-48T device type might have the following component templates defined:
|
|
|
|
@@ -56,32 +52,28 @@ When assigning a multi-U device to a rack, it is considered to be mounted in the
|
|
|
|
|
|
|
|
|
|
A device is said to be full depth if its installation on one rack face prevents the installation of any other device on the opposite face within the same rack unit(s). This could be either because the device is physically too deep to allow a device behind it, or because the installation of an opposing device would impede airflow.
|
|
|
|
|
|
|
|
|
|
## Device Roles
|
|
|
|
|
## Device Components
|
|
|
|
|
|
|
|
|
|
Devices can be organized by functional roles. These roles are fully customizable. For example, you might create roles for core switches, distribution switches, and access switches.
|
|
|
|
|
|
|
|
|
|
---
|
|
|
|
|
|
|
|
|
|
# Device Components
|
|
|
|
|
|
|
|
|
|
There are six types of device components which comprise all of the interconnection logic with NetBox:
|
|
|
|
|
There are eight types of device components which comprise all of the interconnection logic with NetBox:
|
|
|
|
|
|
|
|
|
|
* Console ports
|
|
|
|
|
* Console server ports
|
|
|
|
|
* Power ports
|
|
|
|
|
* Power outlets
|
|
|
|
|
* Network interfaces
|
|
|
|
|
* Front ports
|
|
|
|
|
* Rear ports
|
|
|
|
|
* Device bays
|
|
|
|
|
|
|
|
|
|
## Console
|
|
|
|
|
### Console
|
|
|
|
|
|
|
|
|
|
Console ports connect only to console server ports. Console connections can be marked as either *planned* or *connected*.
|
|
|
|
|
|
|
|
|
|
## Power
|
|
|
|
|
### Power
|
|
|
|
|
|
|
|
|
|
Power ports connect only to power outlets. Power connections can be marked as either *planned* or *connected*.
|
|
|
|
|
|
|
|
|
|
## Interfaces
|
|
|
|
|
### Interfaces
|
|
|
|
|
|
|
|
|
|
Interfaces connect to one another in a symmetric manner: If interface A connects to interface B, interface B therefore connects to interface A. Each type of connection can be classified as either *planned* or *connected*.
|
|
|
|
|
|
|
|
|
@@ -91,10 +83,20 @@ Each interface can also be enabled or disabled, and optionally designated as man
|
|
|
|
|
|
|
|
|
|
VLANs can be assigned to each interface as either tagged or untagged. (An interface may have only one untagged VLAN.)
|
|
|
|
|
|
|
|
|
|
## Device Bays
|
|
|
|
|
### Pass-through Ports
|
|
|
|
|
|
|
|
|
|
Pass-through ports are used to model physical terminations which comprise part of a longer path, such as a cable terminated to a patch panel. Each front port maps to a position on a rear port. A 24-port UTP patch panel, for instance, would have 24 front ports and 24 rear ports. Although this relationship is typically one-to-one, a rear port may have multiple front ports mapped to it. This can be useful for modeling instances where multiple paths share a common cable (for example, six different fiber connections sharing a 12-strand MPO cable).
|
|
|
|
|
|
|
|
|
|
Pass-through ports can also be used to model "bump in the wire" devices, such as a media convertor or passive tap.
|
|
|
|
|
|
|
|
|
|
### Device Bays
|
|
|
|
|
|
|
|
|
|
Device bays represent the ability of a device to house child devices. For example, you might install four blade servers into a 2U chassis. The chassis would appear in the rack elevation as a 2U device with four device bays. 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, but they are included in the "Non-Racked Devices" list within the rack view.
|
|
|
|
|
|
|
|
|
|
## Device Roles
|
|
|
|
|
|
|
|
|
|
Devices can be organized by functional roles. These roles are fully customizable. For example, you might create roles for core switches, distribution switches, and access switches.
|
|
|
|
|
|
|
|
|
|
---
|
|
|
|
|
|
|
|
|
|
# Platforms
|
|
|
|
@@ -118,3 +120,25 @@ Inventory items represent hardware components installed within a device, such as
|
|
|
|
|
A virtual chassis represents a set of devices which share a single control plane: a stack of switches which are managed as a single device, for example. Each device in the virtual chassis is assigned a position and (optionally) a priority. Exactly one device is designated the virtual chassis master: This device will typically be assigned a name, secrets, services, and other attributes related to its management.
|
|
|
|
|
|
|
|
|
|
It's important to recognize the distinction between a virtual chassis and a chassis-based device. For instance, a virtual chassis is not used to model a chassis switch with removable line cards such as the Juniper EX9208, as its line cards are _not_ physically separate devices capable of operating independently.
|
|
|
|
|
|
|
|
|
|
---
|
|
|
|
|
|
|
|
|
|
# Cables
|
|
|
|
|
|
|
|
|
|
A cable represents a physical connection between two termination points, such as between a console port and a patch panel port, or between two network interfaces. Cables can be traced through pass-through ports to form a complete path between two endpoints. In the example below, three individual cables comprise a path between the two connected endpoints.
|
|
|
|
|
|
|
|
|
|
```
|
|
|
|
|
|<------------------------------------------ Cable Path ------------------------------------------->|
|
|
|
|
|
|
|
|
|
|
Device A Patch Panel A Patch Panel B Device B
|
|
|
|
|
+-----------+ +-------------+ +-------------+ +-----------+
|
|
|
|
|
| Interface | --- Cable --- | Front Port | | Front Port | --- Cable --- | Interface |
|
|
|
|
|
+-----------+ +-------------+ +-------------+ +-----------+
|
|
|
|
|
+-------------+ +-------------+
|
|
|
|
|
| Rear Port | --- Cable --- | Rear Port |
|
|
|
|
|
+-------------+ +-------------+
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
All connections between device components in NetBox are represented using cables. However, defining the actual cable plant is optional: Components can be be directly connected using cables with no type or other attributes assigned.
|
|
|
|
|
|
|
|
|
|
Cables are also used to associated ports and interfaces with circuit terminations. To do this, first create the circuit termination, then navigate the desired component and connect a cable between the two.
|
|
|
|
|