-
Notifications
You must be signed in to change notification settings - Fork 165
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support for port-specific VLAN tags #629
Comments
this is under internal discussion. it's not especially easy to implement, but it's fairly high on our wish-list. |
Thanks Nick,
I’ve got the bones of an implementation that simply adds a field to a vlanInterface, alternatively we create a new model to associate a peering VLAN many-to-many with a vlanInterface and put this property there.
Thoughts?
…
On 7 Apr 2020, at 05:47, Nick Hilliard ***@***.***> wrote:
this is under internal discussion. it's not especially easy to implement, but it's fairly high on our wish-list.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
@nickhilliard any further information about internal discussions about this one? |
@nickhilliard any further info about this one? The PR has been submitted but yet to be accepted. Is there any information from your internal discussions I could combine into the PR to get this feature merged? |
not yet unfortunately. We've been working on a framework upgrade (doctrine->eloquent) over the last several months. This has a huge change footprint, so for the moment we're staying away from feature-adds and anything which needs database schema modifications. |
Ah okay, this makes sense. Perhaps we can look at this feature as a way to test the benefits of the new framework? Is there a timeline on a dev cut of the framework migrations? |
Hopefully reasonably soon, but that's a vague answer. @barryo? |
The change is very big and encompasses the entire database layer. I just caught up with @yannrobin there and he's powering through it. In fact most objects are done but the trickier ones are left: auth, users, some of interfaces, patch panels. I think an estmiate of four weeks would be reasonable (but that's not me giving @yannrobin an arbitrary deadline here, just trying to put a reasonable guess on it). |
Thanks all, this is very exciting. Let me know if there is anything you need (testing etc.) closer to release time that we can assist with. |
Thanks @tardoe - we'll likely do this as a beta release. We'll have it live at INEX first so others will know it's in production use but the beta tag will reflect the stong possibility of UI bugs, etc. We'll be looking for people to give it a go then. Thanks! |
@barryo Any update on this one? |
@barryo @nickhilliard any update on this? |
Has there been any movement on this @nickhilliard or @barryo? |
Is your feature request related to a problem? Please describe.
Given the modern fabric solution of presenting multiple services on a single port, we'd like the option to tag a given peering VLAN onto a fabric port with a customer-selected VLAN ID. This type of port-specific VLAN hand-off is common place in modern switching platforms and is easily automated with the correct source-of-truth information.
Describe the solution you'd like
During provisioning, when a user selects "Use 802.1q framing" they are presented with an additional field (portSpecificVlanId) where they can select a VLAN ID to hand the peering VLAN off on.
Note: we currently have this partially working in our own fork, some work is required to align with master and updated all the associated function (e.g. provisioning YAML output etc.)
The text was updated successfully, but these errors were encountered: