Skip to content
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

Breaking virtual chassis does not break cross-member LAG #2170

Closed
candlerb opened this issue Jun 14, 2018 · 3 comments
Closed

Breaking virtual chassis does not break cross-member LAG #2170

candlerb opened this issue Jun 14, 2018 · 3 comments
Labels
status: accepted This issue has been accepted for implementation type: bug A confirmed report of unexpected behavior in the application

Comments

@candlerb
Copy link
Contributor

Issue type

[ ] Feature request
[X] Bug report
[ ] Documentation

Environment

  • Python version: 3.5.2
  • NetBox version: 2.3.3

Description

Here's a way to get into a strange situation where a physical interface on one switch is associated with a LAG on a different switch.

  • Create two switches (testvc1, testvc2) with interfaces g1-g24
  • Rename the interfaces to g1/1-g1/24, g2/1-g2/24 respectively
  • Select them, and create virtual chassis, with testvc1 as master
  • On the master, create a link aggregation interface LAG1
  • Assign g1/1 and g2/1 as members of LAG1
  • Destroy the virtual chassis

Now switch testvc2 interface g2/1 is still associated with LAG1 on testvc1

@jeremystretch jeremystretch added type: bug A confirmed report of unexpected behavior in the application status: under review Further discussion is needed to determine this issue's scope and/or implementation labels Jun 29, 2018
@jeremystretch
Copy link
Member

What's the best way to handle this? Prevent the member from being removed from the VC? Or just automatically remove the interface from the LAG? I'd go with the former.

@candlerb
Copy link
Contributor Author

I don't have a strong view, as long as the invariant is maintained one way or the other.

@jeremystretch jeremystretch added status: accepted This issue has been accepted for implementation and removed status: under review Further discussion is needed to determine this issue's scope and/or implementation labels Oct 23, 2019
@jeremystretch
Copy link
Member

Fixed in 462cede

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Nov 15, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
status: accepted This issue has been accepted for implementation type: bug A confirmed report of unexpected behavior in the application
Projects
None yet
Development

No branches or pull requests

2 participants