Replies: 1 comment 6 replies
-
If you're doing that, then you're using Netbox wrongly - although it's easy to understand why you are, and I did this myself initially until I realised what the right way was. See the note in the documentation here and here.
That's one of the bad consequences of doing it the wrong way. Another consequence is being unable to create a LAG across two ports on different line cards. The right way is to create:
However, as it stands, you can't put interfaces on inventory items, which means you have to add interfaces to the device itself. This is easily done using the bulk add function: literally put Don't define any ports on the device type itself, except for ports which are on the chassis (e.g. console ports, power ports).
I think that device bays will remain for their original purpose, which is for independently managed devices, such as blade servers. You should think of "device bay" as a physical space partition only: a way to install multiple independent devices in the same rack unit. For example, sometimes you get 1U half-width devices: those can be modelled as a parent device with two device bays, and then the two devices "fit" into those bays (even if in reality they're just screwed together side by side) What you describe as "slots" is basically what Inventory Items are. Perhaps one day inventory items will gain the ability to have ports. Personally, I'd be quite happy for the system mainboard to be an inventory item, and all ports move onto inventory items. Then all you need in the device type is the default set of inventory items it comes with. Doing this allows for all sorts of interesting stuff: LOM cards with their own ports, HBAs and NICs with their own ports, and so on. |
Beta Was this translation helpful? Give feedback.
-
|
It sort of makes no sense to apply interfaces to inventory items anyway. In all the equipment I'm familiar with, those interface names will vary depending on what slot the inventory item is inserted in to. |
Beta Was this translation helpful? Give feedback.
-
|
I think it you'd end up with an "inventory item type" as a sort of template, and with interfaces like |
Beta Was this translation helpful? Give feedback.
-
|
I'll give some of my insights on this topic. Replicating the detailed truth on an hardware level seems to be a mantra sometimes, but as a service provider, it have turned out that the logical stuff is more important. An example would be our use of ASR9k with lot of slots and satellites. In real life, modeling the ASR as one device together with satellites as a virtual chassis turned out to fulfill business needs 100%. Ask youself, is the individual slots more important than the interface names for automation? In our case no. In fact, looking at it, in some scenarios we could use one device for a complete L2 domain. My point is, what do you have to achieve? If it is an automation baseline, don't get stuck on too much details as logics are key. If hardware inventory is key baseline, Netbox might not be your best bet. There are alot of asset systems out there. And when you combine one of those with Netbox, you hit Nirvana:-) |
Beta Was this translation helpful? Give feedback.
-
|
ziggekatten, I was using netbox wrongly, and populating the device bays with child devices as modules. Bays are not supposed to work that way. The 'Inventory' item of a devices does exactly that. Brian kindly pointed out to me that I had to use those. So, I'm all good, and I see that you think the same: don't overdetail the truth ! Pieter |
Beta Was this translation helpful? Give feedback.
-
There is a github issue for that: #3333 (but auto-closed because of lack of recent activity) |
Beta Was this translation helpful? Give feedback.
-
Hey,
The current way of working with devices and bays is not very handy..
If I have a chassis with 2 routing engines and 6 slots, I have to create 9 separate devices !
I have to create a different template for each slot a module can be in.
This is, because the interface numbers are based on the slot port (xe-slot/mic/port)
So if I create a devicetemplate, and add the interfaces, I have to already select what the name of the interfaces will be (xe-0/0/0 to xe-0/0/9 for example). This will limit that template to only be usable on the slot0.
For slot1, I have to create another template with ports xe-1/0/0 - xe-1/0/9. and so on
And if you have 10 types of modules, it gets very crowded in the device templates...
If I want to connect 2 devices to eachother. I need to choose the 'bay' device, in stead of the 'chassis' device. that pretty confusing.
I've solved it for now, by creating templates for the bays without interfaces, and manually add the interfaces to my 'chassis' devices.
This still requires me to create devices for each bay. but I don't have to create device templates for each slot (interface numbering issue). I still get a lot of devices in my list that are cluttering the overview.
So I would like an option, that a 'bay' is not linked to a 'device', but only to a device template.
The bay would need some extra fields (like serial number).
Also maybe we could add an 'interface generation template'. for examle "xe-{bayid}/0/[0-9]". When the template is added to the bay, the interfaces are added to the chassis..
Its just a first thought, and I know, a big change to the way devices with bays are handled...
Or we could keep 'bays' and expand the model with 'slots' that have a different behaviour
Pieter
Beta Was this translation helpful? Give feedback.
All reactions