-
Notifications
You must be signed in to change notification settings - Fork 64
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
Virtual Chassis device/interfaces are not grouped #33
Comments
I'm seeing something similar with server chassis where you don't normally document the internal mapping of the virtual nics and I end up having all these blades floating around unconnected. How do you guys get around this? I guess children can be "virtually" connected with a dummy edge? |
I've now modeled our Virtual Chassis with an abstracted SwitchPort loop connection between each and it works okay, except where we have more than 4 members in a stack. It would be nice to be able to hide this to show the logical group, but I imagine that's not going to be straight forward. |
Yep. I have floating islands of switches because of this. It also makes a mess because if you have redundant links on 2 switches in a stack, it shows up as two different switches instead of combining it into one. |
+1 for virtual chassis grouping. We use a lot of VSS/SVL and switch stacks and having individual devices displayed is not very useful or usable. |
As there are reasons for grouping as well as against grouping, this should be an individual parameter. |
When modelling connections to a virtual chassis interfaces appear as separate devices on the map.
Not sure how difficult this would be but, perhaps the switch members of a chassis should be connected by by default as they represent 1 logical device.
The text was updated successfully, but these errors were encountered: