starred/netbox
1
0
Fork 0
mirror of https://github.com/netbox-community/netbox.git synced 2026-01-11 21:10:29 +01:00
Code Issues 273 Packages Projects Releases 10 Wiki Activity

Allow for longer mac addresses #6690

New Issue
Closed
opened 2025-12-29 19:43:59 +01:00 by adam · 7 comments
adam commented 2025-12-29 19:43:59 +01:00
Owner
Copy Link

Originally created by @maxiestudies on GitHub (Jul 19, 2022).

NetBox version

v3.2.3

Feature type

Change to existing functionality

Proposed functionality

Allow for mac addresses to have more than 6 words for specific interfaces. Netbox would need to check the interface type and allow for longer mac addresses for interface types that need longer ones.
If I'm interpreting the code correctly, Netbox uses netaddr to validate the MAC addresses. I think that it is possible to create a new dialect like explained here that allows for more than 6 words, and then check for the interface type in the class MACAddressField and allow if the interface is of type infiniband*.

Use case

Infiniband interfaces have 20-byte long mac addresses. At the moment it's not allowed to have such a long mac-address in the mac address field, only 6-byte long ones are allowed

Database changes

No response

External dependencies

No response

Originally created by @maxiestudies on GitHub (Jul 19, 2022). ### NetBox version v3.2.3 ### Feature type Change to existing functionality ### Proposed functionality Allow for mac addresses to have more than 6 words for specific interfaces. Netbox would need to check the interface type and allow for longer mac addresses for interface types that need longer ones. If I'm interpreting the code correctly, Netbox uses netaddr to validate the MAC addresses. I think that it is possible to create a new dialect like explained [here](https://netaddr.readthedocs.io/en/latest/api.html#netaddr.mac_eui48) that allows for more than 6 words, and then check for the interface type in the `class MACAddressField` and allow if the interface is of type infiniband*. ### Use case Infiniband interfaces have 20-byte long mac addresses. At the moment it's not allowed to have such a long mac-address in the mac address field, only 6-byte long ones are allowed ### Database changes _No response_ ### External dependencies _No response_
adam added the type: featurestatus: revisions needed labels 2025-12-29 19:44:00 +01:00
adam closed this issue 2025-12-29 19:44:00 +01:00
adam commented 2025-12-29 19:44:00 +01:00
Author
Owner
Copy Link

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

Ethernet MAC addresses are six-byte values stored as macaddr fields in the PostgreSQL database. Similarly, Fibre Channel WWN addresses are eight-byte values stored in a macaddr8. We won't be making any changes to these fields, as the address formats are well-defined and enforced during validation.

If you'd like to propose a new address type, the place to start would be by citing its formal definition and detailing how the address would be stored in the database. As I'm not familiar with Infiniband myself, I'm afraid I can't be much more help than that.

@jeremystretch commented on GitHub (Jul 20, 2022): Ethernet MAC addresses are six-byte values stored as [`macaddr`](https://www.postgresql.org/docs/10/datatype-net-types.html#DATATYPE-MACADDR) fields in the PostgreSQL database. Similarly, Fibre Channel WWN addresses are eight-byte values stored in a `macaddr8`. We won't be making any changes to these fields, as the address formats are well-defined and enforced during validation. If you'd like to propose a new address type, the place to start would be by citing its formal definition and detailing how the address would be stored in the database. As I'm not familiar with Infiniband myself, I'm afraid I can't be much more help than that.
adam commented 2025-12-29 19:44:00 +01:00
Author
Owner
Copy Link

@maxiestudies commented on GitHub (Jul 21, 2022):

Thanks for the hint, I'll have a look at that and come with a proposal

@maxiestudies commented on GitHub (Jul 21, 2022): Thanks for the hint, I'll have a look at that and come with a proposal
adam commented 2025-12-29 19:44:01 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Aug 8, 2022):

@maxiestudies are you still interested in pursuing this?

@jeremystretch commented on GitHub (Aug 8, 2022): @maxiestudies are you still interested in pursuing this?
adam commented 2025-12-29 19:44:01 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Aug 22, 2022):

Closing this out for inactivity.

@jeremystretch commented on GitHub (Aug 22, 2022): Closing this out for inactivity.
adam commented 2025-12-29 19:44:01 +01:00
Author
Owner
Copy Link

@zeronewb commented on GitHub (Aug 30, 2022):

My 5 cents;
From database point of view, varchar 59 seems fine.

Relevant RFC:
http://www.rfcreader.com/#rfc4391_line472
http://www.rfcreader.com/#rfc4392_line84

IB Specs
IB Specification Vol 2-Release-1.4-2020-04-07.pdf

IB Specification Vol 1-Release-1.4-2020-04-07 (3).pdf

@zeronewb commented on GitHub (Aug 30, 2022): My 5 cents; From database point of view, varchar 59 seems fine. Relevant RFC: http://www.rfcreader.com/#rfc4391_line472 http://www.rfcreader.com/#rfc4392_line84 IB Specs [IB Specification Vol 2-Release-1.4-2020-04-07.pdf](https://github.com/netbox-community/netbox/files/9453429/IB.Specification.Vol.2-Release-1.4-2020-04-07.pdf) [IB Specification Vol 1-Release-1.4-2020-04-07 (3).pdf](https://github.com/netbox-community/netbox/files/9453428/IB.Specification.Vol.1-Release-1.4-2020-04-07.3.pdf)
adam commented 2025-12-29 19:44:01 +01:00
Author
Owner
Copy Link

@maxiestudies commented on GitHub (Sep 12, 2022):

Hi, woul you consider opening this issue again? I'm back from vacation and have time to work on this

@maxiestudies commented on GitHub (Sep 12, 2022): Hi, woul you consider opening this issue again? I'm back from vacation and have time to work on this
adam commented 2025-12-29 19:44:02 +01:00
Author
Owner
Copy Link

@maxiestudies commented on GitHub (Oct 11, 2022):

Yes! But on vacation until the end of the month, so there will be no news until September I guess

On 8. Aug 2022, at 16:29, Jeremy Stretch @.***> wrote:


@maxiestudies are you still interested in pursuing this?

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you were mentioned.

@maxiestudies commented on GitHub (Oct 11, 2022): Yes! But on vacation until the end of the month, so there will be no news until September I guess > On 8. Aug 2022, at 16:29, Jeremy Stretch ***@***.***> wrote: > >  > @maxiestudies are you still interested in pursuing this? > > — > Reply to this email directly, view it on GitHub, or unsubscribe. > You are receiving this because you were mentioned.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
beta
breaking change
complexity: high
complexity: low
complexity: medium
needs milestone
netbox
pending closure
plugin candidate
pull-request
Mirrored from GitHub Pull Request
 severity: high
severity: low
severity: medium
status: accepted
status: backlog
status: blocked
status: duplicate
status: needs owner
status: needs triage
status: revisions needed
status: under review
topic: GraphQL
topic: Internationalization
topic: OpenAPI
topic: UI/UX
topic: cabling
topic: event rules
topic: htmx navigation
topic: industrialization
topic: migrations
topic: plugins
topic: scripts
topic: templating
topic: testing
type: bug
type: deprecation
type: documentation
type: feature
type: housekeeping
type: translation
No Label status: revisions needed type: feature
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
adam
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/netbox#6690
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?