Virtual chassis (switch stacks)¶

A virtual chassis models a switch stack - several physical switches acting as one logical chassis (Cisco StackWise, Juniper Virtual Chassis, Aruba VSF, and friends). Each member stays an ordinary device with its own serial, rack position, and interfaces; the stack just ties them together and records each member's position and master-election priority.

Create a stack¶

1. Open DCIM → Virtual chassis in the sidebar and click Add.
2. Fill in the form:

1. Save.

Members with monitored IPs or services wear their live check state next to the status pill - in the Members table and on each unit's row in the stack drawing. Unmonitored members show nothing extra. Usually only the master has an address; the stack's Monitoring tab shows the checks of the member it is measured on.

Add members¶

Membership lives on the device, and there are two doors in:

• From the stack page - the Members table's Add member button opens a device search; pick the switch, give it a position (pre-filled with the next free slot) and a priority. A device already in another stack moves over.
• From the device - open a member's edit form and fill in the Stack membership section:

Once a device is in, you can also edit its position/priority, promote it to master, or remove it right from the stack's Members table.

Position-aware interface names¶

Stacked switches name their ports by member number - member 2 of a Catalyst stack owns GigabitEthernet2/0/24, not 1/0/24. Danbyte handles this with a {position} token in component template names:

GigabitEthernet{position}/0/[1-24]

• {position} resolves to the device's stack position when its components are stamped - member 1 gets GigabitEthernet1/0/1, member 2 gets GigabitEthernet2/0/1. A standalone device resolves it to 1; vendors that count from zero (Juniper's ge-0/0/0) write {position:0} to set the standalone default. The token can sit anywhere in the name, so any vendor style works: ge-{position}/0/[0-47], {position}/1/[1-24], ….
• [1-24] is range shorthand in the template dialog - it creates one template per port in a single go, with a live preview of what you'll get.

Names follow the device around. When a device joins a stack, moves to a different position, or leaves, Danbyte re-renders its {position} templates and renames the matching interfaces - swap two members and both sets of ports stay truthful. Renames never clobber: if a target name is already taken by another interface, that port is skipped and everything else still renames. The API reports the count (vc_renamed_interfaces) and the UI toasts it - "added to stack - 28 interfaces renamed to match".

The stack page¶

Open a stack to see its tabs:

• Overview - the stack's facts plus a Members table sorted by position: position, device, priority, role (a Master / Member badge), serial, and status. Tick members and press Remove N from stack to release several at once; each is a device edit, checked and logged as one.
• Interfaces - every member's ports combined into one view (the tab badge shows the total), each row prefixed with the member's position and name.
• Monitoring - the SLAs the stack is in, with Add to SLA, then the member and address the stack is measured on and that member's checks.
• SNMP, Journal and Change log.
• The Overview draws the stack itself - one chassis bar per member in position order (gaps show as dashed empty slots), with the master crowned and each member's serial, priority, and status on the bar.

On a member device's page, the Interfaces tab gains a Whole stack / This member toggle: the combined stack table (with the member column, this device's rows tinted) or just the device's own ports. The stack master defaults to the whole-stack view - open the master and you see every port in the stack.

A member's own device page shows a Stack badge in the header (Stack: name · pos N · master) linking back to the stack.

Port utilization sits under the stack elevation: the same card the device page shows - connected / reserved / free per port kind, undocumented cables counted as connected - summed across every member, by the same counting rule: physical interfaces and front ports, virtual interfaces only when they are counted, rear ports never. The card refreshes after a cable, port or reservation change anywhere.

SNMP¶

A stack is polled once, through its master (or lowest member), and the observation is split per member so drift and sync stay member-accurate. The stack page's SNMP tab polls and syncs the whole stack; details in SNMP discovery → Polling a stack. An interface can be moved between members from its edit form.

SLAs¶

A stack is one member of a service level agreement, measured on its master's primary address - or, when the master has none, on the first member's by position that has one. Add the chassis itself (the Virtual chassis kind, or Add to SLA on its Monitoring tab), or add its devices: devices of one stack that include one without an address count once as the stack. The other members are never scored as down for having no address. A member device's own SLA panel shows the stack's figure.

Deleting a stack¶

Deleting a virtual chassis releases its members - their positions and priorities are cleared and they carry on as standalone devices, each release recorded in that device's change log. The devices themselves are never deleted with the stack.

To delete several stacks, tick them in Virtual chassis and press Delete in the bar. The confirmation says how many member devices are released, and each stack releases its members the same way (POST /api/virtual-chassis/bulk-delete/). More than 1000 stacks go 1000 at a time (see Large selections).

Editing several stacks¶

Tick stacks in Virtual chassis and press Edit in the bar to set the domain and description and to add or remove tags on all of them. Only the fields you change are applied. Name and master are per stack and stay on each stack's own edit form. The bulk edit is POST /api/virtual-chassis/bulk-update/ with {"ids": [...], "fields": {"domain", "description", "add_tag_ids", "remove_tag_ids"}} and needs the change permission.

Tags & custom fields¶

Need to track something extra - a stack firmware train, a maintenance window? Add a custom field for virtual chassis and it appears on every form. See Tags & custom fields.