Add new field to Device/VM models for out-of-band management IP address

[bitcollector1]

NetBox version

v3.1.2

Feature type

Data model extension

Proposed functionality

BMC IP address is a key management item we track as a custom field, it would be great if the Device Management Box had an option for this information.

Use case

Currently I need to drill down into the interfaces to see the BMC IP address. We are creating custom fields so this information is available on the device page for easy reference, same as the primary IPv4 address.

Database changes

No response

External dependencies

No response

[jeremystretch]

I think what you're referring to as BMC is more generally known as an out-of-band (OOB) management IP (but correct me if I'm mistaken). NetBox has the concept of management-only interfaces (via the mgmt_only boolean attribute), but as you note we don't currently provide a direct link from a device/VM to this IP address.

As seen in the screenshot above, NetBox has two primary IP fields on the device and VM models: primary_ip4 and primary_ip6. The generic primary_ip attribute included in the REST API representation of a device or VM points to one or the other depending on the value of the PREFER_IPV4 configuration parameter.

I'm not sure we'd want to fully replicate this structure for an OOB IP address, but it might make sense to introduce only a single oob_ip ForeignKey field pointing to the desired OOB IP address. I'm open to other opinions.

[sdktr]

Seems like a great use case for 'computed fields'. A type of custom field that is rendered when accessed.
Assuming that the IP can be retrieved from the device object, by filtering on type 'mgmt_only', or a user defined tag.

[jeremystretch]

Seems like a great use case for 'computed fields'.

It would need to be a discrete field, as there could be more than one OOB IP address.

[bitcollector1]

it's nothing critical, once you explained the model it seemed like it was more effort than it was worth. Thanks for consideration, love everything about NetBox. Hope you have a Merry X-Mas!!

[bluikko]

Wouldn't BMC be modeled as just another Interface on a Device, perhaps following a naming convention for a uniform name?

[jeremystretch]

Wouldn't BMC be modeled as just another Interface on a Device, perhaps following a naming convention for a uniform name?

The interface itself would, but I think there's value in introducing a direct relationship to the preferred OOB IP address as well.

I'm going to tag this for milestone assignment with the presumption that it will entail adding a single oob_ip ForeignKey field to the Device model.

[bragatto]

Wouldn't it make sense to add the BMC as a child device and have the server as the parent device?

[DanSheps]

Please continue discussion from #9050 here

[ITJamie]

Based on the convo from the other issue.
We could just look to add the ips of interfaces which have the mgmt_only boolean?

Though I guess thats also not perfect as people could add multiple ips to the interface with mgmt_only.
I can actually think of some older EMC san devices that have multiple ips on their "mgmt" interface even though only one of them is accessible, the others are used for some active/failover tests

Adding an additional foreign key like @jeremystretch mentioned seems like the most obvious solution

[bitcollector1]

just wanted to mention that we tried the workaround for this, the services thing, and it was less than ideal as when the IPMI address is changed it's not reflected in the service template. So this means it's just another thing that needs to be updated :(

[bitcollector1]

our users would love to have that IPMI address show up right there on the front page just like the primary IPv4 address does :)

[ITJamie]

Wouldn't BMC be modeled as just another Interface on a Device, perhaps following a naming convention for a uniform name?

The interface itself would, but I think there's value in introducing a direct relationship to the preferred OOB IP address as well.

I'm going to tag this for milestone assignment with the presumption that it will entail adding a single oob_ip ForeignKey field to the Device model.

@jeremystretch Id be happy to attempt this in a PR if this is something you would consider this as acceptable?

[arthanson]

@ITJamie Would you still be interested in working this and submitting a PR, potentially for the upcoming 3.5 release?

[ryanmerolle]

pushed to 3.6 milestone

[ITJamie]

@arthanson I would be interested in this if it's just another field to the existing models, if the idea is make a new relationships model to do what @jeremystretch mentioned on #11953 (comment) then its probably best taken on by another maintainer

[jsenecal]

After glancing over #13013 I believe I'm actually on the same page as @DanSheps in #11953 (comment)

IMHO this would be better fledged out as a m2m relationship with an intermediary model and some validation to prevent things like duplicate "Primary IPv4" addresses.

[ITJamie]

ok. in which case id need a bit more guidance on how we want that to look (eg guidance on what the extra intermediary model should be called, and even some validation decisions eg can an ip have multiple relationships).

I would have initially suggested ip roles or ip services but theres kind of already terminology in netbox around both of those right now.

From a modeling pov. It would be similar to the FHRPGroupAssignment‎ model with a static list of choices to begin with.

[DanSheps]

My personal views on this:

• One IP address to one "role"
• Static list is definitely the way to go with this. PR's can be put in for additions or we could allow overrides in the config but I don't think it should be exposed in the UI
• I think "Device Functional Role" would be a good name for it, or "IPAddressDeviceFunctionalRole" would probably be the proper name

[ITJamie]

if we did IPAddressDeviceFunctionalRole it would hint that we would need IPAddressVDCFunctionalRole and IPAddressVirtualMachineFunctionalRole.

would we want that or would we want one relationships table to host all of them

here was a quick idea of what I had been thinking:

proposal: 
  add new m2m relationship. name tbd, for now, DeviceIpRelationships. 
  (imho the word role or service would suit better, but is used elsewhere across devices/ip models)

proposed models:
  DeviceIpRelationships:
    fields:
      - device (foriegnkey)
      - ip address (foreignkey)
      - ip address family (str)
      - relationship (str, referencing a choices list)
    constraints:
      - device & ip address & ip family & relationship

adjustments to existing models:

  device:
    fields:
      IpRelationships: a filter (similar to contacts) pointing to DeviceIpRelationships model

I would also assume that we are then going to accept that a whole new list/edit/view would exist for assigning these? or would we try to make it work the same way primary_ip assignments work right now

[ITJamie]

ive created an initial POC of the m2m relationship - https://github.com/netbox-community/netbox/pull/13094/files. any feedback would be appreciated before I go further on this

[jeremystretch]

As the scope of this FR was limited to introducing a field to track out-of-band IPs, and because I'd like this to ship in NetBoxv3.6, I've merged @ITJamie's PR #13013 mostly as-is. If anyone would like to propose a change to the underlying mechanism for tracking primary/OOB IP relationships, they are welcome to do so in a separate FR.