NetStacksNetStacks

Multi-Send (Broadcast)

Professional

Send commands to multiple terminal sessions simultaneously for bulk configuration changes, status checks, and network-wide troubleshooting.

Overview

Multi-Send allows you to type a command once and broadcast it to multiple terminal sessions simultaneously. This is essential for network engineers who need to execute the same command across dozens of devices -- whether checking BGP status on every router, deploying an NTP change across the campus network, or gathering show output from all switches during an outage.

Two Broadcast Modes

NetStacks provides two ways to send commands to multiple devices:

  • Live Multi-Send -- toggle multi-send mode on your open terminal tabs. Every keystroke you type is broadcast in real time to all enabled sessions. This is ideal for interactive work where you want to see output from each device as it arrives.
  • Broadcast Command Dialog -- select sessions and enter a command in a dialog. The command is executed on all selected sessions with a configurable timeout (10s, 30s, 60s, or 120s). Results are collected and displayed in a unified view with per-device status, output, and execution time. Results can be exported to Markdown or copied to clipboard.

Use Cases

  • Mass status checks -- run show ip bgp summary on every core router to verify peering health
  • Bulk configuration -- push NTP servers, SNMP communities, or ACL updates across all devices in a site
  • Pre/post maintenance verification -- capture baseline output before a change and compare after
  • Incident triage -- check interface errors, CPU, memory, and log entries across the network simultaneously
Warning

Multi-Send is powerful but potentially dangerous. Always verify which sessions are included before executing commands that make configuration changes. Consider using the Broadcast Command Dialog for destructive operations -- it gives you a preview before execution.

How It Works

Live Multi-Send Architecture

The live multi-send system uses a global manager that tracks which terminal sessions are enabled for broadcast. When you type in any enabled terminal, the input is intercepted and broadcast to all other enabled terminals through registered listeners.

  1. Terminal registration -- each terminal session registers a listener with the multi-send manager when multi-send is toggled on
  2. Input interception -- when you type in the source terminal, the input is sent to the source session normally and simultaneously broadcast to all other enabled sessions
  3. Re-entrancy protection -- a broadcast guard prevents infinite loops where a broadcast triggers another broadcast
  4. Independent execution -- each session receives the input independently and executes it in its own context. Output appears in each terminal separately

Broadcast Command Dialog Architecture

The Broadcast Command Dialog uses a different approach -- it sends a single command to the backend bulk-command API, which executes it on all selected sessions in parallel and collects results.

  1. Session selection -- you select which sessions to include from the list of open sessions
  2. Command dispatch -- the command and session IDs are sent to the bulk-command API endpoint
  3. Parallel execution -- the backend executes the command on all selected sessions simultaneously with the configured timeout
  4. Result aggregation -- results are collected with per-session status (success, error, timeout, auth-failed), output text, and execution time

Result Status Types

StatusMeaningAction
SuccessCommand executed and output capturedReview output in results panel
ErrorCommand execution failedCheck error message, verify device connectivity
TimeoutCommand did not complete within the timeoutIncrease timeout or check device responsiveness
Auth FailedSession authentication was rejectedRe-authenticate the session and retry

Step-by-Step Guide

Workflow 1: Live Multi-Send with Open Tabs

  1. Open terminal sessions to the devices you want to manage (e.g., open tabs to core-rtr01, core-rtr02, dist-sw01, dist-sw02, dist-sw03)
  2. Press Cmd+Shift+M (Mac) or Ctrl+Shift+M (Windows/Linux) to toggle multi-send mode
  3. A broadcast icon appears in the status bar showing "Broadcasting to X sessions"
  4. By default, all open connected sessions are included. To select specific tabs, hold Cmd/Ctrl and click the tabs you want to include
  5. Type your command in any enabled tab -- it is sent to all included sessions
  6. Each session executes the command independently and shows its own output
  7. Press Cmd+Shift+M again to disable multi-send
Tip

Use tab groups to organize devices by role (core routers, distribution switches, access switches). Multi-send respects tab groups -- select a group to broadcast to all tabs in that group at once.

Workflow 2: Broadcast Command Dialog

  1. Select the sessions you want to target by holding Cmd/Ctrl and clicking their tabs
  2. Right-click and select Broadcast Command to open the dialog
  3. The dialog shows the selected sessions with their names and hosts
  4. Enter your command in the text area (e.g., show ip bgp summary)
  5. Set the timeout (10s, 30s, 60s, or 120s) based on expected command duration
  6. Click Execute or press Cmd/Ctrl+Enter
  7. Results appear with per-device status icons, output text, and execution time
  8. Click Export Results to save as Markdown, or Copy All to copy output to clipboard

Workflow 3: Reviewing Per-Device Output

  1. After executing a broadcast command, results are listed by session
  2. Each result shows a status icon: checkmark for success, X for error, clock for timeout
  3. Click the chevron next to a result to expand or collapse the output (the first 3 results are auto-expanded)
  4. For failed devices, check the error message to determine the cause
  5. Use Export Results to save a Markdown file with all outputs organized by device, including timestamps and execution times

Code Examples

Network-Wide BGP Health Check

broadcast-bgp-checktext
# Broadcast to: core-rtr01, core-rtr02, core-rtr03, dist-rtr01, dist-rtr02
# Command: show ip bgp summary
# Timeout: 30s

=== core-rtr01 (10.0.0.1) === [Success, 1.2s]
BGP router identifier 10.0.0.1, local AS number 65100
Neighbor        V  AS    MsgRcvd MsgSent TblVer  Up/Down  State/PfxRcd
10.0.0.2        4  65100   48291   48305  12847  5w2d     256
10.0.0.3        4  65100   48190   48302  12847  5w2d     256
10.0.0.5        4  65200   12045   12030  12847  2w3d     128

