Expand Interface FormFactor / Types #167
Comments
|
Makes sense. When you say FormFactor do you also mean XFP, SFP+, QSFP? |
|
I mean FormFactor as Netbox labels it :)
|
|
+1 |
|
another +1, this would be great. configurable types/form factors would be great as well. |
|
Interface form factors are hard-coded because only a limited set exist in the world. For instance, there is a well-defined set of Ethernet interfaces as standardized by IEEE. Allowing users to create their own pseudo-types is inviting chaos. Of course, I'm happy to create additional form factors, but let's compile a list of exactly what they should be called. |
jeremystretch
added
help wanted
type: feature
|
Would it be possible to add a Form Factor for Serial, or some other descriptor for low speed interfaces? |
|
I think you'll find that form factors are almost infinitely variable depending on how far back in the past you go and what way you stretch the definition of form factor. In some cases you could argue that some of these share the same form factor (ATM, FDDI, POS) because they share the same interface (SC fiber usually) and the primary difference in speeds and even interface type is the transceiver used. I've seen Cisco cards converted from ATM to POS by desoldering the transceiver and replacing them with different ones. But, if you make that argument then everything that rides over an SFP, or an RJ45 is the same form factor. So 100BASE-TX, 1000BASE-T and 10GBASE-T could all be merged.
That doesn't cover really obscure things like AX.25 (amateur packet radio)... I can't think of any others right now. |
|
Looking around my server room the network "sockets" (something I plug into) on the equipment are: Add a few other ports (i.e. CFP, CPAK, XENPAK, and perhaps just "Fiber" for non-transceiver ports) and you've got a solid top-10 of form factors. I've combined SFP & SFP+ here as the same form factor to reduce bloat. Otherwise we'd also have to consider things like SFP28, QSFP+, QSFP28, CFP2, etc... as their adoption grows. |
|
I've added some additional form factors in 76b9a1c. If anyone has any others they'd like to add, please comment here with the group and specific name you'd use for each. |
|
@jeremystretch Looks like a good approach compared to how we were originally discussing to handle form factors. |
|
I do not even use them, but the only modular that I can see people using are the X2s & XENPAKs (both 10G) . |
|
Yeah, I was considering XENPAK and X2, but are those around any more? I suppose the same could be asked of GBICs. |
|
Yes ha, unfortunately, they are. |
|
Would it be possible to add "Unknown" or "Unspecified"? Those might cover the rare cases where someone is doing something weird. It's better than having to enter incorrect data if what you have is not close to any of the choices. |
|
Don't forget to add SFP28 if you are adding QSFP28. |
|
Like @peelman said, please consider adding SFP Fibre Channel interfaces (2,4,8,16 and 32G). Thanks |
|
I would like to get X2 to the list. There is devices/modules with X2 interfaces on the market like Cisco 6500/6800 sup2T. You should support something generic like "Transceiver (10GE)" and "Transceiver (1GE)" because form factor is mandatory field. At the moment you need to select misleading information if your interface form factor is not on the list. |
|
While the "form factors" have been updated, they are still almost exclusively in support of Ethernet standards and not other technologies. Eliminating the terminology "1GE", "10GE", and so on from the "modular" section would correct this and allow FibreChannel, Infiniband, and others to use existing "form factors" without a discrepancy in the stated terminology. As others have suggested, an "other" category would be helpful where an option is not available (i.e. CX4 or X2) |
|
How does this look as far as Ethernet and FibreChannel are concerned? |
FibreChannel is all SFP/SFP+ and in 2/4/6/8/16 speeds. The XFP and 10G items are not relevant to FibreChannel. |
|
@jeremystretch have you considered locking You could then do a merge of the two lists to present the form fields. As others have mentioned there are other "modern" interface types not being considered. HDMI, SDI (my use case for video networks), USB, eSATA, etc. Hard coding all of these options, isn't desirable. But not letting users add them, is limiting as well. Unless you're drawing a hard line, and saying "network" interfaces only? btw, thanks for the awesome tool! |
|
@jamesboswell It makes no sense to allow users to define their own form factors, since a very finite set exist in the real world. And yes, NetBox is intentionally limited to only including network interface types. |
|
This is what I'm including with v1.6: I'm going to close out this issue now as it's been dragging on for months. If anyone would like to request additional interface types, please do so by opening a new issue and enumerating the specific interface form factors you would like to see added. |
|
The way this is currently done seems like a recipe for it to just balloon out of control but still not support how users actually need to use the field. I would be strongly in favour of turning this into a configurable table. I am mostly behind NetBox's strict adherence to its data model, but this is not a data model question, it's about the data itself. Other interface types fit the data model just fine, and yes, they do exist. Is there any reasoning behind why NetBox should only be used for IP network (and console, and power, and storage, and stacking) but not things like KVM or POTS or video distribution or sensor cabling or RF or timecode or RS485 or $proprietary_whatever or whatever other point-to-point interconnect you might find in a datacentre? All these use cases fit the model just fine. Many of them are present in most DCs, which means they need fragmented DCIM or to use $something_else, just because of this. All this seems to achieve is a list that will continually grow but will never be quite right, a built-in expiry date for the code, artificially making NetBox unsuitable (or users abusing what form factors do exist to mean something other than what they say). This is not a good source of truth, nor is it good for usability to have a bunch of locally-unused options there (serial? WTF?). Users should be able to control it, and configure NetBox to handle their 'weird' DCIM needs, or simply adjust the list to better suit their usage. I don't even see SONET in the list, 2.5GBASE-T and 5GBASE-T are coming RSN, it'd be nice to remove clutter I will never need, and it would be REALLY nice to differentiate between 10GBASE-SR and 10GBASE-LR. It doesn't break the model, it just lets the user define how granular they want to be and what interfaces are actually present in their system. Form factor also seems an inappropriate title. It's currently sort of a blend of form factor and a short list of wire protocols. If there's no flexibility, I'd prefer sticking to a strict definition of form factor and get rid of the duplicates (10/100/1000base-T is all the same form factor (usually also T/E carrier), likewise SFP(+) for Ethernet and FC). Perhaps the issue here is conflating the two, and NetBox should consider the RackTables model of having separate physical form factor and media/protocol types. /2c |
These concepts are simply out of scope for NetBox. Sorry, but we have to draw the line somewhere. NetBox is necessarily limited to network, console, and power in the interest of maintainability. If these are hard requirements, NetBox simply isn't the right choice.
Here's my counterpoint: Allowing users to create arbitrary physical interface types, of which only a limited set exist in the real world, will inevitably lead to chaos. All it takes is for one person to create a type named
Happy to add these if someone submits a feature request. We put out new releases of NetBox far more frequently than someone releases a new interface type.
This isn't dependent on the device, but rather the type of transceiver installed within the device. It's inevitably going to vary from one device to another, so it doesn't make sense to specify as part of the device type. In the future we may be able to map transceiver details (gleaned from inventory data) to interfaces but that's still a ways off. |
Yeah, I understand that, but artificially limiting it doesn't seem useful. Out of scope doesn't mean it needs to be excluded; tools should be as flexible as possible as long as it's not compromising their intended purpose. Especially when most of us probably have some oddball things that fit this description that don't really have a good tracking home of their own.
This is what permissions and operational guidelines are for. This is not a problem for which the solution needs to be baked into the software. Your concern can easily be addressed by not allowing normal users to edit device types (I assume this would live in the Django admin panel, so this would be the default situation), placing it in the configuration file, or simply with administrative 'sanctions' for screwing it up. You can make the exact same argument about Device/Circuit Types. It's even worse for Roles, as they are pretty much completely up to the organization to define how they are used.
The point was more about bloating of the list with a bunch of stuff most users aren't going to use but some will need and happen to be interface types you deem legitimate. Obviously nothing added can ever be removed in this model...the list already contains some 'garbage' IMO. Also you do for now. Making this user configurable gives this project runway if you move on to a new gig that isn't so supportive, or lose interest and the project doesn't get picked up by someone else.
Fair enough. I don't really care about modelling the pluggables themselves, but I do want to know what media type a connection is using. Setting this manually on the port, either with or separate from the form factor is probably preferable to me than having to model a module, but either way works, I just want the functionality. |
The concepts you mentioned would need their own set of models, for the same reasons console, power, and network are each discrete sets. Thus, in this context, out of scope equates to not supported.
I have no control over how users assign permissions in NetBox. (I don't have any data to back this up, but I suspect that many people only use the superuser account.) This is why it needs to be baked into the code. Ensuring that users cannot create illegitimate form factors is part of the value NetBox provides.
Totally different concepts. Prefix/VLAN roles are entirely arbitrary organizational constructs, whereas interface form factors are discrete and formally defined.
Nine months into the public release, there are a total of 29 interface types currently supported. I don't feel that this is at all excessive.
I suspect the many people who use those form factors in their network would disagree.
Such is the nature of any open source project. If this is a risk you're not comfortable with, I'd suggest sticking with commercial products (and hoping the selected company doesn't fold).
I suspect we'll see more work on this front once #20 gets under way. Bottom line, the current scheme works well for the functions NetBox aims to fill. While I'm happy to add additional form factors if there's demand for them, it will not be transitioning to a dynamic model, for the reasons I've explained in previous posts. If that does not fit your specific needs, there are plenty of other products to choose from. |
No, apparently it means 'actively blocked', which is quite a different thing. I don't think this will stop me from using NetBox, but it certainly grinds my gears. 'My way or the highway' is a really user-hostile attitude when it comes to things like this, especially when your primary argument can be easily addressed with non-programmatic solutions, if the end-user decides it is in fact a problem. If someone is actively seeking out the 'interface types' table in the Django admin UI, they are probably doing so for a reason. It's not like I'm advocating for this to be a free-form text field with no referential checks.
This is pretty much my point. There is no list that perfectly suits every user, there will either be useless clutter or missing items in almost every deployment, even if I give you that this field should only ever contain things formally defined as some vague idea of a valid network interface (even if it's not an IP interface, despite NetBox allowing that binding).
Understood, I don't think your argument is sound, and I doubt I'm the only one that likes flexibility where it's free, but I'm not going to push further. If the chosen solution for #20 includes media type on the interfaces, we'll still disagree on this but I'll have what I need 😃 . |
Since you seem to think I'm just being stubborn, let's walk through the data model (which you can reference in Please provide an example of a form factor you would add if given the ability that would make sense in this model. |
|
I will throw my two cents in here (though it is probably worth less). @jeremystretch, I find the argument about partitioned data limited at best, if not invalid because in almost every other context in netbox, this issue exists in the same way you described. I could very easily create two device types for the same device model (say ex-4300 and Juniper-EX4300) because I am not paying attention. I tend to agree that you seem to be artificially limiting the scope of netbox in the name of overly strict constraints. Obviously that is a subjective statement, and don't get me wrong I absolutely respect what you have done with netbox and thank you for your work and dedication; it truly is an amazing product! But I think you are overly worried about scope creep in certain areas. As the developer you don't have to account for every single use case (think network vendor here) but you can facilitate a greater number of user's wants by opening up the model a bit. There will certainly always be supported use cases and scenarios and for good reason but a little extensibility never hurt anyone. And let's face it, the vast majority of netbox users are somewhat technically inclined, and are more likely to understand the implications of a given use case (no data to really back that claim up though). Again, just you thoughts, take them for what they are worth. |
|
@lampwins Incidentally, my intention early on was to publish a library of device types in JSON format so that people could simply import the ones they wanted, but it never got off the ground (see #451). Still, not being able to prevent that problem doesn't mean we shouldn't prevent this one.
All I'm saying is that the network interface model should not be used to represent things that are not network interfaces. It's the same reason we have different models for console and power connections. Is that unreasonable? The suggestion here is that users should be able to repurpose the network interface model to represent whatever they want. Can you see why that's a bad idea? |
|
@jeremystretch so I agree it should be for physical interfaces, but I think the argument being made here is that there exist more interface form factors than one person could possibly imagine by themselves.
Not whatever they want, rather any type of physical interface they want. That is the intent, and yes a user could potentially represent a "non-physical" interface with this but i argue this is there prerogative and should not be real concern as no actual technical constraints have been violated. Just to give another arbitrary example, what if I wanted to model the physical GPS connections on my router? By your method, I would need to open an issue, defend my stance and that this type of interface really exists, and wait for an update (granted you are doing great job of getting the releases out often). If that is something you want to do in the long run, more power to you but wouldn't it be better if I could just do it myself and save everyone else the trouble? I understand your argument is that this will open the door to "chaos" but my counter is why does it matter and how much chaos is there really going to be by allowing users to do this? I don't mean to exacerbate this argument as I think everyone has already done so above so I will leave this here. Besides, I think there are more pressings issues that everyone involved could get more value out of anyway. :) |
|
So let's say we create a GPS interface on a device. Here are the problems we run into:
Do you see how a GPS interface differs in function from a network interface? This is why we're not going to use the same model for both. It's the same reason we use different models for console and power: There's other data specific to each class of connection that we might want to track. (Granted, we don't today, but will in the near future.) In fact, the console model would be a much closer fit for a GPS connection. The only reason people fixate on the interface model is because it tracks form factor and they see an opportunity for a quick hack to get what they want. |
|
@jeremystretch If the network interface model isn't the right fit, then that's fine. The ask from me, and others above is there is a need for other types of "network" connections. How that is data modeled is up for debate. From a user perspective, there is a large desire to be able to track other types of interfaces. GPS as mentioned above is one example. In my use case it's a lot of Serial Digital Interface connections on devices that also have true IP addressed GigE connections as well. Ingesting baseband video for example and outputting a IP multicast stream. These aren't your standard routers and servers, but they are mission critical data connections It would be really nice to be able to at least create a SDI port, assign it a port number and map it's relationship to another device/entity. In my case, I don't need IP assignment, etc. So maybe console data model is correct. If I could add a custom field(s) (MPEG program settings, etc.), that would be icing on the cake. |
|
@jamesboswell I understand, and it's probably a perfectly valid use case. But the fact is that NetBox simply does not support that type of connection today. It probably will at some point in the future, but it doesn't right now. What some users fail to recognize is that the absence of a feature does not justify trying to shoehorn data into a different feature to try and make it work. If this is a hard requirement for someone, as I've said before, NetBox just isn't the right choice for them yet. If it's merely a nice-to-have, one can certainly use NetBox for everything it does today and simply abstain from modeling unsupported connections until the data model has been extended appropriately. We've beat the matter to death at this point, so I'm going to ask that people refrain from continuing to comment in this long-closed issue. |
|
My specific use case for this is that we have some DWDM MUX/DEMUX's that are completely passive, and may have many types of traffic going through them. I'd love it if we had generic physical connector options (Such as SC, LC, ST, maybe add the simplex/duplex options) since on my mux that's all that really exists. It isn't Ethernet, or Fiberchannel until you plug something in that is one of those. Right now they're all just "Virtual" but it would be very nice to see the physical connectors properly labeled. |
|
Adding all of these would be great to have support for 100BASE-SX and -FX fiberglas connections. (Yes, basically this should support everything. :) Or give instructions on how to extend https://github.com/digitalocean/netbox/blob/develop/netbox/dcim/constants.py by myself and for what numbers like "IFACE_FF_1GFC_SFP = 3010" are used or mean.) Ok, so now I edited that file, and added them to Ethernet and gave them 810 and 820. How do I get them to be useable via the interface now? (That should be in some sort of wiki, since this seems to happen often, that something is missing here.) |
Might be easiest to make this an admin-configured lookup table.
Rack tables supports dozens of interface types, to the point at which it gets excessively dumb. But being able to define single or multimode for SFPs, and adding Fiber Channel (in 2/4/8/16/32Gb flavors) would probably be a decent start...
The text was updated successfully, but these errors were encountered: