VLAN Translation

[jaakub]

NetBox version

2.11.12

Feature type

Data model extension

Proposed functionality

Extend the VLAN object to allow documentation of 1:1 VLAN translation (similar to already existing NAT IP functionality within the IP address object). The simplest explanation being VLAN 100 being translated into VLAN 200 and the other way round.

This would require two additional fields within the VLAN object called (TBD):

• translation_vlan_group
• translation_vlan_id

Those fields would be used to create a link between two VLAN objects to allow VLANs within the same or different VLAN groups to be linked together (in cases where two different pools are used for internal and external VLANs). Those two new fields would need to be accessible via:

• the API (would return nested VLAN object)
• UI (when creating or editing objects)
• CSV import functionality

This would require validation that the referenced object exists (especially via CSV and the API). Lastly, it would be great if we could expand the query filters to easily return all translated VLANs using is_translated. Similar to has_primary_ip.

Within the UI, when editing/creating an object, you'd see an additional section called VLAN Translation, with two fields mentioned earlier. Once again, this is to be discussed and it may not warrant its own specific section and could be added under the already existing VLAN section.

The UI would also need an additional row within the VLAN view to represent the mapping (None if empty). One option is to just show the associated VLAN within that row, and the second option is to also show the VLAN group of the associated VLAN.

Option 1:

Internal VLAN View:

External VLAN View:

Option 2 (showing VLAN group of mapped VLAN):

Internal VLAN View:

External VLAN View:

Lastly, the VLAN view (/ipam/vlans) would need an additional column called Translation (TBD), which would show either a green (when the VLAN link is present) or red tick (when the VLAN link isn't present) to easily identify those translated VLANs.

Use case

In our scenario shown above, we have two VLAN groups, one for external VLANs, one for internal VLANs. At the moment, we are unable to create external to internal VLAN mapping (1:1) and we need to document those mappings within a spreadsheet. By adding this functionality, we could edit the VLAN object and select another VLAN to create that mapping.

Database changes

Unsure.

External dependencies

N/A

[jeremystretch]

Please spend some time detailing the proposed implementation and update your post above. Per the FR template:

Describe in detail the new feature or behavior you are proposing. Include any specific changes to work flows, data models, and/or the user interface. The more detail you provide here, the greater chance your proposal has of being discussed. Feature requests which don't include an actionable implementation plan will be rejected.

[jaakub]

Please spend some time detailing the proposed implementation and update your post above. Per the FR template:

Describe in detail the new feature or behavior you are proposing. Include any specific changes to work flows, data models, and/or the user interface. The more detail you provide here, the greater chance your proposal has of being discussed. Feature requests which don't include an actionable implementation plan will be rejected.

I've now added more detail in the FR.

[jeremystretch]

I'm not clear on the real-world function being modeled here. How are VLANs being "translated?" From the examples above it looks like you're just correlating VLANs in two different domains.

[jaakub]

The real-world function would be a single layer 2 service stretching two independent domains, which use a different VLAN tag for that service. In this case, you can rewrite/translate those tags on a border device connecting those two independent domains together. It is known as VLAN translation, although you could also say it is a VLAN rewrite function. Two references - Cisco and Juniper.

In the below example, we have:

• VLAN 10 being translated into VLAN 20 and vice versa.
• VLAN 30 being translated into VLAN 40 and vice versa.

What I'm trying to model in Netbox is exactly the correlation of two VLAN objects belonging to different VLAN groups providing that end to end service. We could achieve a similar result by using custom fields, however, a custom field wouldn't provide that dynamic link/reference to the other involved VLAN object and would not be as easy to track.

Allowing that link in Netbox would allow easier documentation and tracking of VLAN rewrite/mappings. At the moment, we maintain a separate spreadsheet to document that function and we would love to use Netbox as a single source of truth.

[tyler-8]

I like the idea. FWIW - The Aruba CX platform also supports VLAN translation.

Would it not be simpler to just have a single field (like maybe vlan_translation) that points to a single other VLAN object? I don't know that a translation_group would be necessary, but I definitely see the value of properly linking two VLANs together for translation modeling.

[julianze]

i like the idea too.
We are using VLAN-Mapping/Translation on our Cisco Catalyst:
https://content.cisco.com/chapter.sjs?uri=/searchable/chapter/content/en/us/td/docs/switches/lan/catalyst9500/software/release/16-9/configuration_guide/lyr2/b_169_lyr2_9500_cg/configuring_vlan_mapping.html.xml&platform=Cisco%20Catalyst%209500%20Series%20Switches

the use case is to "bridge" two vlan together to one l2 broadcast domain.

In example there is a data center switch infrastructure with a separate vlan scope. Then we often bridge a customer vlan from our access network through our backbone to the data center switches.
We don´t have control over the customer vlan id´s and so there could be duplicates over all customer networks.
there´s the point where we have to translate the customer vlan (C-Tag) to our serivce provider vlan (S-Tag) which is then available in the data center for housing or virtualization purposes.

1-to-1 mapping like a fieald with the translated id should be fit most scenarios.

Would it be useful to show interfaces from the translated vlan in the "device-interface"-tab as well?

[jaakub]

I like the idea. FWIW - The Aruba CX platform also supports VLAN translation.

Would it not be simpler to just have a single field (like maybe vlan_translation) that points to a single other VLAN object? I don't know that a translation_group would be necessary, but I definitely see the value of properly linking two VLANs together for translation modeling.

A single field showing the link between two VLAN objects would be most sufficient, and that's what I'm trying to achieve. I thought displaying a VLAN group of the linked VLAN object might be handy/nice, but it's not necessary - hence the two options. Glad to see others see value in this FR.

[jaakub]

Would it be useful to show interfaces from the translated vlan in the "device-interface"-tab as well?

Not sure I follow this idea...

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. Please see our contributing guide.

[jaakub]

It was highlighted (in the Netbox Slack channel), that some vendors and platforms, such as Juniper JUNOS, implement VLAN re-write/translation function on a per-interface basis meaning you can translate 1 VLAN into multiple VLANs, whilst others, such as Cisco NXOS implement it on a per-VLAN basis.

The original idea above was to implement it under the VLAN object, meaning it would be a 1:1 mapping.

One idea to support per-interface VLAN translation (messy, as @DanSheps said, which I agree with), would be to implement a table at the bottom of the interface UI, which would have two columns (old and new VLAN), and one empty row by default. Users could expand that table by additional columns.

From data structure point of view, we would need something like dcim/interfaces/{id}/vlan_rewrite to return a list, with rows being presented as either list or tuple, or a dictionary.

Example case:

• VLAN 10 being rewritten to VLAN 20
• VLAN 100 being rewritten to VLAN 200

tuple = [(10, 20), (100, 200)]
list = [[10, 20], [100, 200]]
dict = [{"ovid": 10, "nvid": 20}, {"ovid": 100, "nvid": 200}]

I would be interested in hearing ideas from others on how this could be implemented both from a UI and API point of view.