0U Racks == Enclosures

[Myke]

We've got lots of non-rack cabinets with equipment. I model them in Netbox as 1U racks, and all devices are unracked. I greatly appreciate the locations addition, but it would be handy for Netbox to handle this.

Unless there's if there's a way to do this more elegantly...?

Some examples:

• Many new homes have "media cabinets" built into a closet, for the router, modem, etc
• An office tower where we had to put patch panels in large electrical boxes on every floor for HVAC
• remote POPs cabinets for WISPs
• Pelican cases with various switches and media converters that we throw under trailers at festivals and construction sites

I would posit as a bare minimum, Netbox 'just' needs to allow 0U racks. Additionally allowing a few new rack types to include 'indoor enclosure', 'outdoor cabinet', 'portable case' etc. but we don't need to go too wild here. (although I'm realizing having another rack field for sealed/vented/heated/cooled... okay, into feature creep now ;)

[candlerb]

You can ignore the Rack model entirely, and just create "Locations" which are sub-areas within a Site. Devices can be assigned to a Location without being assigned to a Rack. These will appear as "non-racked devices" within the Location.

It's also useful that Locations can be created hierarchically: e.g. a location could be a floor, a floor can contain rooms, a room can contain a cabinet etc.

You can add a custom field on Location if you want to define the type e.g. "room", "indoor enclosure", "outdoor cabinet" etc.

Put it another way: only use a "rack" if it's actually something that hold one or more rack-mountable components in "U" blocks. (Then you can see why "0U rack" doesn't make any sense - because it's not a rack).

[Myke]

I fully understand the potential for Locations for this, however I'd argue that Locations are less logical than "0U" rack, because if you reconsider a Rack as "an enclosure with mounting rails" and a "cabinet" as a "an enclosure without mountain rails" - they both remain in the same realm of consideration and attributes.

Whereas a Location could be anything from a building, to a room, to a 3" electrical box half-way down a tunnel...? This is mixing the model more than the above.

Judging by the upvotes I'm in the minority here, so be it. But I've been heavily using Locations and my non-racks (and regular 44U racks!) for a year now... I think it makes more sense. It doesn't seem like it would break anything in Netbox to remove the 0U constraint, other than elevations - which are moot in this context either way.

To further my point:

• a custom field we've added to racks is the mounting type, (ie: cage nuts, 10-32, M6, sheet metal, plywood, velcro, pegboard, etc)
• making Connections only contemplates devices in the same Site and Rack, not devices in the same Location
• Racks already allow for dimension and several other parameters that can apply to a cabinet; Locations lack most of that metadata
• Extending Locations to address even some of Rack model is not logical, and duplicative - especially compared to the very minor adjustment to the Racks model suggested here.

Finally - extending your conclusion "only use a 'rack' ... rack-mountable components in 'U' blocks" - then the Rack model should equally not allow for unracked devices.

[candlerb]

making Connections only contemplates devices in the same Site and Rack, not devices in the same Location

That's only the default selection. I think if the "A" side is a device which is not in any Rack, then it would make sense for the "B" side to default to the same Location. If that's not how it works today, then it would be a reasonable feature request IMO.

I take the opposite view to you: if it doesn't have rack ears, then it's not a rack. But each to their own.

the Rack model should equally not allow for unracked devices.

I think that's primarily for sitting things on shelves within a rack. Something can be within a rack, without being bolted to the ears. The thing that it's inside is still a rack.

[mtinberg]

PDUs and other managed infrastructure attached to the rack but not consuming Rack Units are the primary use case for unracked devices. Racks are a useful model because Rack Units are a limited resource that need to be managed and cabinets are already listed as a type of rack when storing dimensions, I'm not sure all the view/edit queries for this data know how to handle a 0U rack, so making a 0U "Wall-mounted cabinet" may need some amount of work/validation. Making a feature request for 0U cabinets can at least put it on the radar however, while using 1U Racks to model this may not be perfectly elegant, it doesn't seem harmful, are there technical issues that the "empty" 1U rack entries causing? You could also make another feature request to add a few more generic rack types to the 5 or so listed too, if you had specific recommendations. In this case I would also recommend just using custom fields for more specific cabinet_type selection list, another for cabinet_ventilation and whatever other data points you want to track. One thing that I try to keep in mind though is if the data is going to be useful for a config automation tool or a report and how much work it takes to gather, enter and maintain the data over time, so as to not bury our network engineers under low-value administrivia. At least for my opinion as a user of Netbox, and probably why you see this as pushback, it's more important to me that Netbox have useful modeling than perfectly elegant or comprehensive modeling. In my experience the effort to get from pretty good to perfect is often not worth it, using locally documented naming conventions, custom_fields, reports or procedures to bridge any gap between the base built-in models and our organizations process has worked well for me. — Mark Tinberg ***@***.***> Division of Information Technology-Network Services University of Wisconsin-Madison

