Support and troubleshooting

Troubleshoot from the outside in: define the symptom, confirm its scope, check recent changes, inspect service and resource health, then collect evidence before restarting or reconfiguring the system.

First response

Record these facts before making changes:

• affected appliance, interface, user, workflow, and software version;
• first and most recent occurrence;
• time zone and a narrow example time window;
• expected behavior and actual behavior;
• whether capture continues and whether packets are being dropped;
• recent network, authentication, storage, certificate, or software changes;
• exact error text and the page or API operation that produced it.

If packet recording is still healthy, avoid restarting capture services until the evidence needed for the incident is secure.

Network diagnostics

Run tests from the system that is experiencing the problem. A successful check from an unrelated workstation does not prove that the appliance has the same path, DNS view, or policy.

CAUTION Some networks block or deprioritize ICMP. Treat probe loss as a clue, then confirm with the application flow or a packet capture.

Capture path checks

When traffic is missing or capture drops increase:

1. Confirm the physical capture port, optic, breakout, speed, FEC, and link state.
2. Check whether received packet counters increase at the adapter.
3. Review active filters, slicing, merge-port settings, and the selected destination directory.
4. Compare offered traffic with the appliance capture profile.
5. Check filesystem capacity, write latency, and any simultaneous backup or mirror operation.
6. Record a short known flow and search for it by exact endpoint and time.
7. Save adapter statistics and the test PCAP before altering the configuration.

If the adapter receives packets but no file grows, focus on capture state, directory permissions, capacity, and capture services. If adapter counters remain still, focus on the TAP, packet broker, cabling, optics, and link negotiation.

Resource and storage evidence

Use the administration pages or approved command-line access to gather:

• CPU and system load over the incident window;
• memory use and swap activity;
• filesystem capacity and inode availability;
• block-device inventory and health;
• disk latency, throughput, and queue behavior;
• mounted filesystems and stale remote mounts;
• kernel messages related to storage, drivers, memory, or networking.

Common commands include:

iostat -xz 1 10
vmstat 1 10
df -h
df -i
lsblk
mount
dmesg --ctime

Run only commands approved for the deployment. Avoid unbounded logs or high-frequency collection on an already overloaded system.

Service health

The service-health view shows monitored components and their current state. Refresh once to rule out stale status, then inspect the service log before restarting anything.

For NFS, CIFS, iSCSI, NIS, and platform daemons, distinguish among:

• a stopped local service;
• an unreachable remote dependency;
• failed authentication or permission;
• DNS or routing failure;
• a stale mount;
• capacity or timeout pressure.

Restart a service only when you understand which workflows it affects and have captured the pre-restart evidence. Afterward, verify both service state and the user-visible operation that originally failed.

Block devices and filesystems

Confirm that expected drives appear with the correct size and mount point. A missing device may indicate hardware, controller, or operating-system detection trouble. A present device with a full or read-only filesystem points to a different failure domain.

When refreshing block-device information, compare the result with the recorded storage design. Do not initialize, format, repair, or remount a device from a generic troubleshooting procedure; those actions require a system-specific recovery plan.

API and authentication failures

For an API problem, capture the method, URL path, query parameters, response code, response body, and request time. Redact credentials before sharing logs.

Repeat a failed request with the smallest safe input. Do not include live secrets in screenshots, shell history, or support attachments.

Collect a support bundle

Use the platform support-log function when available. Include only the time range necessary to reproduce the issue. A complete case normally contains:

1. appliance model, serial number, and software version;
2. concise symptom and business impact;
3. timestamps with time zone;
4. recent changes and attempted recovery steps;
5. support bundle and relevant service logs;
6. CPU, memory, filesystem, block-device, mount, and network evidence;
7. API request and sanitized response when applicable;
8. focused PCAP or search result when packet behavior is involved;
9. screenshots that include the full error and surrounding state.

Before uploading, review the bundle for credentials, tokens, customer data, and packet payload that the recipient is not authorized to receive.

Escalation summary template

System and version:
Impact:
Expected behavior:
Observed behavior:
First occurrence and time zone:
Most recent example:
Recent changes:
Capture state and drop count:
Tests completed:
Temporary workaround:
Attached evidence:

For configuration procedures, see Control administration. For packet evidence, see Capture and search.