Replies: 1 comment
-
Meaning what - that you have a long list of device models from the drop-down menu, all from the same vendor? You can type a partial name to filter it down, when selecting.
Not necessarily. You can change the model of a device (or change the interfaces on a device type), without repopulating the interfaces on devices of that type - but you may end up with the wrong set of interfaces. There are scripts you can run to highlight the differences and create extra interfaces.
You just have to follow the rules: first create the devices, secondly rename the interfaces using the bulk rename function, and then finally create the stack.
I'm afraid I don't know what you mean by this. The DB structure is just Manufacturer -< Device Type -< Device.
Strongly not recommended. Netbox is meant to be a curated source of truth database (which pushes data to other systems), not a portal onto data collected by some other systems. Please see: https://docs.netbox.dev/en/stable/introduction/#serve-as-a-source-of-truth
Once a device has been created, you can always add new interfaces to it. (This is necessary in any case for logical interfaces like loopbacks and vlan subinterfaces, but nothing stops you adding physical interfaces). It doesn't matter that it diverges from the Device Type it was created from - it becomes independent from the time it is created. Device Type is really just a cookie cutter. If your device actually has slots to plug in new interfaces, then you can model this using Modules and Module Bays. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
First off I know that device types can have interfaces and when you create a new device and associate the type it inherits the interfaces.
Problem 1: If you have lots of device types becomes cumbersome to identify.
Problem 2: If you make a mistake you have to delete the device and re-add it, and if you have lots of dependencies linked via custom fields you have to re-associate all of them
Problem 3: VSS (virtual chassis) and stacked switches cause all types of problems with interface numbering
Problem 4: Models to device associating leaves a lot to be desired, very unintuitive to implement, lots of decencies hard to automate
Solution 1: Auto update each device with napalm and post/push each interface cron job every day
Solution 2: Existing automated way to keep interfaces up-to-date. New modules etc
Solution 3: A way to update interfaces from device without having to delete device and recreate device for new interfaces
Does anyone have a rock solid method?
Beta Was this translation helpful? Give feedback.
All reactions