Option to attatch MAC Address to IP Addresses #6511

New Issue

adam · 2025-12-29T19:41:48+01:00

adam commented

2025-12-29 19:41:48 +01:00

Originally created by @Decafpancakes on GitHub (May 25, 2022).

NetBox version

v3.2.3

Feature type

New functionality

Proposed functionality

The ability to add an associated MAC to an IP under IPAM IP Addresses without creating Interfaces or Devices. Would also like some sort of validation on the MAC so that they cant repeat. There is also no duplicate check for DNS name either, this would also be important to have.

Use case

This would help the transition from IPPlan to NetBox. Also useful for when exporting to a DHCP server.

Database changes

No response

External dependencies

No response

Originally created by @Decafpancakes on GitHub (May 25, 2022). ### NetBox version v3.2.3 ### Feature type New functionality ### Proposed functionality The ability to add an associated MAC to an IP under IPAM IP Addresses without creating Interfaces or Devices. Would also like some sort of validation on the MAC so that they cant repeat. There is also no duplicate check for DNS name either, this would also be important to have. ### Use case This would help the transition from IPPlan to NetBox. Also useful for when exporting to a DHCP server. ### Database changes _No response_ ### External dependencies _No response_

adam added the type: feature label 2025-12-29 19:41:48 +01:00

adam closed this issue

2025-12-29 19:41:48 +01:00

adam commented

2025-12-29 19:41:49 +01:00

@DanSheps commented on GitHub (May 27, 2022):

The problem with this is that MAC addresses are almost never associated to IP addresses. You get them associated to FHRP groups, interfaces, etc. Your import script should take this into account.

We try to replicate real-world models where possible, and not conform to the needs of other DCIM/IPAM packages which is why our models are setup the way they are.

For DNS names, you can create a custom validator for that.

@DanSheps commented on GitHub (May 27, 2022): The problem with this is that MAC addresses are almost never associated to IP addresses. You get them associated to FHRP groups, interfaces, etc. Your import script should take this into account. We try to replicate real-world models where possible, and not conform to the needs of other DCIM/IPAM packages which is why our models are setup the way they are. For DNS names, you can create a custom validator for that.

adam commented

2025-12-29 19:41:49 +01:00

@jeremystretch commented on GitHub (May 31, 2022):

I'd argue that what you want to model is analogous to an ARP record; a binding between an IP address and a MAC address. NetBox doesn't model these natively (the relationship between IPs and MACs exists through interfaces) but you could easily do so in a plugin.

@jeremystretch commented on GitHub (May 31, 2022): I'd argue that what you want to model is analogous to an ARP record; a binding between an IP address and a MAC address. NetBox doesn't model these natively (the relationship between IPs and MACs exists through interfaces) but you could easily do so in a plugin.

adam commented

2025-12-29 19:41:49 +01:00

@sleepinggenius2 commented on GitHub (Jun 1, 2022):

We have something like this implemented today using a custom field to capture the MAC address for static DHCP reservations. This is absolutely critical for our use case to be able to create the reservations in IPAM and subsequently generate the corresponding DHCP server config. I think OP is talking about a similar use case and I suspect a number of other people are also using NetBox within a DDI solution. We have a simple regex validator in place today for the custom field to catch obviously malformed input, but it would be really nice to have the value standardized/normalized like the interface MAC addresses are today and not have to do that work after they are retrieved for an integration. We are not able to use the Interface model for this, as these are primarily customer devices that we do not have in our network inventory and it would not be practical to do so.

@sleepinggenius2 commented on GitHub (Jun 1, 2022): We have something like this implemented today using a custom field to capture the MAC address for static DHCP reservations. This is absolutely critical for our use case to be able to create the reservations in IPAM and subsequently generate the corresponding DHCP server config. I think OP is talking about a similar use case and I suspect a number of other people are also using NetBox within a DDI solution. We have a simple regex validator in place today for the custom field to catch obviously malformed input, but it would be really nice to have the value standardized/normalized like the interface MAC addresses are today and not have to do that work after they are retrieved for an integration. We are not able to use the Interface model for this, as these are primarily customer devices that we do not have in our network inventory and it would not be practical to do so.

adam commented

2025-12-29 19:41:49 +01:00

