Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 1 addition & 0 deletions docs/troubleshooting/.pages
Original file line number Diff line number Diff line change
Expand Up @@ -3,3 +3,4 @@ nav:
- Physical Links: physical_links.md
- Switch Agent: agent.md
- ...
- Support Diagnostics: support_diagnostics.md
47 changes: 47 additions & 0 deletions docs/troubleshooting/support_diagnostics.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,47 @@
# Support Diagnostics

If the steps in the rest of this section don't resolve the issue, collect the
following before reaching out to support. The more of this is included up
front, the faster the issue can be localized.

## What to include

- Your `hhfab`/`hhfabctl` version and a summary of your topology (gateway
present, external peering, VPCs in use).
- A plain description of the symptom and roughly when it started.
- Anything that changed around that time - a config push, upgrade, reboot,
or node/server move - even if you're not sure it's related.
- Which specific switches or nodes are affected, if you've already narrowed
it down.
- Any diagnostics you've already collected yourself. Include the raw output

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

isn't that contradictory? if they provide us with the raw output and not the output, that means we need to re-derive what they have already found. I'd say we still want the raw output, but motivate it differently - e.g. we want to be able to reach our own conclusions / exclude other possible root causes etc. I'd still encourage them to give us any summary (in addition to the raw output) if they did any troubleshooting themselves.

rather than a summary, so we don't have to re-derive what you've already
found.

## Collecting a support bundle

`hhfabctl` is installed on the control node as a `kubectl` plugin, so it's
invoked as `kubectl hhfab`, not as a standalone command:

```console
core@control-1 ~ $ kubectl hhfab support dump -y
```

This produces a single timestamped `.hhs` file containing cluster resources
(Fabricator, Agent, Connection, VPC, and related objects) and pod logs.
Secrets are redacted, but the bundle still reflects your deployment's real
topology and state.

## Switch-level diagnostics

For issues that look like a dataplane or hardware problem rather than a
control-plane one (for example, traffic not forwarding despite correct BGP/EVPN
state), support may also ask for a `show techsupport` capture from specific
switches. This is a per-device SONiC command - if asked, run it only on the
switches identified as relevant rather than the whole fabric, both to keep
the capture a manageable size and because a comparison against a switch that
*is* behaving correctly is often the most useful artifact.

!!! note
Support bundles and switch dumps reflect your real deployment and should
be treated as confidential. Share them only through the channel your
support contact provides, not in a public issue or channel.
Loading