starred/netbox
1
0
Fork 0
mirror of https://github.com/netbox-community/netbox.git synced 2026-03-02 12:30:06 +01:00
Code Issues 273 Packages Projects Releases 10 Wiki Activity

Interface Type Additions for LTE Standards #2357

New Issue
Closed
opened 2025-12-29 17:25:12 +01:00 by adam · 10 comments
adam commented 2025-12-29 17:25:12 +01:00
Owner
Copy Link

Originally created by @tyler-8 on GitHub (Feb 7, 2019).

Environment

  • Python version: 3.6.8
  • NetBox version: 2.5.5

Proposed Functionality

There are multiple LTE standards (similar to WiFi/802.11) so it would also be beneficial to track the particular standard of the interface. These are likely the most common ones out there to start:

IFACE_FF_LTE = 2800
IFACE_FF_LTEA = 2810
IFACE_FF_LTEAP = 2820

[IFACE_FF_LTE, 'LTE'],
[IFACE_FF_LTEA, 'LTE Advanced'],
[IFACE_FF_LTEAP, 'LTE AdvancedPro']

Depending on the discussion, I could see these being grouped under the existing Wireless heading or potentially their own category.

Use Case

LTE is a common method of connectivity for sites or as a backup, or OOBM, even in a datacenter. LTE routers, such as Cisco's 800 or 1100 series, Cradlepoint's IBR platform, etc., have a "Cellular" interface that wirelessly connects to the provider network.

LTE is an IP-based architecture, with interfaces receiving IP addresses from the provider so I think their form factor fits the previous interface type discussions I've read in past issues.

Database Changes

None (representations are handled in code rather than DB structure).

External Dependencies

NA.

Originally created by @tyler-8 on GitHub (Feb 7, 2019). <!-- NOTE: This form is only for proposing specific new features or enhancements. If you have a general idea or question, please post to our mailing list instead of opening an issue: https://groups.google.com/forum/#!forum/netbox-discuss NOTE: Due to an excessive backlog of feature requests, we are not currently accepting any proposals which significantly extend NetBox's feature scope. Please describe the environment in which you are running NetBox. Be sure that you are running an unmodified instance of the latest stable release before submitting a bug report. --> ### Environment * Python version: 3.6.8<!-- Example: 3.5.4 --> * NetBox version: 2.5.5<!-- Example: 2.3.6 --> <!-- Describe in detail the new functionality you are proposing. Include any specific changes to work flows, data models, or the user interface. --> ### Proposed Functionality There are multiple LTE standards (similar to WiFi/802.11) so it would also be beneficial to track the particular standard of the interface. These are likely the most common ones out there to start: ``` IFACE_FF_LTE = 2800 IFACE_FF_LTEA = 2810 IFACE_FF_LTEAP = 2820 [IFACE_FF_LTE, 'LTE'], [IFACE_FF_LTEA, 'LTE Advanced'], [IFACE_FF_LTEAP, 'LTE AdvancedPro'] ``` Depending on the discussion, I could see these being grouped under the existing `Wireless` heading or potentially their own category. <!-- Convey an example use case for your proposed feature. Write from the perspective of a NetBox user who would benefit from the proposed functionality and describe how. ---> ### Use Case LTE is a common method of connectivity for sites or as a backup, or OOBM, even in a datacenter. LTE routers, such as Cisco's 800 or 1100 series, Cradlepoint's IBR platform, etc., have a "Cellular" interface that wirelessly connects to the provider network. LTE is an IP-based architecture, with interfaces receiving IP addresses from the provider so I think their form factor fits the previous interface type discussions I've read in past issues. <!-- Note any changes to the database schema necessary to support the new feature. For example, does the proposal require adding a new model or field? (Not all new features require database changes.) ---> ### Database Changes None (representations are handled in code rather than DB structure). <!-- List any new dependencies on external libraries or services that this new feature would introduce. For example, does the proposal require the installation of a new Python package? (Not all new features introduce new dependencies.) --> ### External Dependencies NA.
adam added the status: acceptedtype: feature labels 2025-12-29 17:25:12 +01:00
adam closed this issue 2025-12-29 17:25:12 +01:00
adam commented 2025-12-29 17:25:13 +01:00
Author
Owner
Copy Link

@DanSheps commented on GitHub (Feb 7, 2019):

I want to point out what was stated in #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 a generic "Cellular" interface (or how Cisco does it: "Dialer", which also covers PPPoE connections) would be the better method here.

@DanSheps commented on GitHub (Feb 7, 2019): I want to point out what was stated in #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 a generic "Cellular" interface (or how Cisco does it: "Dialer", which also covers PPPoE connections) would be the better method here.
adam commented 2025-12-29 17:25:13 +01:00
Author
Owner
Copy Link

@sdktr commented on GitHub (Feb 7, 2019):

