Netbox: Add support for FibreChannel WWNs for interfaces

[kicker69101]

Issue type: Can't populate FC WWNs

Python version:2.7.5
NetBox version:2.0.9

I'm unable to add wwns to fc connections. It doesn't have wwn entry, but it does have a mac. When I put it in the mac spot, it states its invalid mac entry (which would make some sense because wwns are longer). Please allow FC connections to be able to input wwns like it should.

[jeremystretch]

This feature request lacks sufficient detail to be actionable. Per the contributing guidelines:

When submitting a feature request on GitHub, be sure to include the following:

• A detailed description of the proposed functionality
• A use case for the feature; who would use it and what value it would add to NetBox
• A rough description of changes necessary to the database schema (if applicable)
• Any third-party libraries or other resources which would be involved

Please extend the request so that it meets all of these requirements. If no response is received within a week, this issue will be closed.

[jeremystretch]

Closing due to lack of reply

[Gelob]

I'd like to re-open this feature request.

When editing an interface if the Form Factor is FiberChannel we should allow entering a WWN.
You could just expand the MAC Address field to allow the syntax of WWNs or we could display another field for WWN if == FiberChannel.

WWNs are important when setting up a storage area network (SAN). Each device has to be registered with the SAN by its WWN before the SAN will recognize it. (In fact, if the SAN has trouble recognizing a device, the WWN registration is usually one of the first things an administrator will check.) The names are usually 128 binary digits (bits) long, but could be 64 bits if the device is older.

There are apparently three different types of WWNs
Original, Registered, and Mapped EUI-64

More info is here: https://en.wikipedia.org/wiki/World_Wide_Name

[jeremystretch]

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

[Zek99]

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?

[cpjs]

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.

[nickel820]

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.

[moobys]

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.

[christensen-b]

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.

[ericgeldmacher]

+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._

[a31amit]

+1 for EUI-64 WWNs and InfiniBand GUIDs support

[lastwednesday]

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.

[jeremystretch]

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.

[lastwednesday]

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.

[jeremystretch]

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.

[lastwednesday]

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)
2. 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:

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.

[cpmills1975]

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?

[speakster17]

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.

[kicker69101]

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.

[jeremystretch]

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.