NetBox Custom Objects (aka Service Mappings)

[rcon-git]

I'd love to get more information about this exciting feature : https://netboxlabs.com/blog/netbox-custom-objects-private-preview/

Will custom objects be making it into the 4.3 train? This sounds like a pretty huge feature and I'd hate for us to have to wait another 4-6 months for 4.4 to take advantage of this.

Does anyone have any screenshots they can share of this feature in action?

[jeremystretch]

The Public Preview (beta) of Custom Objects will be released as a plugin in the 4.3 train later in June, at which point all users can test it themselves and share feedback. To be notified when it becomes available drop your details in this form and we'll reach out.

Custom Objects will not move out of Public Preview (beta) until NetBox 4.4 (~early September) at the earliest.

[cruse1977]

hey @rcon-git - in addition to Jeremy's advice above - this webinar should now be on demand if you'd like a sneak peak - https://netboxlabs.com/events/webinar-netbox-custom-objects/

[rcon-git]

I'd love to hear what anyone else's ideas are for this new feature. I'm looking to model Applications and SaaS licensing with custom objects. Who else has ideas for what they want to use custom models for?

[loubladi]

As an ISP we are planning on modeling some aspects of our DWDM network using Custom Objects. Also we have plans on modeling L3/L2/L1 services providing to our customers.

[mrmrcoleman]

@loubladi I'd love to compare notes on how you're thinking about modelling DWDM. This comes up a lot.

[loubladi]

Currently, we don’t have a finalized model—only ideas we hope to test using Custom Objects, if they prove valid. I’ve described several issues we’re facing in issue #19033.

For modeling DWDM chassis with cards, we’re mostly able to use the default structure: Virtual Chassis → Device → Modules. However, due to the current implementation of naming conventions in NetBox, we’re unable to use automatic interface creation (as discussed in #19414). Instead, we use a script that reads ports directly from the devices and creates them as Interfaces in NetBox.

Next is modeling the network itself. While Layer 1 is technically the physical layer, in current DWDM chassis many of the actual connections are hidden from the user and therefore cannot be modeled as physical Circuits in NetBox.

Here’s an example of what a simple DWDM topology might look like:

We have several vendors and sometimes modeling goes to different levels of abstraction. Most components are relatively straightforward to represent using Rear and Front ports. Parts like amplifiers (Booster, Preamp), C/T Filter, Transponders and Multiplexers are not difficult to model. You can have for each of these components one 1U device but you can also have many of these integrated into single Module card.

The complexity arises with ROADM components. As they are MxN matrixes of connections, that are dynamically reconfigured based on current optical services I don't see any reasonable way to model them in Netbox. For now, we treat them as black boxes—cards with multiple Interfaces that are not internally connected in the model. In our view, this is acceptable, since ROADM provisioning is typically handled by the DWDM controller itself and does not require detailed modeling in NetBox.

The most important aspect for us to model is the links between sites. A good visual representation of this can be seen here:

Using Cables, Circuits, and Front/Rear ports, we can model the actual physical connections—specifically, the Line ports connections between devices. The current Interface model represent Ethernet ports in picture, but there isn't suitable object for OMS/OCH/ODU layers, which span multiple nodes in a DWDM network. My idea was to use Virtual Circuits and map them to appropriate Interface,Rear/Front ports.

We’ve considered developing a plugin to support this, but our current resources are focused on other priorities, such as automated inventory collection and tracking of leased fibers. For now, DWDM modeling is marked as a “nice-to-have” for the future.