Allow creation of a stack of devices

[mdomore]

the stack having only a single name and multiple devices under is it possible to add this option ?

the problem is in the hardware section multiple models and serial number, the location can be in different rack for each node of the stack

[jeremystretch]

Can you give a real-world example of a stack of devices for context? Do you mean like a stack of switches functioning with a single control plane?

[mdomore]

Yes exaclty, for exemple i have this sh version :

UNIT 1: SL 1: FCX-48GS 48-port Management Module
     Serial  #: BCX2247F00R
     License: FCX_FULL_ROUTER_SOFT_PACKAGE   (LID: dezHHJMhFFt)
     P-ENGINE  0: type DB90, rev 01
     P-ENGINE  1: type DB90, rev 01

UNIT 1: SL 2: FCX-2XGC 2-port 16G Module (2-CX4)

UNIT 1: SL 3: FCX-2XG 2-port 10G Module (2-XFP)

UNIT 2: SL 1: FCX-24GS 24-port Management Module
     Serial  #: BCV2249F0R0
     License: FCX_FULL_ROUTER_SOFT_PACKAGE   (LID: dezHHJMhFFt)
     P-ENGINE  0: type DB90, rev 01

UNIT 2: SL 2: FCX-2XGC 2-port 16G Module (2-CX4)

UNIT 2: SL 3: FCX-2XG 2-port 10G Module (2-XFP)

UNIT 3: SL 1: FCX-24GS 24-port Management Module
     Serial  #: BCV2249F0MZ
     License: FCX_FULL_ROUTER_SOFT_PACKAGE   (LID: dezHHJMhFFt)
     P-ENGINE  0: type DB90, rev 01

UNIT 3: SL 2: FCX-2XGC 2-port 16G Module (2-CX4)

UNIT 3: SL 3: FCX-2XG 2-port 10G Module (2-XFP)

UNIT 4: SL 1: FCX-48GS 48-port Management Module
     Serial  #: BCX2247F029
         License: FCX_FULL_ROUTER_SOFT_PACKAGE   (LID: dezHHJMhFFt)
     P-ENGINE  0: type DB90, rev 01
     P-ENGINE  1: type DB90, rev 01

UNIT 4: SL 2: FCX-2XGC 2-port 16G Module (2-CX4)

UNIT 4: SL 3: FCX-2XG 2-port 10G Module (2-XFP)

this is just one virtual switch with one name but each unit as it's own serial number and hardware and it's own place in the racks.

in fact in the future i will buy arista switch and the mlag is different but for those who use stack like fcx and cisco 3750 it cold be a great feature.

[jeremystretch]

This could be really tricky to implement because a stack of devices isn't necessarily consecutive within a rack, and may not even be in the same rack.

I'd suggest just assigning any IPs, secrets, etc. to the master device and annotating the rest of the members by appending the hostname for now. For example, switch10, switch10:2, and switch10:3.

[mdomore]

Yes that's what i will do but it cold be cool to have a check box for stack unit that allow users to choose hardware and location for each unit of the stack

[dberube1]

Here's the way that I'm doing this currently with a Juniper Virtual Chassis stack.

Define each switch individually. In the interface list for each switch add the necessary VC ports (eg. vcp-0, vcp-1, vcp-255/2/0, etc.). On the additional switches I change the interface numbering to match the stack setup. For example

• FPC 0 - int range ge-0/0/0 thru ge-0/0/47
• FPC 1 - int range ge-1/0/0 thru ge-1/0/47
• Link the virtual chassis ports to the appropriate switch. that way it also shows the devices are connected to each other.

[peelman]

@dberube1's solution is probably the "correct" one, in that it documents the connectivity and establishes the relationship. That being said, a way to denote a Stack, Redundant Pairing, etc. might be useful. Could also be used to group servers together (say for VMware HA clusters), routers/firewalls together (pfSense, Juniper, Cisco, etc. high availability pairs).

Not sure what that would look like from design standpoint...

[ryanmerolle]

I agree with @peelman. Regardless we should continue to talk about stacks, virtual chassis, FEXs, and clusters.

[ashleytayles]

How about this for implementing stacks/ha clusters?

1) Under the "devices" tab we great a new "device group".

2) In the device group creation/edit screen you can search devices and select the members.

3) on the device group page, you can assign primary IP etc, and we can collate all interfaces across members into one screen.

