starred/netbox
1
0
Fork 0
mirror of https://github.com/netbox-community/netbox.git synced 2026-01-11 21:10:29 +01:00
Code Issues 273 Packages Projects Releases 10 Wiki Activity

Ability to assign management IP to a virtual chassis #5587

New Issue
Closed
opened 2025-12-29 19:29:48 +01:00 by adam · 11 comments
adam commented 2025-12-29 19:29:48 +01:00
Owner
Copy Link

Originally created by @jasonyates on GitHub (Oct 29, 2021).

NetBox version

3.0.8

Feature type

Data model extension

Proposed functionality

We have a large number of Cisco Catalyst switches in our environment that are typically "stacked". A stacked switch has 1 management plane but multiple physical devices. We currently model these with a virtual chassis and X many members. E.g.

Virtual Chassis: office-switch1
Member: office-switch1-1
Member: office-switch1-2
Member: office-switch1-3

The "problem" we face is that because these switches have 1 management plane they have 1 IP address for management which is typically configured as a loopback. We currently assign the management IP to the primary member which means the other members sit in the inventory with no IP displayed.

It would be useful to allow the virtual chassis to be assigned a management IP and then have child members inherit that IP.

Use case

Expanding the functionality of a virtual chassis to allow more real world modelling of Cisco "stack" switches.

Database changes

No response

External dependencies

No response

Originally created by @jasonyates on GitHub (Oct 29, 2021). ### NetBox version 3.0.8 ### Feature type Data model extension ### Proposed functionality We have a large number of Cisco Catalyst switches in our environment that are typically "stacked". A stacked switch has 1 management plane but multiple physical devices. We currently model these with a virtual chassis and X many members. E.g. Virtual Chassis: office-switch1 Member: office-switch1-1 Member: office-switch1-2 Member: office-switch1-3 The "problem" we face is that because these switches have 1 management plane they have 1 IP address for management which is typically configured as a loopback. We currently assign the management IP to the primary member which means the other members sit in the inventory with no IP displayed. It would be useful to allow the virtual chassis to be assigned a management IP and then have child members inherit that IP. ### Use case Expanding the functionality of a virtual chassis to allow more real world modelling of Cisco "stack" switches. ### Database changes _No response_ ### External dependencies _No response_
adam added the type: featurepending closure labels 2025-12-29 19:29:48 +01:00
adam closed this issue 2025-12-29 19:29:48 +01:00
adam commented 2025-12-29 19:29:48 +01:00
Author
Owner
Copy Link

@bluikko commented on GitHub (Oct 31, 2021):

To take this further: not only management IP address could be assigned to a virtual chassis but also virtual (loopback, VLAN/"SVI") interfaces & IP addresses in general?

@bluikko commented on GitHub (Oct 31, 2021): To take this further: not only management IP address could be assigned to a virtual chassis but also virtual (loopback, VLAN/"SVI") interfaces & IP addresses in general?
adam commented 2025-12-29 19:29:49 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Nov 1, 2021):

The "problem" we face is that because these switches have 1 management plane they have 1 IP address for management which is typically configured as a loopback. We currently assign the management IP to the primary member which means the other members sit in the inventory with no IP displayed.

This is the purpose of designating a master device for the virtual chassis: The master device becomes representative of the virtual chassis, which is the best approximation we can achieve, as that is how a virtual chassis functions in the real world. the "chassis" itself has no resources.

@jeremystretch commented on GitHub (Nov 1, 2021): > The "problem" we face is that because these switches have 1 management plane they have 1 IP address for management which is typically configured as a loopback. We currently assign the management IP to the primary member which means the other members sit in the inventory with no IP displayed. This is the purpose of designating a master device for the virtual chassis: The master device becomes representative of the virtual chassis, which is the best approximation we can achieve, as that is how a virtual chassis functions in the real world. the "chassis" itself has no resources.
adam commented 2025-12-29 19:29:49 +01:00
Author
Owner
Copy Link

@jasonyates commented on GitHub (Nov 1, 2021):

Screenshot 2021-11-01 at 12 15 56

@jeremystretch As an example, here's one of my stack switches. Management IP is assigned to a loopback "owned" by the master switch.

In the inventory the other child members show no IP, despite them being managed by the same management IP as the master, however we don't manage the switch by its inventory name, we manage it via the virtual chassis name. If I look at the virtual chassis, it doesn't show anything other than the assigned members.

Could the child members inherit the management IP from the master to display in the inventory along with the virtual chassis?

