Add support for FibreChannel WWNs for interfaces #1093

@jeremystretch commented on GitHub (Sep 12, 2017):

FYI NetBox uses the PostgreSQL macaddr data type to store MAC addresses, which would not accommodate WWNs.

@jeremystretch commented on GitHub (Sep 12, 2017): FYI NetBox uses the PostgreSQL [`macaddr` data type](https://www.postgresql.org/docs/current/static/datatype-net-types.html) to store MAC addresses, which would not accommodate WWNs.

adam commented

@Zek99 commented on GitHub (Oct 26, 2018):

I was reviewing NetBox for our System Administrators but found the lack of EUI-64 support to be a deal breaker.

As of PostgreSQL v10 it has a data type for EUI-64: macaddr8.

Other than changing the minimum PostgreSQL version, do you have any other ideas on how to achieve EUI-64 support? Storing it as 64bit integer?

@Zek99 commented on GitHub (Oct 26, 2018): I was reviewing NetBox for our System Administrators but found the lack of EUI-64 support to be a deal breaker. As of PostgreSQL v10 it has a data type for EUI-64: [macaddr8](https://www.postgresql.org/docs/10/static/datatype-net-types.html#DATATYPE-MACADDR8). Other than changing the minimum PostgreSQL version, do you have any other ideas on how to achieve EUI-64 support? Storing it as 64bit integer?

adam commented

@cpjs commented on GitHub (Nov 15, 2018):

We are currently rolling out netbox at our place replacing Excel spreadhseets. So far it has been pretty accomodating. But there does seem to be a few features lacking - currently not being able to add the wwpn for our fibre channel interfaces is a little disapointing as most of the things we've found lacking were around virtual machines/servers/etc.

+1 for this feature.

@cpjs commented on GitHub (Nov 15, 2018): We are currently rolling out netbox at our place replacing Excel spreadhseets. So far it has been pretty accomodating. But there does seem to be a few features lacking - currently not being able to add the wwpn for our fibre channel interfaces is a little disapointing as most of the things we've found lacking were around virtual machines/servers/etc. +1 for this feature.

adam commented

@nickel820 commented on GitHub (Feb 10, 2020):

Not sure if there's a better place to vote for this issue, but I'd also like to see Netbox able to record WWNs per interface.

@nickel820 commented on GitHub (Feb 10, 2020): Not sure if there's a better place to vote for this issue, but I'd also like to see Netbox able to record WWNs per interface.

adam commented

@moobys commented on GitHub (Feb 21, 2020):

We are trying to keep track of WWNs in the netbox description fields. It would be great if WWNs could be assigned to interfaces like MAC addresses do.

@moobys commented on GitHub (Feb 21, 2020): We are trying to keep track of WWNs in the netbox description fields. It would be great if WWNs could be assigned to interfaces like MAC addresses do.

adam commented

@christensen-b commented on GitHub (Sep 16, 2020):

I would like to see WWPN available as a searchable field on interfaces. I was testing if this would work using tags, or adding to the description field, but I couldn't locate these test interfaces with a search.

@christensen-b commented on GitHub (Sep 16, 2020): I would like to see WWPN available as a searchable field on interfaces. I was testing if this would work using tags, or adding to the description field, but I couldn't locate these test interfaces with a search.

adam commented

@ericgeldmacher commented on GitHub (Oct 12, 2020):

+1 for EUI-64 support to track WWNs and InfiniBand GUIDs on interfaces.

Edit:
Alternatively, the ability to add custom fields to interfaces would work for me.

@ericgeldmacher commented on GitHub (Oct 12, 2020): +1 for EUI-64 support to track WWNs and InfiniBand GUIDs on interfaces. **Edit:** _Alternatively, the ability to add custom fields to interfaces would work for me._

adam commented

@a31amit commented on GitHub (Oct 13, 2020):

+1 for EUI-64 WWNs and InfiniBand GUIDs support

@a31amit commented on GitHub (Oct 13, 2020): +1 for EUI-64 WWNs and InfiniBand GUIDs support

adam commented

@lastwednesday commented on GitHub (Oct 26, 2020):

This is a key feature for my usage for the product as well. So far I've been having to just make note of the WWN into the Label field for a Rear Interface.

@lastwednesday commented on GitHub (Oct 26, 2020): This is a key feature for my usage for the product as well. So far I've been having to just make note of the WWN into the Label field for a Rear Interface.

adam commented

@jeremystretch commented on GitHub (Oct 27, 2020):

Per the contributing guide:

If the feature you'd like to see has already been requested and is open, click "add a reaction" in the top right corner of the issue and add a thumbs up (+1). This ensures that the issue has a better chance of receiving attention. Also feel free to add a comment with any additional justification for the feature. (However, note that comments with no substance other than a "+1" will be deleted. Please use GitHub's reactions feature to indicate your support.)

This feature request has been open for three years yet has exactly one +1 vote despite all the comments above indicating support.

@jeremystretch commented on GitHub (Oct 27, 2020): Per the contributing guide: > If the feature you'd like to see has already been requested and is open, click "add a reaction" in the top right corner of the issue and add a thumbs up (+1). This ensures that the issue has a better chance of receiving attention. Also feel free to add a comment with any additional justification for the feature. (However, note that comments with no substance other than a "+1" will be deleted. Please use GitHub's reactions feature to indicate your support.) This feature request has been open for three years yet has exactly one +1 vote despite all the comments above indicating support.

adam commented

@lastwednesday commented on GitHub (Dec 17, 2020):

If I could add a use case for this as well, I have been doing a lot of work lately to automate pulling inventory information from Brocade Network Advisor in order to be able to populate status and connections into Netbox, eg for updating port labels based on what is currently logged into the switch on a particular port. The API data I get back from the requests always contains the WWN of the switch port as the key/ID for the stanza, so being able to then query that WWN against the Netbox API to find what Netbox has for that particular interface ID, so as to be able to run a Patch against it would very much simplify the process.

@lastwednesday commented on GitHub (Dec 17, 2020): If I could add a use case for this as well, I have been doing a lot of work lately to automate pulling inventory information from Brocade Network Advisor in order to be able to populate status and connections into Netbox, eg for updating port labels based on what is currently logged into the switch on a particular port. The API data I get back from the requests always contains the WWN of the switch port as the key/ID for the stanza, so being able to then query that WWN against the Netbox API to find what Netbox has for that particular interface ID, so as to be able to run a Patch against it would very much simplify the process.

adam commented

@jeremystretch commented on GitHub (Dec 17, 2020):

This issue has been open a for several years, so I'd love to lock down the specific change being proposed. I'm not very familiar with FibreChannel so I really need the community's help here.

Is it sufficient to simply add a macaddr8 field named wwn to the Interface model? If so, would it make sense to add to VMInterface as well?

I'm okay with bumping the minimum PostgreSQL version to 10 in v2.11 since support for 9.6 is being dropped next year.

@jeremystretch commented on GitHub (Dec 17, 2020): This issue has been open a for several years, so I'd love to lock down the specific change being proposed. I'm not very familiar with FibreChannel so I really need the community's help here. Is it sufficient to simply add a [`macaddr8` field](https://www.postgresql.org/docs/current/datatype-net-types.html#DATATYPE-MACADDR8) named `wwn` to the Interface model? If so, would it make sense to add to VMInterface as well? I'm okay with bumping the minimum PostgreSQL version to 10 in v2.11 since support for 9.6 is being dropped next year.

adam commented

@lastwednesday commented on GitHub (Dec 17, 2020):

I agree that these fields would be useful for the VMInterface model as well so that the WWN/WWPN of VMHBAs could be tracked there.

From my perspective I would say what would be most useful would be macaddr8 fields on the Interface for:

WWN (world wide name)
WWPN (world wide port name)
1. These may or may not be used for every interface depending on platform but are important to have as an option
2. There may be multiple WWPNs associated with a particular WWN, for example given a 4-port HBA card the WWN for the card will be the same but then each port on the card will have a unique WWPN assigned to it. I would expect to create each HBA port as a separate Interface, but having the WWN to associate it back to the physical component would be useful.

Appreciated but not mandatory would be macaddr8 fields on the Interface for:

Remote WWN (world wide name of the end device which is connected to this interface)
Remote WWPN (world wide port name of the end device which is connected to this interface)

The latter two would be most helpful in cases where we want to mark an interface with the details of what occupies it without necessarily having to create a DCIM entry for the end device and cabling, since in many cases those end devices are not under our management, so tracking them in our own DCIM would get to be a lot of overhead.

In cases where cabling is added between interfaces, one could have the Remote WWN/WWPN fields on either side automatically updated based on the WWN/WWPN of the interface it is being cabled to, but this isn't necessary, just an idea.

@lastwednesday commented on GitHub (Dec 17, 2020): I agree that these fields would be useful for the VMInterface model as well so that the WWN/WWPN of VMHBAs could be tracked there. From my perspective I would say what would be most useful would be macaddr8 fields on the Interface for: 1. WWN (world wide name) 1. WWPN (world wide port name) 1. These may or may not be used for every interface depending on platform but are important to have as an option 1. There may be multiple WWPNs associated with a particular WWN, for example given a 4-port HBA card the WWN for the card will be the same but then each port on the card will have a unique WWPN assigned to it. I would expect to create each HBA port as a separate Interface, but having the WWN to associate it back to the physical component would be useful. Appreciated but not mandatory would be macaddr8 fields on the Interface for: 1. Remote WWN (world wide name of the end device which is connected to this interface) 2. Remote WWPN (world wide port name of the end device which is connected to this interface) The latter two would be most helpful in cases where we want to mark an interface with the details of what occupies it without necessarily having to create a DCIM entry for the end device and cabling, since in many cases those end devices are not under our management, so tracking them in our own DCIM would get to be a lot of overhead. In cases where cabling is added between interfaces, one could have the Remote WWN/WWPN fields on either side automatically updated based on the WWN/WWPN of the interface it is being cabled to, but this isn't necessary, just an idea.

adam commented

@cpmills1975 commented on GitHub (Dec 18, 2020):

I'm all for supporting FC as if it uses physical infrastructure it should be documented. But would the addition of more fields to the existing interface forms be appropriate? Since WWN and WWPN presumably (I am equally in the dark on FC) are only relevant to FC and not Ethernet, I'm thinking they shouldn't be present on the Ethernet interface form. Presumably Parent LAG is only relevant to Ethernet and not FC so the same could be applied in reverse.

Note I am referring to form here. Adding a whole new Interface model seems excessive for a couple of new fields so would it be possible to modify the form dynamically based on whether a drop down is set to Ethernet or Fibre Channel or something?

@cpmills1975 commented on GitHub (Dec 18, 2020): I'm all for supporting FC as if it uses physical infrastructure it should be documented. But would the addition of more fields to the existing interface forms be appropriate? Since WWN and WWPN presumably (I am equally in the dark on FC) are only relevant to FC and not Ethernet, I'm thinking they shouldn't be present on the Ethernet interface form. Presumably Parent LAG is only relevant to Ethernet and not FC so the same could be applied in reverse. Note I am referring to form here. Adding a whole new Interface model seems excessive for a couple of new fields so would it be possible to modify the form dynamically based on whether a drop down is set to Ethernet or Fibre Channel or something?

adam commented

@speakster17 commented on GitHub (Dec 21, 2020):

I would like to add a vote for the feature of being able to add WWN to devices.
We have moved to NetBox for all tracking and one of the last things missing is ability to add the WWN for switches and fiber tracking.

@speakster17 commented on GitHub (Dec 21, 2020): I would like to add a vote for the feature of being able to add WWN to devices. We have moved to NetBox for all tracking and one of the last things missing is ability to add the WWN for switches and fiber tracking.

adam commented

@kicker69101 commented on GitHub (Dec 21, 2020):

I no longer have skin in the game because I no longer support netbox at my Org.

With that stated, I believe the easiest approach would be to have the mac address field support both macs and wwns since they are pretty much the same thing (albeit they are used quite a bit differently). We could rename the field to machine address or similar and have a mac and wwn property that could be used to format the data differently and/or other magic sauce.

I'm not so sure about tracking WWPN, because that doesn't really represent the hardware and can change at any moment. Upon change then there would need to be an outside force to update the db. A change could be a simple vm migration from one hypervisor to another. I would much rather see a field for virtual macs/wwns than a wwpn field. But maybe a metadata field or table could be useful to satisfy the needs of virtual addresses, WWPNs, or any other bit of info that is useful for your Org?

I would suggest that we move the MAC/wwn validation and handling out of the db and into code base, because then you can support any database that Django supports. Then the database isn't really a concern for netbox to handle, you will just link them the correct django docs and let them handle it. AFAIK this is the only reason Postgres is required.

I am familiar (but rusty) with FC, so if I'm willing to answer questions about it if wanted.

@kicker69101 commented on GitHub (Dec 21, 2020): I no longer have skin in the game because I no longer support netbox at my Org. With that stated, I believe the easiest approach would be to have the mac address field support both macs and wwns since they are pretty much the same thing (albeit they are used quite a bit differently). We could rename the field to machine address or similar and have a mac and wwn property that could be used to format the data differently and/or other magic sauce. I'm not so sure about tracking WWPN, because that doesn't really represent the hardware and can change at any moment. Upon change then there would need to be an outside force to update the db. A change could be a simple vm migration from one hypervisor to another. I would much rather see a field for virtual macs/wwns than a wwpn field. But maybe a metadata field or table could be useful to satisfy the needs of virtual addresses, WWPNs, or any other bit of info that is useful for your Org? I would suggest that we move the MAC/wwn validation and handling out of the db and into code base, because then you can support any database that Django supports. Then the database isn't really a concern for netbox to handle, you will just link them the correct django docs and let them handle it. AFAIK this is the only reason Postgres is required. I am familiar (but rusty) with FC, so if I'm willing to answer questions about it if wanted.

adam commented

@jeremystretch commented on GitHub (Dec 21, 2020):

I believe the easiest approach would be to have the mac address field support both macs

This isn't tenable because we need to know what type the address is for proper validation. What we could do, though, is add a discrete wwn field, and provide an attribute on the model (e.g. l2_address) that would return whichever value is set.

I would suggest that we move the MAC/wwn validation and handling out of the db and into code base, because then you can support any database that Django supports.

Supporting anything beyond PostgreSQL isn't a design goal, and likely never will be. There are myriad other aspects that would need to be considered beyond this field type, anyway.

@jeremystretch commented on GitHub (Dec 21, 2020): > I believe the easiest approach would be to have the mac address field support both macs This isn't tenable because we need to know what type the address is for proper validation. What we could do, though, is add a discrete `wwn` field, and provide an attribute on the model (e.g. `l2_address`) that would return whichever value is set. > I would suggest that we move the MAC/wwn validation and handling out of the db and into code base, because then you can support any database that Django supports. Supporting anything beyond PostgreSQL isn't a design goal, and likely never will be. There are myriad other aspects that would need to be considered beyond this field type, anyway.

adam commented