4) if you click on a group member in the rack it could either go to the specific device and it has a field with a link to the group, or it could go straight to the group with an option in the group to go to individual devices.

I believe this was you keep the "genericness" and it can be applied cross-rack.

Im trying to do this myself but I'm a very slow coder with little free time :P

[DanSheps]

Couple of random thoughts beyond the device group's idea:

Use existing parent/child, but have a "Shared Control Plane" toggle which more or less merges the devices, a "dynamic height" on parent and children toggle (merges children + parent heights together).

This would only work for stacked switches (physically stacked), and for things like FEXs you might have to do something like add "line cards" as a option.

[engageant]

I just bumped into this myself while porting data from Racktables. There may be some deeper (programmatic) reasons why this can't be done, but one potential solution is to remove the "child devices must be 0U" constraint.

[jeremystretch]

I've spent several hours working on virtual chassis and I've come to the conclusion that implementing it will take far more time and effort than it's currently worth. There are just too many caveats regarding treatment of the control plane and member interfaces. I'm going to close out this feature request, but maybe we'll be able to take another look at it down the road, after we've addressed some more popular features.

[Armadill0]

It's a pity that you canceled this feature.

Our blade center chassis (Dell PowerEdge M1000e) carry two switch modules (Dell PowerConnect M6348) which form one logical switch stack with all ports of the two modules. Currently we can only form one of those two relationships between the affected devices.

[jeremystretch]

Reopening this. Will give it another shot in the near future.

[lampwins]

From my experience with playing with the model for this, I think interfaces need to be definable at both the control plane level and the member device level. I my thinking, I want to define staking interfaces at the member device level (at least some of the time). In the case of Juniper VCP ports, the port conversion is done at the local device context, so it would be nice to have that defined there, source of truth wise.

Then the regular dataplane interfaces should be defined at the control plane (however that gets modeled), so that things like LAGs can span what would normally be multiple devices.

[lampwins]

I was thinking about the model for this a little bit lately. In order to not deviate too much from the current patterns for devices, here is what I propose:

At it's core, a stack is an aggregation of several physical devices into one logical unit. To that end, we care about nodes, and roles. That is to say a stack member has a node position and a role within the stack, i.e. node: 3, role: backup routing engine.

The model calls for a logical "Stack device" to which actual physical devices are assigned to. This "stack device" is a non rackable logical device. The stack device contains the interfaces, ip addresses, etc. It also defines the maximum number of nodes and the available roles (routing engine, backup routing engine, line card, etc).

At this point, individual devices are assigned to the stack (somewhat similar to how device bays work today). In the UI, you are asked if this is a stack member and if so, you pick the stack and then the node number and role.

There is already some logic in the interface names to try to identify fpc/pic/port in netbox. I think this can be extended here to allow a stack member's interfaces to actually show up when viewing that individual stack member device. I think this becomes important when thinking about things like topology maps. Yes the interface belongs to a logical stack, but it is physically located on node x.

In summary, we allow the aggregation of configuration for things like interfaces, ip addresses. etc, while allowing physical devices to remain separate, so they can exist wherever need be, i.e. separate racks, sites, etc.

@jeremystretch do you have any thoughts on this so far? Just want to get your take to see if this is headed in a direction you think is feasible?

[MichaelRat]

I'm fairly new to using NetBox but have the same problem. I was wondering about a similar approach to @lampwins but along the lines of an extension to the existing device model to allow the creation of "virtual devices".

A virtual device type could be created just like a physical device type. It would look exactly like a physical device type with interfaces but occupies no space (0U). A virtual device instance again looks like a physical device but need not be associated with a rack but just a site ... since it occupies zero space.

Now, let's build a Juniper EX2200 Virtual Chassis, say, as follows: a) create a virtual device type called, say EX2200VC, which has 4 device bays (max no. VC elements). b) create a device instance based on EX2200VC, say Switch00-VC; this device instance can now act as a container for the physical virtual chassis elements c) create the physical EX2200 instances d) fill the Switch00-VC virtual device bays with the EX2200 physical instances

Since the virtual device instance is not constrained to a single rack, it should be possible to fill it with physical devices from any/all racks in the same site.

The one remaining "problem" is the fixed classification of device types as either parent or child or undefined since currently only instances of device types defined as "child" are available for associating with device bays. This could be fixed perhaps in two ways: 1) physical instances of device types with neither "child" not "parent" associated with it may be used as either parent or child 2) device types may have the dual state parent/child associated with it