@jasonyates commented on GitHub (Nov 1, 2021): <img width="2262" alt="Screenshot 2021-11-01 at 12 15 56" src="https://user-images.githubusercontent.com/242483/139670319-dff93967-211a-492a-bf25-db17c1c63a9b.png"> @jeremystretch As an example, here's one of my stack switches. Management IP is assigned to a loopback "owned" by the master switch. In the inventory the other child members show no IP, despite them being managed by the same management IP as the master, however we don't manage the switch by its inventory name, we manage it via the virtual chassis name. If I look at the virtual chassis, it doesn't show anything other than the assigned members. Could the child members inherit the management IP from the master to display in the inventory along with the virtual chassis?
adam commented 2025-12-29 19:29:50 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Nov 1, 2021):

In the inventory the other child members show no IP, despite them being managed by the same management IP as the master

The other VC members show no IP address because they're managed by the master. This is by design. Consider your proposal further: Suppose a user searches NetBox for a non-master VC member named switch03 and sees a management IP address assigned to it. But when they SSH to that IP expecting switch03, they find switch01 (the VC master). That would be rather confusing.

In a virtual chassis, there typically is no direct way of accessing a non-VC member, as all management plane functionality is handled by the master. (Otherwise it would defeat the purpose of configuring a VC in the first place.) All management is done via the master, which is why only the master shows a management IP address.

@jeremystretch commented on GitHub (Nov 1, 2021): > In the inventory the other child members show no IP, despite them being managed by the same management IP as the master The other VC members show no IP address **because** they're managed by the master. This is by design. Consider your proposal further: Suppose a user searches NetBox for a non-master VC member named switch03 and sees a management IP address assigned to it. But when they SSH to that IP expecting switch03, they find switch01 (the VC master). That would be rather confusing. In a virtual chassis, there typically is no direct way of accessing a non-VC member, as all management plane functionality is handled by the master. (Otherwise it would defeat the purpose of configuring a VC in the first place.) All management is done via the master, which is why only the master shows a management IP address.
adam commented 2025-12-29 19:29:50 +01:00
Author
Owner
Copy Link

@jasonyates commented on GitHub (Nov 1, 2021):

The other VC members show no IP address because they're managed by the master. This is by design. Consider your proposal further: Suppose a user searches NetBox for a non-master VC member named switch03 and sees a management IP address assigned to it. But when they SSH to that IP expecting switch03, they find switch01 (the VC master). That would be rather confusing.

I agree the above situation could be confusing. However right now if I were to search for switch03 as I'm looking to SSH to it, I have to dig in to the virtual chassis section to find the master and look at that device to get the management IP. One could argue that is equally as confusing.

Would it not make usage easier if under the management section (and in the device list), assuming you don't have a management IP configured for that member, it shows the IP address of the master, perhaps highlighted in some way to indicate it's "inherited" as part of the virtual chassis?

Additionally along the same lines, when you view the virtual chassis object I would have to locate the master in order to obtain the management IP.

@jasonyates commented on GitHub (Nov 1, 2021): > The other VC members show no IP address because they're managed by the master. This is by design. Consider your proposal further: Suppose a user searches NetBox for a non-master VC member named switch03 and sees a management IP address assigned to it. But when they SSH to that IP expecting switch03, they find switch01 (the VC master). That would be rather confusing. I agree the above situation could be confusing. However right now if I were to search for switch03 as I'm looking to SSH to it, I have to dig in to the virtual chassis section to find the master and look at that device to get the management IP. One could argue that is equally as confusing. Would it not make usage easier if under the management section (and in the device list), assuming you don't have a management IP configured for that member, it shows the IP address of the master, perhaps highlighted in some way to indicate it's "inherited" as part of the virtual chassis? Additionally along the same lines, when you view the virtual chassis object I would have to locate the master in order to obtain the management IP.
adam commented 2025-12-29 19:29:50 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Nov 1, 2021):

However right now if I were to search for switch03 as I'm looking to SSH to it, I have to dig in to the virtual chassis section to find the master and look at that device to get the management IP. One could argue that is equally as confusing.

I disagree. Your screenshot above clearly shows the VC assignment for the member device.

As I said, VC members have no management capability, and thus display no management IP address. IMO the clear indication of VC membership is sufficient, and most closely models the real world.

@jeremystretch commented on GitHub (Nov 1, 2021): > However right now if I were to search for switch03 as I'm looking to SSH to it, I have to dig in to the virtual chassis section to find the master and look at that device to get the management IP. One could argue that is equally as confusing. I disagree. Your screenshot above clearly shows the VC assignment for the member device. As I said, VC members have no management capability, and thus display no management IP address. IMO the clear indication of VC membership is sufficient, and most closely models the real world.
adam commented 2025-12-29 19:29:50 +01:00
Author
Owner
Copy Link

