Data Model Limitations
NetBox is an extremely powerful tool for modeling network components and topologies. However, it doesn't (yet) support several fairly common complex scenarios which are difficult to model. This page seeks to compile such cases for reference and encourage exploration into potential solutions.
Physical Modeling
Logical Modeling
A breakout cable is a special type of cable which connects a single termination on one side to multiple terminations on the other. A common example is a cable which connects four 10 Gigabit Ethernet interfaces to a single channelized 40 Gigabit Ethernet interface. It looks like this:
Channelized interfaces are tricky to model because they combine four discrete interfaces into a single physical termination point. For example, a channelized 40GE interface on Junos will appear to the device as four individual 10GE interfaces:
xe-0/0/0:0
xe-0/0/0:1
xe-0/0/0:2
xe-0/0/0:3
Although they share a physical termination point, each of these functions as an individual interface: Each can be enabled or disabled and configured without consideration of its peers, and each one passes data back and forth to exactly one other interface on the other end of the cable. For these reasons, NetBox models each 10GE channel as its own interface.
This poses a problem for the cable model, which expects and supports only a single interface assignment to either of its two ends.
The recommended approach for modeling breakout cables is to create a separate cable instance for each channelized interface. Although not technically correct, it is perhaps the "least incorrect" possible deviation and ensures that all functions and configurations beyond the physical termination details can be reliably modeled.
Device A [xe-0/0/0:0] ---(Cable 1)--- [eth0] Device B
Device A [xe-0/0/0:1] ---(Cable 1)--- [eth0] Device C
Device A [xe-0/0/0:2] ---(Cable 1)--- [eth0] Device D
Device A [xe-0/0/0:3] ---(Cable 1)--- [eth0] Device E
It's very common for certain lower-end branch or SMB network devices to make a logical interface available via one of two physical connections (typically twisted pair copper or SFP). For example, the Juniper ACX1100-AC provides a set of four copper and four SFP interfaces numbered 0/1/0 through 0/1/3: Each position can utilize either the copper port or its SFP peer, but not both.
These are difficult to model because it forces a layer of abstraction between the logical interface and its physical counterpart. Depending on the device, it might not even be possible to tell which physical port is in use.
The recommended approach in this case is to only model the physical interface that you intend to use, and simply ignore the existence of its alternate. While not a perfectly accurate, it's the solution most likely to avoid confusion and user error. (Be sure to designate the correct interface type when adding these interfaces to NetBox.)
Certain switch products, such as Cisco's Nexus series, can utilize physically separate switches as remote line cards (or "fabric extenders") of a parent device. These devices appear logically as line cards belonging to the switch, but are typically connected using regular Ethernet links and may physically reside far from the parent device. On top of this, such remote line cards are often connected to two parent devices, which share a common management plane.
This concept is difficult to model because it requires a layer of abstraction to treat the parent-to-child links differently from normal links.
The recommended approach is to create all of the parent and child devices as physical devices, and then create a virtual chassis to group them in NetBox as a single logical entity. You'll probably still want to create the physical connections between parents and children to ensure the cables are modeled appropriately, although currently there's no mechanism for designating these as intra-chassis links.
A common solution when multiple default gateways serve a common prefix is to advertise a virtual IP address using a next-hop resolution such as VRRP, HSRP, or GLBP. This IP is "shared" by two or more devices. Because NetBox requires each IP address be assigned to a specific interface, there's not currently a precise way to model this concept.
On each interface which participates in the NHRP group, assign both its own normal, unique IP address as well as a copy of the shared IP address, with the later having its role designated as the appropriate NHRP protocol. (Use "VIP" when no dynamic protocol is in use.) See feature request #2456 for further discussion on potential solutions.