The second solution is perhaps quite useful in a more general way, since, for example, it would allow a parent switch chassis to be associated with a child switch module which in turn may be associated as parent to a child sfp+ module. Also makes sense with Juniper routers with chassis, FPC blade and PIC module.

This model may also be used for a "virtual aggregation" of any physical devices, e.g. SRX chassis clusters where, for example, the "cluster attributes", such as Reth interfaces, may be associated with the virtual device instance and so represents the "real world"quite accurately.

To go even further, a virtual device instance as such also makes sense if anyone wishes to model a virtual firewall or other device within, say, a VMWARE infrastructure.

Ah, and as a final note, should virtual device instance need to contain physical elements in different sites, why not create a virtual site to represent the resources shared by the real sites. I already used this trick to be able to represent vlans stretched between two sites only of the many more sites I am modeling ...

So, does this seem feasible?

[jotasantos]

@MichaelRat your approach looks very good to me with only one caveat: child devices need to be created with 0U. This doesn't allow us to allocate line cards line the juniper EX (1 or more U) to the rack space. A line card can be physically a card in a chassis or a physically different devices located somewhere else. Apologies if I'm missing something, but why do we have this constrain? Could it be lifted somehow?

[bartdebruijn]

The way I see it, is that the fundamental problem with stacked networking devices is that they are made up of hardware that is functionally the same box, but consists of multiple independent boxes that you want to keep track of. So if you want a logical representation in your CMDB, that's no problem, but that collides with real world inventory keeping.

To make things worse, some vendors/platforms do implement separate management IP's per stack member, others don't. Even then, it would be hard to define LAG's across different independent devices. There has to be a way to define a stacked device.

I think that the easiest would be to have a container object that serves as a placeholder for a stack. Within the container, you would specifiy the members, ports, serial numbers, etc, etc. However, I have no idea how that would work under water and if you could change it w/o changing the current model.

The parent/child logic is in Netbox already, maybe it can be used for this as well?

[shepherdjay]

Ran into this one when trying to define a VSS Pair. On the one hand I want my racking diagrams and any cabling to match the physical world for relaying to smart hands or field techs. ie. tell theme the vss-pair:1 or vss-pair:2 port 24

However logically if I login to the device it's called vss-pair and the interface would be te2/0/24... I can appreciate the complexity of the problem but haven't settled on how I would solve it.

[mvangoor]

Hi guys,

I have been looking at this aswell.

The parent/child relation is one of the best approaches here, however child devices cannot have U's assigned or be added to a rack. This breaks the 'real world' representation.

A logical device that can have multiple devices registered and take over the physical ports defined on that device would be my best guess to a solution. Then the LaG could be created on the logical device, etc.

Thoughts?

[zsandrus]

We are in the early stages of moving from poorly maintained Visio rack elevation diagrams and IP spreadsheets to NetBox. How to handle switch stacks and fabric extenders has been one of the biggest issues we have run in to. The ability to add ports to a LAG across fabric extenders and stacked switches is something I'm willing to invest some time into implementing. Ideally this would also work for any clustered devices that sync configuration and share IPs like our firewalls and load balancers.

I agree that the parent/child relationships would work well here, but instead of changing the existing device bay model, I propose introducing a "cluster" model. There would be a parent 0U "cluster" device where LAGs and virtual interfaces can be created and, cluster/floating IPs can be assigned. Parent or None devices could be added as cluster members and assigned a optional node number. The node number could correspond to a slot in a modular chassis, VSS pair, or a switch number, or FEX number. It could also be helpful to store information like priority as well, but I'm not sure yet if that would be better as a custom field or part of the model. The view for the "cluster" object could include the virtual interfaces, as well as the physical interfaces of the children (a fix for what was requested in #970). If done right, this could also close #824.

By creating a separate "cluster" model, there would be additional tables added and additions to the DCIM API, but there wouldn't be any breaking changes on the existing model.

Additionally, for fabric extenders, there is also the ability to dual home to two Nexus switches, but I'm not sure if allowing a child to have multiple parents is a good idea. The configuration of the fabric extenders must always be the same on both Nexus switches, so the real issue there is creating a one-to-many relationship that might not be used very often. Using a "cluster" device for the VPC pair could work in this case, but there would be an overlap with interface names.

[arionl]