@DanSheps commented on GitHub (Nov 1, 2021):

@jasonyates

The Management and Control plane for 3850's is only on the "master". The Standby is in a sync state but does not control the members unless there is a failover event. The console port is likewise redirected through the stackwise ring to the master once the chassis comes up.

This is why the Virtual Chassis model is done the way it is (with the master having the IP/management interface and the members not having anything).

You should only be assigning the management resources to the VC master. You won't ever connect to VC members to perform any sort of management functions (unless they take over as master, which should only be a temporary event)

@DanSheps commented on GitHub (Nov 1, 2021): @jasonyates The Management and Control plane for 3850's is only on the "master". The Standby is in a sync state but does not control the members unless there is a failover event. The console port is likewise redirected through the stackwise ring to the master once the chassis comes up. This is why the Virtual Chassis model is done the way it is (with the master having the IP/management interface and the members not having anything). You should only be assigning the management resources to the VC master. You won't ever connect to VC members to perform any sort of management functions (unless they take over as master, which should only be a temporary event)
adam commented 2025-12-29 19:29:51 +01:00
Author
Owner
Copy Link

@jasonyates commented on GitHub (Nov 1, 2021):

@DanSheps I agree. I fully appreciate the master owns the management resources.

My point (perhaps poorly described by the use of the word "assign") is mainly that from a usability perspective having the VC model and/or the members at least SHOW the management IP assigned to the master would be useful to save additional clicks to get to the master to locate the management IP.

@jasonyates commented on GitHub (Nov 1, 2021): @DanSheps I agree. I fully appreciate the master owns the management resources. My point (perhaps poorly described by the use of the word "assign") is mainly that from a usability perspective having the VC model and/or the members at least SHOW the management IP assigned to the master would be useful to save additional clicks to get to the master to locate the management IP.
adam commented 2025-12-29 19:29:51 +01:00
Author
Owner
Copy Link

@mgoetze5 commented on GitHub (Nov 25, 2021):

This is the purpose of designating a master device for the virtual chassis: The master device becomes representative of the virtual chassis, which is the best approximation we can achieve, as that is how a virtual chassis functions in the real world.

Well, that is how a virtual chassis functions in the real world of stackable switches, perhaps. In the real world of clustered storage arrays, any node in the cluster could be the master, it's usually not configurable nor predictable (for instance it might change everytime you do a firmware upgrade). My solution has been to add a virtual 0 RMU master device to my virtual chassis where I can add virtual interfaces, but the better model for my case would be the ability to add interfaces directly to the virtual chassis model.

@mgoetze5 commented on GitHub (Nov 25, 2021): > This is the purpose of designating a master device for the virtual chassis: The master device becomes representative of the virtual chassis, which is the best approximation we can achieve, as that is how a virtual chassis functions in the real world. Well, that is how a virtual chassis functions in the real world of stackable switches, perhaps. In the real world of clustered storage arrays, any node in the cluster could be the master, it's usually not configurable nor predictable (for instance it might change everytime you do a firmware upgrade). My solution has been to add a virtual 0 RMU master device to my virtual chassis where I can add virtual interfaces, but the better model for my case would be the ability to add interfaces directly to the virtual chassis model.
adam commented 2025-12-29 19:29:51 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Jan 25, 2022):

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.

@github-actions[bot] commented on GitHub (Jan 25, 2022): 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](https://github.com/netbox-community/netbox/blob/develop/CONTRIBUTING.md).
adam commented 2025-12-29 19:29:51 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Feb 24, 2022):

This issue has been automatically closed due to lack of activity. In an effort to reduce noise, please do not comment any further. Note that the core maintainers may elect to reopen this issue at a later date if deemed necessary.

@github-actions[bot] commented on GitHub (Feb 24, 2022): This issue has been automatically closed due to lack of activity. In an effort to reduce noise, please do not comment any further. Note that the core maintainers may elect to reopen this issue at a later date if deemed necessary.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
beta
breaking change
complexity: high
complexity: low
complexity: medium
needs milestone
netbox
pending closure
plugin candidate
pull-request
Mirrored from GitHub Pull Request
 severity: high
severity: low
severity: medium
status: accepted
status: backlog
status: blocked
status: duplicate
status: needs owner
status: needs triage
status: revisions needed
status: under review
topic: GraphQL
topic: Internationalization
topic: OpenAPI
topic: UI/UX
topic: cabling
topic: event rules
topic: htmx navigation
topic: industrialization
topic: migrations
topic: plugins
topic: scripts
topic: templating
topic: testing
type: bug
type: deprecation
type: documentation
type: feature
type: housekeeping
type: translation
No Label pending closure type: feature
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
adam
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/netbox#5587
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?