I think a generic "Cellular" interface (or how Cisco does it: "Dialer", which also covers PPPoE connections) would be the better method here.

I agree, just like a 'generic' xDSL interface (not in netbox today) instead of all it's flavors.

@sdktr commented on GitHub (Feb 7, 2019): > > I think a generic "Cellular" interface (or how Cisco does it: "Dialer", which also covers PPPoE connections) would be the better method here. I agree, just like a 'generic' xDSL interface (not in netbox today) instead of all it's flavors.
adam commented 2025-12-29 17:25:13 +01:00
Author
Owner
Copy Link

@tyler-8 commented on GitHub (Feb 7, 2019):

@DanSheps I think the LTE case matches those statements quite well (an IP address and description of the physical interface type). This is a description of the physical antenna's capabilities/interface type (LTE vs LTE-A, like 1000BASE-TX and SFP+) rather than the signal.

The bottom of this article lists the different cellular network standards out there, so we could go the full way and define most of the modern ones in a "Cellular" section (which I'm happy to do). I went with the 'primary' LTE flavors, rather than the intricacies of the 3GPP specifications as I think it's a happy medium between too generic and too specific.

"Cellular" is just the interface name in Cisco, it's not a description of the physical component. The hardware component is seen in this Cisco output:

#sh int cell 0/2/0
Cellular0/2/0 is up, line protocol is up
  Hardware is LTE Advanced pluggable - Europe/North America Multimode LTE/DC-HSPA+/HSPA+/HSPA
  Internet address is XXX.XXX.XXX.XXX/32

And LTE is a standard (technically 3GPP) with similar "versioning" as 802.11, which is captured in Netbox already, and just as important (LTE vs LTE-A vs LTE-AP) and IMO, sufficiently different from other wireless or dial based protocols.

@tyler-8 commented on GitHub (Feb 7, 2019): @DanSheps I think the LTE case matches those statements quite well (an IP address and description of the physical interface type). This is a description of the physical antenna's capabilities/interface type (LTE vs LTE-A, like 1000BASE-TX and SFP+) rather than the signal. The bottom of this [article](https://en.wikipedia.org/wiki/LTE_(telecommunication)) lists the different cellular network standards out there, so we could go the full way and define most of the modern ones in a "Cellular" section (which I'm happy to do). I went with the 'primary' LTE flavors, rather than the intricacies of the 3GPP specifications as I think it's a happy medium between too generic and too specific. "Cellular" is just the interface name in Cisco, it's not a description of the physical component. The hardware component is seen in this Cisco output: ``` #sh int cell 0/2/0 Cellular0/2/0 is up, line protocol is up Hardware is LTE Advanced pluggable - Europe/North America Multimode LTE/DC-HSPA+/HSPA+/HSPA Internet address is XXX.XXX.XXX.XXX/32 ``` And LTE is a standard (technically 3GPP) with similar "versioning" as 802.11, which is captured in Netbox already, and just as important (LTE vs LTE-A vs LTE-AP) and IMO, sufficiently different from other wireless or dial based protocols.
adam commented 2025-12-29 17:25:13 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Feb 12, 2019):

I'm happy to add these, but we need to lock down the different specifications that should be defined. I'm not very familiar with cellular service, but providers are not unaccustomed to making up their own specs (looking at you, AT&T). Is there a significant benefit to defining more than just "LTE" for the immediate future?

@jeremystretch commented on GitHub (Feb 12, 2019): I'm happy to add these, but we need to lock down the different specifications that should be defined. I'm not very familiar with cellular service, but providers are not unaccustomed to making up their own specs (looking at you, AT&T). Is there a significant benefit to defining more than just "LTE" for the immediate future?
adam commented 2025-12-29 17:25:13 +01:00
Author
Owner
Copy Link

@tyler-8 commented on GitHub (Feb 12, 2019):

The 3 variations in my OP cover the existing LTE implementations fairly well I think. Those are not carrier-specific names, they are from the 3GPP (basically a standards body for GSM, CDMA, and LTE that is comprised of telecommunications groups around the world).

The term "3GPP specification" covers all GSM (including GPRS and EDGE), W-CDMA (including HSPA) and LTE (including LTE-Advanced and LTE-Advanced Pro) specifications, and the emerging 5G specifications.

The differences between those LTE types is akin to the variations of the 802.11 standard. "LTE" alone would be better than current state, but I can certainly see value in having the subtypes defined as well.