=== core-rtr02 (10.0.0.2) === [Success, 0.9s]
BGP router identifier 10.0.0.2, local AS number 65100
Neighbor        V  AS    MsgRcvd MsgSent TblVer  Up/Down  State/PfxRcd
10.0.0.1        4  65100   48305   48291  12847  5w2d     256
10.0.0.3        4  65100   48188   48300  12847  5w2d     256
10.0.0.6        4  65300   8820    8805   12847  1w5d     64

=== dist-rtr01 (10.1.0.1) === [Timeout, 30.0s]
(Device did not respond within timeout)

=== dist-rtr02 (10.1.0.2) === [Success, 2.1s]
BGP router identifier 10.1.0.2, local AS number 65100
Neighbor        V  AS    MsgRcvd MsgSent TblVer  Up/Down  State/PfxRcd
10.0.0.1        4  65100   48210   48195  12847  5w2d     256
10.0.0.2        4  65100   48208   48193  12847  5w2d     256

Bulk NTP Configuration

broadcast-ntp-configtext
# Live Multi-Send to all campus switches
# Tabs: access-sw01, access-sw02, access-sw03, access-sw04, access-sw05

configure terminal
no ntp server 172.16.0.1
ntp server 10.0.100.1 prefer
ntp server 10.0.100.2
ntp source Loopback0
end
write memory

Pre-Maintenance Baseline Capture

broadcast-baselinetext
# Broadcast Command Dialog - capture baseline before maintenance
# Sessions: core-rtr01, core-rtr02, dist-sw01 through dist-sw08
# Timeout: 60s

show ip route summary
show ip ospf neighbor
show ip bgp summary
show interfaces status | include connected
show cdp neighbors
show spanning-tree summary
show etherchannel summary

Exported Results Format

broadcast-results-2026-03-10.mdmarkdown
# Broadcast Command Results

**Command:** `show version | include uptime`
**Executed:** 3/10/2026, 2:30:00 PM
**Sessions:** 5 (4 succeeded, 1 failed)
**Total Time:** 3.45s

## Results

### core-rtr01 (10.0.0.1) ✓

**Status:** success
**Execution Time:** 0.82s

```
core-rtr01 uptime is 5 weeks, 2 days, 14 hours, 22 minutes
```

### access-sw03 (10.1.3.1) ✗

**Status:** timeout
**Error:** Command did not complete within 30s

Q&A

Q: How many devices can I broadcast to simultaneously?
A: There is no hard limit on the number of sessions. Live multi-send broadcasts to all enabled tabs in your terminal window. The Broadcast Command Dialog sends to all selected sessions. Practical limits depend on your machine's resources and the number of open SSH connections. Teams commonly broadcast to 20-50 devices at a time without issues.
Q: Can I filter which devices receive commands?
A: Yes. In live multi-send mode, hold Cmd/Ctrl and click specific tabs to include or exclude them. You can also right-click a tab and select Exclude from Multi-Send. Tab groups let you select an entire group at once. In the Broadcast Command Dialog, you pre-select which sessions to include before executing.
Q: Is command execution parallel or sequential?
A: In live multi-send mode, keystrokes are broadcast to all sessions simultaneously -- each session receives and processes input in parallel. In the Broadcast Command Dialog, the backend executes the command on all selected sessions in parallel and collects results as they complete.
Q: How do I handle devices that fail during a broadcast?
A: In live multi-send mode, if a session disconnects it is automatically excluded from broadcast and a notification appears. In the Broadcast Command Dialog, failed devices show an error or timeout status in the results panel. You can review which devices failed, fix the issue, and re-run the command on just those devices.
Q: Can I use multi-send with different device types (e.g., Cisco and Juniper)?
A: Yes, but be aware that command syntax differs between vendors. Live multi-send broadcasts the exact same keystrokes to all sessions, so the command must be valid on all target devices. For mixed-vendor environments, consider grouping devices by vendor into tab groups and broadcasting to one vendor group at a time.
Q: Can I export broadcast results?
A: Yes. The Broadcast Command Dialog provides two export options: Export Results saves a Markdown file with all output organized by device including status, execution time, and timestamps. Copy All copies all output text to the clipboard for pasting into tickets or documentation.

Troubleshooting

Some Devices Not Receiving Commands

  • Verify the device's tab is included in the multi-send group -- look for the broadcast indicator on the tab
  • Check that the session is connected (disconnected sessions are automatically excluded)
  • If using tab groups, confirm the device's tab is in the selected group

Output Not Appearing After Broadcast

  • Switch to each tab individually to check for output -- live multi-send does not aggregate output; each tab shows its own results
  • Some commands may take time to produce output (e.g., show tech-support). Wait for the command to complete on each device.
  • Use the Broadcast Command Dialog instead, which collects and displays all results in one view

Timeout on Slow Devices

  • Increase the timeout in the Broadcast Command Dialog (up to 120 seconds)
  • Some commands like show tech-support or show running-config on large configurations may need longer timeouts
  • Older or resource-constrained devices may respond more slowly -- consider running them in a separate batch

Mixed Vendor Command Issues

  • Commands are vendor-specific: show ip route (Cisco) vs show route (Juniper) vs show ip route (Arista)
  • Group devices by vendor using tab groups and broadcast to one vendor at a time
  • The Broadcast Command Dialog results panel makes it easy to identify which devices returned errors due to invalid commands

Connection Drops During Broadcast

  • In live multi-send mode, disconnected sessions are automatically excluded and a notification appears
  • In the Broadcast Command Dialog, disconnected sessions show an error status in results
  • Reconnect the dropped sessions and re-run the command on just those devices
  • For critical operations, consider using the Controller's scheduled tasks or MOPs for better tracking and rollback workflows