VLAN Group utilization is not being calculated correctly #11745

New Issue

adam · 2025-12-29T21:49:22+01:00

adam commented

2025-12-29 21:49:22 +01:00

Originally created by @aq5747 on GitHub (Oct 17, 2025).

Originally assigned to: @pheus on GitHub.

NetBox Edition

NetBox Community

NetBox Version

v4.4.4

Python Version

3.10

Steps to Reproduce

Create a new VLAN group with VLAN IDs value of 1-2.
Create two new VLANs (1 and 2) and assign them to the new VLAN group.
Notice that the VLAN group shows as 66.7% utilized, but it should display as 100%.
Next update the VLAN group to use VLAN IDs value of 1,2
Notice now that the utilization is showing as 50% instead of 100%.

Expected Behavior

VLAN Group utilization should be accurate.

Observed Behavior

VLAN Group utilization is no longer being calculated correctly, as described above.

Originally created by @aq5747 on GitHub (Oct 17, 2025). Originally assigned to: @pheus on GitHub. ### NetBox Edition NetBox Community ### NetBox Version v4.4.4 ### Python Version 3.10 ### Steps to Reproduce 1. Create a new VLAN group with VLAN IDs value of `1-2`. 2. Create two new VLANs (1 and 2) and assign them to the new VLAN group. 3. Notice that the VLAN group shows as 66.7% utilized, but it should display as 100%. 4. Next update the VLAN group to use VLAN IDs value of `1,2` 5. Notice now that the utilization is showing as 50% instead of 100%. ### Expected Behavior VLAN Group utilization should be accurate. ### Observed Behavior VLAN Group utilization is no longer being calculated correctly, as described above.

adam added the type: bug status: accepted netbox severity: low labels 2025-12-29 21:49:22 +01:00

adam closed this issue

2025-12-29 21:49:23 +01:00

adam commented

2025-12-29 21:49:23 +01:00

@aq5747 commented on GitHub (Oct 17, 2025):

Here's what I think is the culprit:

# ipam/models/vlans.py

class VLANGroup(OrganizationalModel):
#...
    def save(self, *args, **kwargs):
        self._total_vlan_ids = 0
        for vid_range in self.vid_ranges:
            self._total_vlan_ids += vid_range.upper - vid_range.lower + 1 # <--- remove the '+ 1' from this line

        super().save(*args, **kwargs)

Adding 1 no longer appears necessary due to the changes to #20478, since the upper range value will always be at least one greater than the lower range value, even for a range of a single VLAN.

@aq5747 commented on GitHub (Oct 17, 2025): Here's what I think is the culprit: ```python # ipam/models/vlans.py class VLANGroup(OrganizationalModel): #... def save(self, *args, **kwargs): self._total_vlan_ids = 0 for vid_range in self.vid_ranges: self._total_vlan_ids += vid_range.upper - vid_range.lower + 1 # <--- remove the '+ 1' from this line super().save(*args, **kwargs) ``` Adding 1 no longer appears necessary due to the changes to #20478, since the upper range value will always be at least one greater than the lower range value, even for a range of a single VLAN.

adam commented

2025-12-29 21:49:24 +01:00

@pheus commented on GitHub (Oct 17, 2025):

Thanks for the clear report! You’re absolutely right, and I’m sorry I missed it.

Context: We standardized ranges to half‑open [lo, hi), but _total_vlan_ids is computed during save(). Most other operations aren’t affected because they operate on the canonical half‑open values stored in PostgreSQL. However, _total_vlan_ids still uses the pre‑save inclusive bounds, so it needs to be corrected.

Plan:

Remove the + 1 from the _total_vlan_ids calculation.
Add a test to ensure 100–199 yield a total of 100

I’m happy to open a fix PR.

Question for maintainers: Should we include a data migration to backfill existing _total_vlan_ids values, or is a lazy recompute on the next save acceptable? If a migration is preferred, I’ll add it to the fix PR.

@pheus commented on GitHub (Oct 17, 2025): Thanks for the clear report! You’re absolutely right, and I’m sorry I missed it. **Context:** We standardized ranges to half‑open `[lo, hi)`, but `_total_vlan_ids` is computed during `save()`. Most other operations aren’t affected because they operate on the canonical half‑open values stored in PostgreSQL. However, `_total_vlan_ids` still uses the pre‑save inclusive bounds, so it needs to be corrected. **Plan:** - Remove the `+ 1` from the `_total_vlan_ids` calculation. - Add a test to ensure `100–199` yield a total of 100 I’m happy to open a fix PR. **Question for maintainers:** Should we include a data migration to backfill existing `_total_vlan_ids` values, or is a lazy recompute on the next save acceptable? If a migration is preferred, I’ll add it to the fix PR.

Sign in to join this conversation.

Branches Tags

main

update-changelog-comments-docs

feature-removal-issue-type

20911-dropdown

20239-plugin-menu-classes-mutable-state

21097-graphql-id-lookups

feature

fix_module_substitution

20923-dcim-templates

20044-elevation-stuck-lightmode

feature-ip-prefix-link

v4.5-beta1-release

20068-import-moduletype-attrs

20766-fix-german-translation-code-literals

20378-del-script

7604-filter-modifiers-v3

circuit-swap

12318-case-insensitive-uniqueness

20637-improve-device-q-filter

20660-script-load

19724-graphql

20614-update-ruff

14884-script

02496-max-page

19720-macaddress-interface-generic-relation

19408-circuit-terminations-export-templates

20203-openapi-check

fix-19669-api-image-download

7604-filter-modifiers

19275-fixes-interface-bulk-edit

fix-17794-get_field_value_return_list

11507-show-aggregate-and-rir-on-api

9583-add_column_specific_search_field_to_tables

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/netbox#11745