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.

[jcralbino]

I would like to see this implemented in a way that we can decouple the concept of the layer 2 end-to-end domain from the vlan object

Currently this is just one use case of several examples where a layer 2 broadcast domain is not tied to the vlan deployed in a switch and associated with the interface of the device

For example:

• in a vxlan environment the l2 broadcast domain is extended across several devices without requiring the use of the same vlan id
• ultimately in any l2vpn overlay this is also existing

In this case we want to associate the same layer 2 broadcast domain to two vlan ids existing in different vlan groups

This is the struggle I have faced when trying to model a modern SDN environment in the netbox current structure

[jcralbino]

This is one discussion i started to improve the l2 forwarding plane that I believe is relevant to my comment above

#9418

[jcralbino]

Similar issue here about the changes needed for better modelling of layer 2 forwarding planes

#9373

[DanSheps]

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.

Just want to point out, NX-OS does it per-interface as well. I am not sure where you got the information that it is per-device but it is not. You do need the VLAN to be VXLAN enabled, however it is do-able on a per-interface basis.

#9373 is not relevant to this issue so it would be best to ignore it (You can bring it up in your discussion, it is just not relevant here)

[tyler-8]

Just wanted to revisit some ideas on how to model this simply and broadly.

If I'm understanding correctly; Aruba, Cisco, and Juniper vendors all do VLAN translation at the interface level - translation isn't global across all interfaces on the device participating in the "local" VLAN; so perhaps the way forward is to make this an interface-object data structure.

We have tagged_vlans and untagged_vlan - how do we simply model when any given VLAN is translated across the interface? A JSONField that maps "local" VLAN Object IDs to "remote" VLAN Object IDs, perhaps?

For example:

If VLAN 5 (id 1) is used locally on the switch, but I want to translate it to VLAN 10 (id 2) across a trunk interface, the data structure could look like this:

Snippet of interface API output

{
    "tx_power": null,
    "untagged_vlan": null,
    "tagged_vlans": [
        {
          "id": 1,
          "url": "https://demo.netbox.dev/api/ipam/vlans/1/",
          "display": "Data (5)",
          "vid": 5,
          "name": "Data"
        }
      ],
    "tagged_vlan_translation": [{"local": 1, "remote": 2}],
    "untagged_vlan_translation": [],
    "mark_connected": false
}

Alternatively, a new model would have to be created, rough example:

class InterfaceVlanTranslation(models.Model):
    interface = ForeignKey(Interface)
    local_vlan = ForeignKey(VLAN)  # vlan being translated
    remote_vlan = ForeignKey(VLAN)  # vlan that we're translating to

[ITJamie]

personally, i think the idea of a separate model InterfaceVlanTranslation is the better approach and would help a lot when it comes to documenting svlans in future. it could also help for virtual circuits / circuit tracing.

though maybe have an option of using id's only instead of having to have two vlan objects...

class InterfaceVlanTranslation(models.Model):
    interface = ForeignKey(Interface)
    local_vlan = ForeignKey(VLAN)  # vlan being translated
    local_vlan_vid = int()
    remote_vlan = ForeignKey(VLAN)  # vlan that we're translating to
    remote_vlan_vid = int()

the reason why I would argue for this is in an isp its normal to handoff a customers vlan on vlan10 for example. it would be great to have an ability to just document it as vlan 10 handoff without having to create 1000's of unique vlan 10's vlan objects.

in a lot of cases we would want to use vlan foreignkeys for both, but in some just a documented integer would be preferred for at least one of the sides of the translation