@Decafpancakes commented on GitHub (Jun 1, 2022):

@sleepinggenius2 Would you be able to share how you got this setup? Would be a huge help, thanks!

@Decafpancakes commented on GitHub (Jun 1, 2022): @sleepinggenius2 Would you be able to share how you got this setup? Would be a huge help, thanks!

adam commented

2025-12-29 19:41:50 +01:00

@sleepinggenius2 commented on GitHub (Jun 1, 2022):

Sure, we have the custom field set up like this:

Models(s): IPAM > IP address
Name: mac_address
Label: MAC Address
Type: Text
Weight: 100
Required: false
Description: Only use if the IP cannot be associated with an interface, like for customer static DHCP assignments
Filter Logic: Loose
Default: null
Validation regex: ^(?:[A-Fa-f0-9]{2}:){5}[A-Fa-f0-9]{2}$

Interestingly enough, this was the first custom field created in our install. Hope this helps!

@sleepinggenius2 commented on GitHub (Jun 1, 2022): Sure, we have the custom field set up like this: Models(s): IPAM > IP address Name: mac_address Label: MAC Address Type: Text Weight: 100 Required: false Description: Only use if the IP cannot be associated with an interface, like for customer static DHCP assignments Filter Logic: Loose Default: null Validation regex: ^(?:[A-Fa-f0-9]{2}:){5}[A-Fa-f0-9]{2}$ Interestingly enough, this was the first custom field created in our install. Hope this helps!

adam commented

2025-12-29 19:41:50 +01:00

@Decafpancakes commented on GitHub (Jun 1, 2022):

@sleepinggenius2 Thank you for that, I did already have a very similar custom field set up but you filled in some details that I didn't have like the regex value. You had mentioned that you have a script that is exporting the reservations to a dhcp config, could you share this with me since I have to do the same thing? Feel free to msg me: decafpancakes@gmail.com

@Decafpancakes commented on GitHub (Jun 1, 2022): @sleepinggenius2 Thank you for that, I did already have a very similar custom field set up but you filled in some details that I didn't have like the regex value. You had mentioned that you have a script that is exporting the reservations to a dhcp config, could you share this with me since I have to do the same thing? Feel free to msg me: decafpancakes@gmail.com

adam commented

2025-12-29 19:41:50 +01:00

@DanSheps commented on GitHub (Jun 1, 2022):

This is absolutely critical for our use case to be able to create the reservations in IPAM and subsequently generate the corresponding DHCP server config

This would be something you would want to develop a plugin for then. However, you could also obtain this information simply by querying the IP and getting the mac addresses of the interface that an IP is assigned to.

@DanSheps commented on GitHub (Jun 1, 2022): > This is absolutely critical for our use case to be able to create the reservations in IPAM and subsequently generate the corresponding DHCP server config This would be something you would want to develop a plugin for then. However, you could also obtain this information simply by querying the IP and getting the mac addresses of the interface that an IP is assigned to.

adam commented

2025-12-29 19:41:50 +01:00

@sleepinggenius2 commented on GitHub (Jun 1, 2022):

@sleepinggenius2 Thank you for that, I did already have a very similar custom field set up but you filled in some details that I didn't have like the regex value. You had mentioned that you have a script that is exporting the reservations to a dhcp config, could you share this with me since I have to do the same thing? Feel free to msg me: decafpancakes@gmail.com

We are using a combination of Webhooks and a periodic batch audit process to keep the data synchronized with our DHCP server today. Unfortunately, I'm not going to be able to provide that code, as it's part of a larger custom provisioning platform and would vary depending on the specific type of DHCP server that you're using.

This is absolutely critical for our use case to be able to create the reservations in IPAM and subsequently generate the corresponding DHCP server config

This would be something you would want to develop a plugin for then. However, you could also obtain this information simply by querying the IP and getting the mac addresses of the interface that an IP is assigned to.

The issue for us is that we can't associate the IP with an interface, since the device that the IP is assigned to does not exist within our NetBox platform. It is typically CPE that belongs to a customer, and we have not found a practical, non-hacky way to maintain that data in the platform.

