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

Originally created by @bitcollector1 on GitHub (Dec 21, 2021).

Originally assigned to: @ITJamie on GitHub.

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

Originally created by @bitcollector1 on GitHub (Dec 21, 2021). Originally assigned to: @ITJamie on GitHub. ### 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. <img width="656" alt="Screen Shot 2021-12-21 at 10 14 00 AM" src="https://user-images.githubusercontent.com/50723251/146979456-d3c5ca46-958d-4158-8e7f-6b4a77f330ea.png"> ### Database changes _No response_ ### External dependencies _No response_

adam added the status: accepted type: feature labels 2025-12-29 19:33:06 +01:00

adam closed this issue

adam commented

@jeremystretch commented on GitHub (Dec 22, 2021):

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.

@jeremystretch commented on GitHub (Dec 22, 2021): 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`](https://netbox.readthedocs.io/en/stable/configuration/dynamic-settings/#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.

adam commented

@sdktr commented on GitHub (Dec 22, 2021):

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.

@sdktr commented on GitHub (Dec 22, 2021): 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.

adam commented

@jeremystretch commented on GitHub (Dec 22, 2021):

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.

@jeremystretch commented on GitHub (Dec 22, 2021): > 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.

adam commented

@bitcollector1 commented on GitHub (Dec 22, 2021):

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!!

@bitcollector1 commented on GitHub (Dec 22, 2021): 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!!

adam commented

@bluikko commented on GitHub (Dec 23, 2021):

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

@bluikko commented on GitHub (Dec 23, 2021): Wouldn't BMC be modeled as just another Interface on a Device, perhaps following a naming convention for a uniform name?

adam commented

@jeremystretch commented on GitHub (Jan 14, 2022):

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 commented on GitHub (Jan 14, 2022): > 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.

adam commented

@bragatto commented on GitHub (Mar 13, 2022):

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

@bragatto commented on GitHub (Mar 13, 2022): Wouldn't it make sense to add the BMC as a child device and have the server as the parent device?

adam commented

@DanSheps commented on GitHub (Apr 6, 2022):

Please continue discussion from #9050 here

@DanSheps commented on GitHub (Apr 6, 2022): Please continue discussion from #9050 here

adam commented

@ITJamie commented on GitHub (Apr 6, 2022):

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

@ITJamie commented on GitHub (Apr 6, 2022): 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

adam commented

@bitcollector1 commented on GitHub (Sep 14, 2022):

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 commented on GitHub (Sep 14, 2022): 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 :(

adam commented

@bitcollector1 commented on GitHub (Sep 14, 2022):

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

@bitcollector1 commented on GitHub (Sep 14, 2022): our users would love to have that IPMI address show up right there on the front page just like the primary IPv4 address does :)

adam commented

@ITJamie commented on GitHub (Sep 23, 2022):

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?

@ITJamie commented on GitHub (Sep 23, 2022): > > 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?

adam commented

@arthanson commented on GitHub (Jan 6, 2023):

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

@arthanson commented on GitHub (Jan 6, 2023): @ITJamie Would you still be interested in working this and submitting a PR, potentially for the upcoming 3.5 release?

adam commented

@ryanmerolle commented on GitHub (Mar 23, 2023):

pushed to 3.6 milestone

@ryanmerolle commented on GitHub (Mar 23, 2023): pushed to 3.6 milestone

adam commented

@ITJamie commented on GitHub (Jun 22, 2023):

@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 https://github.com/netbox-community/netbox/pull/11953#issuecomment-1502166006 then its probably best taken on by another maintainer

@ITJamie commented on GitHub (Jun 22, 2023): @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 https://github.com/netbox-community/netbox/pull/11953#issuecomment-1502166006 then its probably best taken on by another maintainer

adam commented

@jsenecal commented on GitHub (Jul 4, 2023):

After glancing over #13013 I believe I'm actually on the same page as @DanSheps in https://github.com/netbox-community/netbox/pull/11953#issuecomment-1555150918

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.

@jsenecal commented on GitHub (Jul 4, 2023): After glancing over #13013 I believe I'm actually on the same page as @DanSheps in https://github.com/netbox-community/netbox/pull/11953#issuecomment-1555150918 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.

adam commented

@ITJamie commented on GitHub (Jul 4, 2023):

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.

@ITJamie commented on GitHub (Jul 4, 2023): 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.

adam commented

@DanSheps commented on GitHub (Jul 5, 2023):

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

@DanSheps commented on GitHub (Jul 5, 2023): 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

adam commented

@ITJamie commented on GitHub (Jul 5, 2023):

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 commented on GitHub (Jul 5, 2023): 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

adam commented

@ITJamie commented on GitHub (Jul 5, 2023):

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

@ITJamie commented on GitHub (Jul 5, 2023): 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

adam commented