Add support for Infiniband interfaces

[callumstrubi]

Issue type

[x] Feature request
[ ] Bug report
[ ] Documentation

Environment

• Python version: 3.4.1
• NetBox version: 2.2.10

Description

Infiniband is a commonly used verbs communication protocol that is commonly used for high performance computing. Whilst adapters and connectors follow the same form factor as some ethernet, their available protocols are very different. Another factor is that a single form factor connector may support different protocols, and critically the DAC itself has specific protocol support too, so specifying what the protocol is supported on the NIC is critical.

Proposal:
Add all Infiniband interfaces as their protocols within their own category.

Reference:
https://en.wikipedia.org/wiki/InfiniBand

[callumstrubi]

Happy to provide feedback if you need it, though I'm not sure what I'm answering.

[Phhere]

Maybe it is possible to create a new database table for all interface types? so users can add their own interface types. We could also need MPO (https://en.wikipedia.org/wiki/Optical_fiber_connector)

[jeremystretch]

I'm not familiar with Infiniband myself, so a pull request adding the appropriate types to IFACE_FF_CHOICES would be greatly appreciated.

[DanSheps]

This was brought up in IRC as the PR has been put through, and after reviewing some of the documentation, I think this issue should be changed from adding to the form factors to adding to the cable types. My read on Infiniband is that there are two common form factors: CXP & QSFP. The SDR/DDR/FDR/etc are all underlying protocols and cable configurations that are supported by those form factors.

I think it would be a good idea to add "Infiniband" to the form factor list and then add the following form factors:

• CXP
• QSFP

This follows the same vein as FibreChannel where there is a different procotol at work but they use the same form factors.

Then, include the cables as the data rate definers for Infiniband with:

• SDR
• DDR
• FDR
• etc

However, with the recent PR for DAC/AOC cables, we did not define speed there, so that may not be something we want to do with cables either. What is really needed to properly model this is a "module" section where you connect a module, and that module defines the datarate.

My question would be, for someone with an Infiniband switch/device, how does the interface present if you are using a SDR/DDR/FDR etc. Is it defined in the name? If so, then we don't need to worry about the speeds at all.

[candlerb]

Maybe it is possible to create a new database table for all interface types? so users can add their own interface types.

FYI, that was discussed in #84 and #97 but is currently rejected.

[DanSheps]

From #1865

The litmus test for whether something counts as a network interface is generally "can you put an IP address on it, and is it still in common use?" Additionally, "form factor" is a misnomer in this instance (I'd actually like to rename it a some point) as it describes a physical interface type like 1000BASE-TX or SFP+. So we wouldn't add RJ-45, for example, because several Ethernet standards employ it. And I don't know of any DB25/DE9 interfaces which support IP routing still in common use.

I think this hits the nail on the head. Since the Infiniband interfaces aren't physical interfaces, they shouldn't be included in the list themselves. Instead, an Infiniband category and QSFP and CXP are the way forward IMO.

[cmacnevin]

Is there any further movement on this issue? The database / YAML file / whatever for defining our own interface types is still the fastest way to work around limitations in existing supported protocols, but at any rate, Infiniband is important and widely used, and we'd like to incorporate it as a use case.

[jeremystretch]

#2849 is open and awaiting feedback. Have you looked at it?

[cmacnevin]

It looks like it was already committed to develop? Any idea when that will be folded into the main release? Thanks!

[DanSheps]

It looks like it was already committed to develop? Any idea when that will be folded into the main release? Thanks!

No, it is a pull request which is requesting permission to merge the change into develop.

[jeremystretch]

For everyone who claims they want to see this added, #2849 has been open for months with virtually no feedback.

[wols]

I do not need an InfiniBand myself, but I would very much like to be able to define my own interfaces:
We have NTP servers witch 4 x Ethernet and 2 x Power Supply (all no problem) and additional

• 1PPS (BNC)
• Serial Timestring (SubD9)

[jeremystretch]

NetBox only models network interfaces.

[wols]

I understand and accept the argumentation in #84, #97 and #1865.
Strictly speaking, power and console are also not network interfaces - but useful for comprehensive documentation ;-)
My wish is for a complete picture of the necessary connections - achievable with a little flexibility: a user defined list behind "Form factor > Other" can give "Console / Power / Others".
Please!

[jeremystretch]

Strictly speaking, power and console are also not network interfaces

Which is why NetBox uses different models for each of these. The subject of this FR is Infiniband specifically; let's keep the conversation on-topic please.

[cmacnevin]

Infiniband is L2 networking, over which one can run IP, similar to how Ethernet is l2 and you can run IP on it. That's not the native method, but most of the interfaces we run IP on didn't start that way either. It's being used a lot in high performance compute environments, and since people are deploying machine learning and big data clusters a lot these days, its role in data centers will continue to expand. I can see why there's a perceived difference between IB and ethernet, in the same way that people might think of it just as a replacement for FiberChannel, but even FiberChannel is a networking technology which we need to track in our data centers, in the same way we're now tracking cables and patch panels, if nothing else.