Virtual Chassis enhancement - Add the ability to name a virtual chassis

[jsenecal]

Issue type

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

Environment

• Python version: Python 3.5.2
• NetBox version: Develop branch [07364ab]

Description

Currently virtual chassis are named after their master node. It would be great if there was a way to name them according to their "virtual" identity -

For instance: A two member firewall virtual chassis could have two separate names and a virtual one representing the two units.

• node1.fw1.somesite.net
• node2.fw1.somesite.net

Their virtual name is fw1.somesite.net

See what I did there?

A name CharField would need to be added to the VirtualChassis model
It should be optional but used in the __str__ method when documented.

I can submit a PR for this functionality if approved.

[jeremystretch]

This virtual chassis model is intended to replicate real-world implementations, wherein the master device "is" the virtual chassis. Do you need to support an implementation where the virtual chassis has a name which differs from that of its master device?

[jsenecal]

Yes, in our use case, the two node virtual chassis assumes a third "virtual" identity while both units can still be reachable using specific Ips/hostnames) for instance.

[dirtycajunrice]

To chime in:
We have it both ways actually.
Example A:
2 Brocade Switches in "Fabric" setup. Master device takes the name of the pair
Example B:
2 Cisco Switches in "VSS" Setup. Each device has its own name but the "HSRP" Identity has its own name

[Chipa001]

Another example being EqualLogic SAN's in a group.
Any member can be elected the master.
Each Member has its own IP's and the Group has additional IP's.
Naming - 3 members means 4 names: member[1-3], group1

[Chipa001]

I know it might be a separate issue, but it would also be nice to assign interfaces/IP's directly to the VC object. For us this would mainly apply for my EqualLogic SAN example.

Prior to the implementation of virtual chassis in netbox, and in fact still on our psuedo production environment of netbox, we used the Chassis device bays (child/parent) model to represent our virtual chassis. This was of course at the detriment of being able to represent the physical hardware on racks. This essentially created a "Virtual Chassis" which would hold most of the logical configuration, but still allowed the physical hardware to exist within netbox for inventory purposes.

When Virtual chassis was originally discussed, I really thought that a rework of chassis would be implemented to support virtual chassis'. I was actually quite surprised to see the direction that was taken.

There is talk of Firewalls and Active/Standby which I don't really like the idea of representing these type of relationships as virtual chassis, except when looking at the current implementation of Virtual Chassis. I think current VC implementation is better described as an HA relationship and less like a Virtual Chassis. With that in mind, I believe VC/HA should be allowed within the Virtual world as well.

[deadflanders]

I'd vote for this feature as well. We use Comware gear here, and we often IRF multiple chassis into a single virtual chassis. When we do this, we have a name for each physical device that is used just for inventory purposes, we then have a separate name that is used for the stack as a whole.

[mmahacek]

The use case sounds more like a cluster than a virtual chassis. In our case, we have two sets of stacked switches, each as their own virtual chassis, that are then clustered together for fail over. I would vote for this enhancement to be a separate object. Kind of a combination of virtual chassis and virtual cluster, but for physical clusters.

[snowie-swe]

Virtual cluster naming is also present in Checkpoint firewalls, where u can have for example 8 nodes in a VSX cluster running VSLS (load sharing) - as clusters are normally made of physical devices that can be located in diff datacenters a virtual cluster name is more or less always given.

Each member of the cluster will have its own IP and Name.
The Virtual cluster will have its own IP and name, it dosn´t inherit from any other member.

[paravoid]

This virtual chassis model is intended to replicate real-world implementations, wherein the master device "is" the virtual chassis. Do you need to support an implementation where the virtual chassis has a name which differs from that of its master device?

I'm not sure how familiar you are with Juniper gear; apologies beforehand if you are and this is overly verbose!

Juniper's virtual chassis (= switch stacking) has the concept of "global management", where one assigns an IP to the "virtual management Ethernet" interface, and then SSH to that IP for management. That IP is automatically assigned by whichever switch happens to be the master ("routing-engine" in Juniper's confusing terminology) at that time.

For all intents and purposes, a VC is "one switch", with one configuration, which has one hostname set (as shown at the prompt), and one IP assigned to its vme interface. The individual switches that comprise the stack don't (typically?) have an IP of their own, and no separate configuration of their own either -- the interfaces are all renamed as well (prefixed with the member's ID), making their names globally unique across the stack. You can't know which switch you've connected to (i.e. which switch is the master) until you run e.g. show virtual-chassis.

Other vendors -and even Juniper in some configurations I believe- may treat a switch stack in a similar fashion, where "secondary" devices are treated as "remote linecards" of a primary device.

An real-world simplified example is: we have a switch stack called "asw-esams", with a hostname of "asw-esams.mgmt.esams.wmnet", comprised of two QFX5100 switches, IDs 0 and 3, devices "asw-oe10-esams" and "asw-oe13-esams" in Netbox, in racks OE10 and OE13 respectively. oe10's interfaces are xe-0/N/N and oe13's interfaces are xe-3/N/N. The configuration includes:

set system host-name asw-esams
set interfaces vme unit 0 family inet address 10.21.0.104/24
set routing-options static route 0.0.0.0/0 next-hop 10.21.0.1
...
set interfaces xe-0/0/0 description lvs3001
...
set interfaces xe-3/0/0 description lvs3003
...

It's not clear to me how one would model this in Netbox, and how would make this association. It's certainly useful, both for humans, and for automated tools (e.g. configuration management) to be able to maintain the association between stack members and "stack hostname", as well as to be able to define the management IPv4/IPv6 of the stack as a whole in some field that is shared between the members. (Separate from this issue and probably another can of worms deserving another issue is the fact that one cannot represent these "global interface (naming) view" in Netbox right now either, but would have to parse interface names and offset them by VC ID to get the configured interface name).

Hope I'm making sense!

[DanSheps]

Just to chime in on this to give a use case, but ultimately express my middling support for this.

We physically name each device (-<#><sw#>-<4thoctet>) however the VC is named -<#>-<4thoctet>.

I feel this keeps the documentation in Netbox fairly structured to follow the physical labelling convention in netbox. However, to get around this, currently I use the domain as the Chassis Name.

Something for people to keep in mind, Virtual Chassis is meant, in the current implementation, to replicate actual Virtual Chassis, not virtual clusters (vPC and the like).

To be honest through, I don't know if a separate name is required as the domain is sufficient for, I would imagine, most use cases. I haven't dove too deep into our VSS setup but there is no domain in our VC setup and you can't have one (stackwise doesn't do it, not 100% sure about Virtual Stackwise however).

I would like to see some support for MLAG, which would support the other Virtual implementations (vPC, etc) but I think that would be out of scope of this FR.

[paravoid]

To be honest through, I don't know if a separate name is required as the domain is sufficient for, I would imagine, most use cases. I haven't dove too deep into our VSS setup but there is no domain in our VC setup and you can't have one (stackwise doesn't do it, not 100% sure about Virtual Stackwise however).

"Domain" is not a concept that exists in a Juniper Virtual Chassis. I suspect it's a Cisco-specific feature.

Besides the confusing terminology issue, even if one were to put the name of the switch's name in that field, it still makes things quite awkward. There is no place for one to put the (primary) IP of the stack, nor its interfaces and so on and so forth.

[DanSheps]

"Domain" is not a concept that exists in a Juniper Virtual Chassis. I suspect it's a Cisco-specific feature.

It is not specific to Cisco, as I have not seen it on any of our gear, currently, with the exception of our Nexus switches which run VPC. It may be a VSS terminology but I haven't looked too much into VSS yet.

Besides the confusing terminology issue, even if one were to put the name of the switch's name in that field, it still makes things quite awkward. There is no place for one to put the (primary) IP of the stack, nor its interfaces and so on and so forth.

If you create a VME interface on each switch and mark it as "management", when you combine the switches into a VC you will only see the single interface from the master unit.

The way you model the interfaces is the interface for each physical unit belong to the individual units in netbox. The master unit is typically where you model all the "global" configuration. You can also opt to do what I do and include certain global configurations on each unit.

Netbox is not intended to represent a config (even though you can build one from the information contained in Netbox)