…

________________________________ From: Brian Candler ***@***.***> Sent: Monday, November 7, 2022 10:33 AM To: netbox-community/netbox ***@***.***> Cc: Subscribed ***@***.***> Subject: Re: [netbox-community/netbox] 0U Racks == Enclosures (Discussion #10858) making Connections only contemplates devices in the same Site and Rack, not devices in the same Location That's only the default selection. I think if the "A" side is a device which is not in any Rack, then it would make sense for the "B" side to default to the same Location. If that's not how it works today, then it would be a reasonable feature request IMO. I take the opposite view to you: if it doesn't have rack ears, then it's not a rack. But each to their own. the Rack model should equally not allow for unracked devices. I think that's primarily for sitting things on shelves within a rack. Something can be within a rack, without being bolted to the ears. The thing that it's inside is still a rack. — Reply to this email directly, view it on GitHub<#10858 (reply in thread)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAS7UM7UNOLBAAI7C22BEU3WHEVNTANCNFSM6AAAAAARYOL7VE>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[Myke]

Fundamentally I'm asking for validators=[MinValueValidator(1)... to be zero. Having the other rack/cab types is far less important - agreed.

I pressed back on the pushback because Locations inferior in every way.

And I also agree that automation/auditing tools might see a lot of false capacity in these fake 1U racks. I think Netbox's rack modelling is 99% viable for cabinets. It doesn't even need to be a well supported feature, just allowed.

The discussion is appreciated.

[dfex]

I too am running up against this problem trying to model networks in heavy OT environments (roadside cabinets, manufacturing facilities, solar farms etc.) where a lot of DIN-rail mount switches are used inside electrical and control panels.

DIN rails don't segment nicely like 19" Rack Units, but I was thinking along the lines of a drop-down that could nominate a "rack" as an "enclosure" or "cabinet", and changing the parameters from RU count to number of DIN rails along with width (in mm/inches) for each. Then DIN-rail devices could be added to a specific rail at a position (mm or inches from the left hand side of the rail) and their widths would be subtracted from available DIN-rail length, giving utilisation. This device space would then be reserved and unavailable for other devices in much the same way that the rack occupancy code works today.

Using locations and unracked devices takes away the benefit of utilisation calculation and consistent patching schedules (the rack column for A and B end is missing for "location" cabinets).

I would be interested in funding this development, but will look to see if this functionality can be introduced via a plugin.

[dfex]

The current workaround I'm using for anyone coming across this problem in the future:

1. Create a Rack type that has the same number of RU as you have DIN rails or a multiple of 4 RU which is the approximate spacing a DIN rail would usually need. You can capture the real external dimensions of the panel in the existing Dimensions fields and set the rack width to 10" to indicated that it is not a typical 19" panel.
2. Create a DIN Rail Device Type that is either 1RU or more realistically 4 RU to account for space above and below, set the Parent/Child field to Parent.
3. Now, add Device Bays to the DIN Rail Device Type (e.g.: Device Bay [1-8]). Depending on how detailed you are capturing mounted devices (e.g.: DIN Terminals, Spacers, Circuit Breakers etc.), you may need more than 8 Bays, but you can easily add extra bays manually to a specific DIN Rail device instance if required. It's not like they can be rendered or show DIN Rail utilisation accurately. I typically only care about network devices and any dedicated power supplies, rail-mount FOBOTs and Patch Panels in Netbox. Electrical engineers can draw the rest in CAD if they want.
4. Now, Create Device Types for each of your DIN-Rail mount switches/power supplies/fobots/patch panels, but make sure to set their Parent/Child type to Child. You can then add interfaces, front ports and rear ports to these device types as required.
5. Now you can simply fill your rack with DIN Rail "Devices" and then connect DIN Rail Devices to Device Bays on each DIN Rail.

This method has the benefit of still associating all your network hardware with a particular "rack" (rather than the generic Location container) even if it doesn't render it correctly in the rack drawing, while also giving you a hint which DIN rail the device is mounted rather than the normal "Not Racked" tag when you don't specify an RU.

Vertical DIN rails are a problem, but can also be solved by not racking the vertical DIN rail (and describing it as vertical) and then mounting your DIN-rail devices as normal. You'll just need to come up with a method of conveying whether your "Module Bays" for the vertical rail start from the top or the bottom of the rail.

I'm hopeful there might be a way to solve the lack of rendering by using the Netbox Device View plugin as inspiration.