@tyler-8 commented on GitHub (Feb 12, 2019): The 3 variations in my OP cover the existing LTE implementations fairly well I think. Those are not carrier-specific names, they are from the [3GPP](http://www.3gpp.org/specifications/specifications) (basically a standards body for GSM, CDMA, and LTE that is comprised of telecommunications groups around the world). > The term "3GPP specification" covers all GSM (including GPRS and EDGE), W-CDMA (including HSPA) and LTE (including LTE-Advanced and LTE-Advanced Pro) specifications, and the emerging 5G specifications. The differences between those LTE types is akin to the variations of the 802.11 standard. "LTE" alone would be better than current state, but I can certainly see value in having the subtypes defined as well.
adam commented 2025-12-29 17:25:13 +01:00
Author
Owner
Copy Link

@DanSheps commented on GitHub (Feb 12, 2019):

I think what @jeremystretch is asking, is do we really need to get granular with LTE itself? I don't think so.

The main difference I see with LTE, LTE Advanced, and LTE Advanced Pro is the channel bandwidth. I see this as more of a difference between 20/40/80 channel widths in 802.11 and I don't think it necessitates a different standard being added.

HOWEVER, I would see value in adding GSM and W-CDMA, with the LTE so you would have three choices (GSM, CDMA, LTE), because those are significant differences in the technology and not everything is compatible there whereas with LTE Advanced it is still LTE (Just like 802.11n with 20Mhz is still fundamentally the same as 802.11n with 40Mhz channel width)

@DanSheps commented on GitHub (Feb 12, 2019): I think what @jeremystretch is asking, is do we really need to get granular with LTE itself? I don't think so. The main difference I see with LTE, LTE Advanced, and LTE Advanced Pro is the channel bandwidth. I see this as more of a difference between 20/40/80 channel widths in 802.11 and I don't think it necessitates a different standard being added. HOWEVER, I would see value in adding GSM and W-CDMA, with the LTE so you would have three choices (GSM, CDMA, LTE), because those are significant differences in the technology and not everything is compatible there whereas with LTE Advanced it is still LTE (Just like 802.11n with 20Mhz is still fundamentally the same as 802.11n with 40Mhz channel width)
adam commented 2025-12-29 17:25:13 +01:00
Author
Owner
Copy Link

@tyler-8 commented on GitHub (Feb 12, 2019):

do we really need to get granular with LTE itself?

If you had a large fleet of LTE-* capable devices all varying between LTE/LTE-A/LTE-AP you might feel differently. It would be useful to know which devices support which standard. Sometimes this can be sufficiently captured based on the device hardware model - but that isn't always the case.

The main difference I see with LTE, LTE Advanced, and LTE Advanced Pro is the channel bandwidth.

It's a bit more than that. The changes in bandwidth are due to the improvements to 'carrier aggregation' which allows a device to connect to multiple bands at once, thereby achieving (theoretical) significantly higher data rates. In LTE, a device could only connect to one band at a time, LTE-A took this to 5, and LTE-AP took this to 32 (and introduced new bands).

Also MIMO, lower latency, and a few other things. In my opinion the differences between the 3 are significant enough to warrant them being spelled out.

As for GSM and CDMA, those could be useful additions as well. I suspect their use will decline in the networking space, if it hasn't already, CDMA in particular. Both of those protocols don't see much/any evolution of the specification so they certainly won't need any subgroups to define.

Proposed schema:

IFACE_FF_CDMA = 2800
IFACE_FF_GSM = 2810
IFACE_FF_LTE = 2820
IFACE_FF_LTEA = 2830
IFACE_FF_LTEAP = 2840

[IFACE_FF_CDMA, 'CDMA'],
[IFACE_FF_GSM, 'GSM'],
[IFACE_FF_LTE, 'LTE'],
[IFACE_FF_LTEA, 'LTE Advanced'],
[IFACE_FF_LTEAP, 'LTE AdvancedPro']
@tyler-8 commented on GitHub (Feb 12, 2019): > do we really need to get granular with LTE itself? If you had a large fleet of LTE-* capable devices all varying between LTE/LTE-A/LTE-AP you might feel differently. It would be useful to know which devices support which standard. Sometimes this can be sufficiently captured based on the device hardware model - but that isn't always the case. > The main difference I see with LTE, LTE Advanced, and LTE Advanced Pro is the channel bandwidth. It's a bit more than that. The changes in bandwidth are due to the improvements to 'carrier aggregation' which allows a device to connect to multiple bands at once, thereby achieving (theoretical) significantly higher data rates. In LTE, a device could only connect to one band at a time, LTE-A took this to 5, and LTE-AP took this to 32 (and introduced new bands). Also MIMO, lower latency, and a few other things. In my opinion the differences between the 3 are significant enough to warrant them being spelled out. As for GSM and CDMA, those could be useful additions as well. I suspect their use will decline in the networking space, if it hasn't already, CDMA in particular. Both of those protocols don't see much/any evolution of the specification so they certainly won't need any subgroups to define. Proposed schema: ``` IFACE_FF_CDMA = 2800 IFACE_FF_GSM = 2810 IFACE_FF_LTE = 2820 IFACE_FF_LTEA = 2830 IFACE_FF_LTEAP = 2840 [IFACE_FF_CDMA, 'CDMA'], [IFACE_FF_GSM, 'GSM'], [IFACE_FF_LTE, 'LTE'], [IFACE_FF_LTEA, 'LTE Advanced'], [IFACE_FF_LTEAP, 'LTE AdvancedPro'] ```
adam commented 2025-12-29 17:25:13 +01:00
Author
Owner
Copy Link

@DanSheps commented on GitHub (Feb 12, 2019):

It's a bit more than that. The changes in bandwidth are due to the improvements to 'carrier aggregation' which allows a device to connect to multiple bands at once, thereby achieving (theoretical) significantly higher data rates. In LTE, a device could only connect to one band at a time, LTE-A took this to 5, and LTE-AP took this to 32 (and introduced new bands).

Also MIMO, lower latency, and a few other things. In my opinion the differences between the 3 are significant enough to warrant them being spelled out.

These are all similar to N, and we don't differentiate between N and "N Advanced". I would say if there is a need it could be added, but for now just stick with LTE and maybe leave a "gap". I personally don't want an interface list a mile long and adding all of these corner case specifications is going to get:

  1. Tedious to implement
  2. Ridiculously long

If we are doing LTE Advanced, what is to stop someone from requesting 3G, HSPA, etc?

The goal with interfaces is to model the "physical" interface in my understanding, and the "physical" interface here is LTE, the change with LTE/LTE-A/LTE-A-Pro (Sidebar, lets be real, this is just to sell more phones, because the average consumer needs to have the latest and greatest tech and adding "advanced" and "pro" is going to get people jumping. No one would even give it a second look if they said "LTE is now going to support carrier aggregation and larger channel widths" without the "Advanced" or "Advanced Pro" badge) is just expanding the capabilities of those interfaces by bolting on new tech (channel bonding).

@DanSheps commented on GitHub (Feb 12, 2019): > It's a bit more than that. The changes in bandwidth are due to the improvements to 'carrier aggregation' which allows a device to connect to multiple bands at once, thereby achieving (theoretical) significantly higher data rates. In LTE, a device could only connect to one band at a time, LTE-A took this to 5, and LTE-AP took this to 32 (and introduced new bands). > > Also MIMO, lower latency, and a few other things. In my opinion the differences between the 3 are significant enough to warrant them being spelled out. These are all similar to N, and we don't differentiate between N and "N Advanced". I would say if there is a need it could be added, but for now just stick with LTE and maybe leave a "gap". I personally don't want an interface list a mile long and adding all of these corner case specifications is going to get: 1. Tedious to implement 2. Ridiculously long If we are doing LTE Advanced, what is to stop someone from requesting 3G, HSPA, etc? The goal with interfaces is to model the "physical" interface in my understanding, and the "physical" interface here is LTE, the change with LTE/LTE-A/LTE-A-Pro (Sidebar, lets be real, this is just to sell more phones, because the average consumer needs to have the latest and greatest tech and adding "advanced" and "pro" is going to get people jumping. No one would even give it a second look if they said "LTE is now going to support carrier aggregation and larger channel widths" without the "Advanced" or "Advanced Pro" badge) is just expanding the capabilities of those interfaces by bolting on new tech (channel bonding).
adam commented 2025-12-29 17:25:14 +01:00
Author
Owner
Copy Link

@tyler-8 commented on GitHub (Feb 12, 2019):

All I can say is I think the differences are not trivial and that the differentiation would have value for me. In any case, having LTE alone as an option would be preferable to current state.

# Cellular
IFACE_FF_CDMA = 2800
IFACE_FF_GSM = 2810
IFACE_FF_LTE = 2820

[IFACE_FF_CDMA, 'CDMA'],
[IFACE_FF_GSM, 'GSM'],
[IFACE_FF_LTE, 'LTE'],
@tyler-8 commented on GitHub (Feb 12, 2019): All I can say is I think the differences are not trivial and that the differentiation would have value for me. In any case, having `LTE` alone as an option would be preferable to current state. ``` # Cellular IFACE_FF_CDMA = 2800 IFACE_FF_GSM = 2810 IFACE_FF_LTE = 2820 [IFACE_FF_CDMA, 'CDMA'], [IFACE_FF_GSM, 'GSM'], [IFACE_FF_LTE, 'LTE'], ```
adam commented 2025-12-29 17:25:14 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Feb 13, 2019):

I'm going to add GSM, CDMA, and LTE for now. We'll see if the issue of regular/advanced/advanced pro differentiation comes up again once people start using the new LTE option.

@jeremystretch commented on GitHub (Feb 13, 2019): I'm going to add GSM, CDMA, and LTE for now. We'll see if the issue of regular/advanced/advanced pro differentiation comes up again once people start using the new LTE option.
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: accepted 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#2357
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?