I'm struggling with modeling Cisco chassis switches in NetBox (4510's and Nexus 9k's). In the case of a 4510, it has 10 "slots" -- with slots 5 and 6 reserved for supervisor cards (that have serial ports and some uplinks) and the rest being for normal interface line cards. While each of the SUPs and line cards have separate part numbers and can be defined as devices and appropriate interfaces can be added, what I really care about is a consolidated view of the switch.. and I'd prefer to keep all interfaces documented as they are shown when doing a show interfaces summary. For now, I'm retaining the parent/child relationships (and the concept that the chassis has 'slots') but not including any interfaces in the templates -- those get added upon instantiation. Would be ideal if interfaces could be automagically named for a line card based on the slot the card is marked as being installed in, but as everyone has pointed out this gets very complex very quickly.. and besides, after I set up one of these chassis switches, it pretty much stays in a static config for its lifespan. The Nexus 9ks are similar considering the FEX modules -- they are like line cards, but external and not in the actual chassis. Just figured I'd document my 2c and experiences here in this issue..

[jeremystretch]

I've been working on this off and on for the past few weeks, and I think I've got a reasonable approach to representing virtual chassis membership worked out. My original intention was to automatically rename member interfaces, such that e.g. xe-0/0/1 on the member device in position 5 would be presented as xe-5/0/1 when viewed in the context of a virtual chassis. However, implementing this logic this is proving to be problematic, primarily because there's no sane way to provide the necessary context to the API interface serializer.

For example, suppose the device with a PK of 123 is a virtual chassis master, and NetBox receives a request for /api/dcim/interfaces/?device_id=123. To generate a response with renamed interfaces, we'd need to:

1. Manually retrieve the device with a PK of 123 (since we can't access this from the filter directly)
2. Check if this device is a VC master. If so, retrieve all peer memberships
3. Retrieve the device's DeviceType to determine how interfaces should be renumbered
4. Compile a dictionary linking each device in the virtual chassis to its position
5. Execute a custom get_name serializer method to modify the name of each interface using the provided context

This approach is further complicated by the ability to query the interfaces endpoint for multiple devices. In addition to being highly inefficient, such a complex mechanism is almost certain to present numerous problems in future development.

As an alternative solution, I propose keeping the virtual chassis membership model as it exists now (in branch 99-virtual-chassis), but forgoing the automatic renaming of interfaces. As an example, when creating member 5 in a virtual chassis, you would simply name the switch's interfaces using the VC position ID, e.g. xe-5/0/0-48. While not ideal, this approach avoids a lot of performance and validation concerns. It also completely sidesteps the issue of how to define renaming rules for different platforms. The tedium of renaming interfaces would be aided with a new mechanism to rename interfaces in bulk.

Thoughts?

[arionl]

Is the UI complete for Virtual Chassis support in v2.3-beta2? I upgraded my dev box to the beta (went from v2.2.8 -> v2.3-beta3) and I don't see any way to create or mark a device as a virtual chassis in the web interface. I can explicitly navigate to /dcim/virtual-chassis/ and see a "Virtual Chassis" list view with a message saying "No virtual chassiss found" but that's about it.. Any help would be appreciated.

[jeremystretch]

@arionl To create a virtual chassis, select one or more devices from the device list and click the "create virtual chassis" button at the bottom of the page.

[arionl]

@jeremystretch Ahh. Thanks, I missed that at the bottom of the device list view -- I thought something was going to show up in the Devices menu. Makes sense now. I was able to successfully create a virtual chassis. However, whenever I try to add another device to it, I'm getting an error:

AttributeError at /dcim/virtual-chassis/1/add-member/
'NoneType' object has no attribute 'virtual_chassis'
Request Method: POST
Request URL:    http://netbox/dcim/virtual-chassis/1/add-member/?site=1&rack=1&return_url=/dcim/devices/9/
Django Version: 1.11.10
Exception Type: AttributeError
Exception Value:    
'NoneType' object has no attribute 'virtual_chassis'
Exception Location: /opt/netbox/netbox/dcim/views.py in post, line 2208
Python Executable:  /usr/local/bin/python
Python Version: 3.6.4
Python Path:    
['/opt/netbox/netbox',
 '/opt/netbox/netbox',
 '/usr/local/bin',
 '/usr/local/lib/python36.zip',
 '/usr/local/lib/python3.6',
 '/usr/local/lib/python3.6/lib-dynload',
 '/usr/local/lib/python3.6/site-packages']
Server time:    Wed, 21 Feb 2018 21:32:18 +0000

Should I open up a separate issue for this? Thanks!