Allow more Q-in-Q SVLAN options

[sleepinggenius2]

NetBox version

v4.2-beta1

Feature type

Data model extension

Triage priority

N/A

Proposed functionality

1. When trying to document a triple-tagged VLAN, creating the outermost SVLAN and setting the Q-in-Q role to "Service" works fine, but on the second VLAN in the stack, setting the Q-in-Q role to "Service" and setting the Q-in-Q SVLAN to the outermost SVLAN generates the validation error "Only Q-in-Q customer VLANs maybe assigned to a service VLAN." It seems an arbitrary restriction to disallow documenting nested SVLAN tags. I propose to have this restriction removed, as it could always be implemented with a custom validator, if appropriate in someone's environment.
2. The Q-in-Q SVLAN selection should be a many-to-many relationship, not a many-to-one relationship, as a given VLAN may have different tags pushed onto it in different parts of the network, and the current model does not allow for that to be properly documented.

Use case

When transporting an OVC through our network, we sometimes run into contention with the customer's selected SVLAN that they wish to use on their ENNI, as it may not be available along the full path of the service. In that case, we may need to add one or more additional SVLANs for some or all of its path, ending up with triple-tagging. Even with a CVLAN, we find that different VLANs are available on different rings and we might need to push an SVLAN for a particular ring, and maybe a different one for a different ring. As the tag is only present within that given ring, it needs to be recorded as a separate VLAN object for documentation and provisioning purposes. Therefore, a given CVLAN or SVLAN may require one or more Q-in-Q SVLANs to properly document its path in the network. We are implementing this using a "Multiple objects" custom field to allow for basic documentation today, but would like to move over to the native implementation once it is available, for the additional features it would offer; the current implementation would not allow for that.

Database changes

Rename the qinq_svlan field on the Vlan model to qinq_svlans and change the type from ForeignKey to ManyToManyField.

External dependencies

None