I agree wholeheartedly with associating an IP to an interface where possible, which is exactly why I made the field description say what it does. In fact, I would love to see this implemented as maybe another tab under the Interface Assignment section of the IP address form, so you have to explicitly choose to enter the MAC manually. I'm actually working on a custom validator to make sure that the Status is DHCP, has our Static tag set, and is not otherwise assigned to be able to populate our current custom field.

@sleepinggenius2 commented on GitHub (Jun 1, 2022): > @sleepinggenius2 Thank you for that, I did already have a very similar custom field set up but you filled in some details that I didn't have like the regex value. You had mentioned that you have a script that is exporting the reservations to a dhcp config, could you share this with me since I have to do the same thing? Feel free to msg me: [decafpancakes@gmail.com](mailto:decafpancakes@gmail.com) We are using a combination of Webhooks and a periodic batch audit process to keep the data synchronized with our DHCP server today. Unfortunately, I'm not going to be able to provide that code, as it's part of a larger custom provisioning platform and would vary depending on the specific type of DHCP server that you're using. > > This is absolutely critical for our use case to be able to create the reservations in IPAM and subsequently generate the corresponding DHCP server config > > This would be something you would want to develop a plugin for then. However, you could also obtain this information simply by querying the IP and getting the mac addresses of the interface that an IP is assigned to. The issue for us is that we can't associate the IP with an interface, since the device that the IP is assigned to does not exist within our NetBox platform. It is typically CPE that belongs to a customer, and we have not found a practical, non-hacky way to maintain that data in the platform. I agree wholeheartedly with associating an IP to an interface where possible, which is exactly why I made the field description say what it does. In fact, I would love to see this implemented as maybe another tab under the *Interface Assignment* section of the IP address form, so you have to explicitly choose to enter the MAC manually. I'm actually working on a custom validator to make sure that the *Status* is *DHCP*, has our *Static* tag set, and is not otherwise assigned to be able to populate our current custom field.

adam commented

2025-12-29 19:41:50 +01:00

@DanSheps commented on GitHub (Jul 2, 2022):

I think in the context of DHCP, you would be better of having a "DHCPScope" model and then having an association between IPAddress and the scope, with a field on the join table for "MacAddress"

Again, this would have to be done in a plugin as this is likely not to be included in Core.

@DanSheps commented on GitHub (Jul 2, 2022): I think in the context of DHCP, you would be better of having a "DHCPScope" model and then having an association between IPAddress and the scope, with a field on the join table for "MacAddress" Again, this would have to be done in a plugin as this is likely not to be included in Core.

adam commented

2025-12-29 19:41:50 +01:00

@jeremystretch commented on GitHub (Jul 20, 2022):

To summarize the discussion above, there are several options to address this use case:

Map MAC addresses to IP addresses via interface assignment
Add a custom MAC address field to the IP address model
Introduce a new model via a plugin for tracking the specific data structure needed (e.g. ARP record or DHCP lease)

@jeremystretch commented on GitHub (Jul 20, 2022): To summarize the discussion above, there are several options to address this use case: * Map MAC addresses to IP addresses via interface assignment * Add a custom MAC address field to the IP address model * Introduce a new model via a plugin for tracking the specific data structure needed (e.g. ARP record or DHCP lease)

Sign in to join this conversation.

Branches Tags

main

update-changelog-comments-docs

feature-removal-issue-type

20911-dropdown

20239-plugin-menu-classes-mutable-state

21097-graphql-id-lookups

feature

fix_module_substitution

20923-dcim-templates

20044-elevation-stuck-lightmode

feature-ip-prefix-link

v4.5-beta1-release

20068-import-moduletype-attrs

20766-fix-german-translation-code-literals

20378-del-script

7604-filter-modifiers-v3

circuit-swap

12318-case-insensitive-uniqueness

20637-improve-device-q-filter

20660-script-load

19724-graphql

20614-update-ruff

14884-script

02496-max-page

19720-macaddress-interface-generic-relation

19408-circuit-terminations-export-templates

20203-openapi-check

fix-19669-api-image-download

7604-filter-modifiers

19275-fixes-interface-bulk-edit

fix-17794-get_field_value_return_list

11507-show-aggregate-and-rir-on-api

9583-add_column_specific_search_field_to_tables

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/netbox#6511