Netbox 4.4 Vlan Sites/Group deprecation

[falz]

Netbox 4.4.0 came out and lists:

• Deprecate the assignment of VLANs directly to sites #19738 - The direct assignment of VLANs to sites is now discouraged in favor of VLAN groups

The Justification listed in that case isn't so much of a justification as it is an opinion:

The recommended approach to VLAN management is to create a VLAN group scoped to the site, and assign VLANs to that group.

Someone also asked in the case how this is handled from the API perspective, but it didn't get answered:

I automation I use jinja templates with the device.site.vlans.all() function to get all vlans that are relevant for the specific device. How to replace this function in the jinja templates?

We are curious how this will shake out - since it's deprecated now, I presume removed in 4.5.0/4.6.0. When that happens will something automatically create groups and a group to site association?

Or is there an expectation that that is completed manually prior to 4.5?

In our case we only have one vlan per site (at most) but very few sites with vlans, so it's creating a vlan group to hold a single VLAN - so some busywork, but probably ok.

Just looking for clarification of these things so people know what to do well in advance of vlan to site being removed.

[MANT5149]

Also curious about this. Have many sites with one VLAN directly assigned, so I'm not following the need to create a group to hold one VLAN. If the decision is made to continue, will this process be automated during the upgrade, or do we have to undo site assignments before upgrading?

[ZPrimed]

In addition to all of the above - we have a use case where VLANs need to span multiple sites (P2P RF links between sites). Currently we just put the same number at both sites and it's "assumed" to be the same... but if we're losing the ability to assign VLANs to sites then this is no longer viable.

Representing this with VLAN Groups will be somewhat cumbersome, as it will require creation of arbitrary Site Groups or Regions to contain the sites using the same VLANs, since a single VLAN Group can't be scoped to multiple sites at the same time (AFAIK).

[mitchplze]

Also looking for clarification on this one, and why the decision was made / who it benefits. Right now it's easy to see what Site or other scope a VLAN is assigned to (and sort / filter by this) but it seems we will soon be forced to add a redundant level of organization - for reasons that aren't at all clear. There does not seem to be a value-add here, and I don't understand the reason behind the change.

[patrickpreuss]

I think VLANs should be a first-class concept on the device model, not an afterthought—e.g. something like:

device.vlans.all() (and ideally device.vlans.effective() if we support inheritance/aggregation)

We need this because we’ll have multiple VLAN “sources” / relationships that must be modeled, for example:

• Site A → Access VLANs
• Site A → Server VLANs
• Site A–B → Inter-site / transit VLANs

Different devices will consume different combinations of these:

• some inherit only Site A Access VLANs,
• others need two of the three,
• and some need all three.

We also need to account for platform-predefined VLANs that exist by default (e.g., Cisco Catalyst reserved VLANs like 1002–1005). These should show up in the device VLAN view as well—either as “system/platform VLANs” or similar—so the effective VLAN set is complete and the UI/API doesn’t hide what’s actually on the box.

Example (Catalyst reserved VLANs):

VLAN Type  SAID       MTU   Parent RingNo BridgeNo Stp  BrdgMode Trans1 Trans2
---- ----- ---------- ----- ------ ------ -------- ---- -------- ------ ------
1002 fddi  101002     1500  -      -      -        -    -        0      0
1003 trcrf 101003     4472  1005   3276   -        -    srb      0      0
1004 fdnet 101004     1500  -      -      -        ieee -        0      0
1005 trbrf 101005     4472  -      -      15       ibm  -        0      0

We should also explicitly handle overlaps between VLAN sources. Since a device’s VLAN view can be composed from multiple inputs (platform defaults + multiple site/site-link sets + device overrides), the same VLAN ID can show up more than once, and we need to detect and mark that rather than silently flattening it.

Concretely, when we build device.vlans.all() / device.vlans.effective() we should:

• detect duplicates by VLAN ID (VID) across all contributing sources
• mark whether the overlap is benign or conflicting
  • benign: same VID and same effective properties (same “definition”)
  • conflicting: same VID but differing properties (e.g., name/MTU/STP/etc.)
• preserve explainability by recording which sources contributed that VID

[patrickpreuss]

For a link (portA ↔ portB), we should be able to compute link-level consistency from the two ports’ assignments:

• trunk↔trunk: compare allowed/assigned VLAN sets (diff + intersection)
• access↔access: access VID must match (kind of)
• access↔trunk: trunk must carry the access VID (and tagging/native expectations must match)
• native VLAN mismatch (VID or tagging behavior)

Expose as link.vlans.consistency() / port.peer().vlans.diff() with a clear diff + source attribution.