Skip to content

Commit 3b2bbfc

Browse files
committed
docs(troubleshooting): add support diagnostics page
Signed-off-by: Pau Capdevila <pau@githedgehog.com>
1 parent fb56907 commit 3b2bbfc

2 files changed

Lines changed: 48 additions & 0 deletions

File tree

docs/troubleshooting/.pages

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -3,3 +3,4 @@ nav:
33
- Physical Links: physical_links.md
44
- Switch Agent: agent.md
55
- ...
6+
- Support Diagnostics: support_diagnostics.md
Lines changed: 47 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,47 @@
1+
# Support Diagnostics
2+
3+
If the steps in the rest of this section don't resolve the issue, collect the
4+
following before reaching out to support. The more of this is included up
5+
front, the faster the issue can be localized.
6+
7+
## What to include
8+
9+
- Your `hhfab`/`hhfabctl` version and a summary of your topology (gateway
10+
present, external peering, VPCs in use).
11+
- A plain description of the symptom and roughly when it started.
12+
- Anything that changed around that time - a config push, upgrade, reboot,
13+
or node/server move - even if you're not sure it's related.
14+
- Which specific switches or nodes are affected, if you've already narrowed
15+
it down.
16+
- Any diagnostics you've already collected yourself. Include the raw output
17+
rather than a summary - it saves us a round trip re-deriving what you've
18+
already found.
19+
20+
## Collecting a support bundle
21+
22+
`hhfabctl` is installed on the control node as a `kubectl` plugin, so it's
23+
invoked as `kubectl hhfab`, not as a standalone command:
24+
25+
```console
26+
core@control-1 ~ $ kubectl hhfab support dump -y
27+
```
28+
29+
This produces a single timestamped `.hhs` file containing cluster resources
30+
(Fabricator, Agent, Connection, VPC, and related objects) and pod logs.
31+
Secrets are redacted, but the bundle still reflects your deployment's real
32+
topology and state.
33+
34+
## Switch-level diagnostics
35+
36+
For issues that look like a dataplane or hardware problem rather than a
37+
control-plane one (for example, traffic not forwarding despite correct BGP/EVPN
38+
state), support may also ask for a `show techsupport` capture from specific
39+
switches. This is a per-device SONiC command - if asked, run it only on the
40+
switches identified as relevant rather than the whole fabric, both to keep
41+
the capture a manageable size and because a comparison against a switch that
42+
*is* behaving correctly is often the most useful artifact.
43+
44+
!!! note
45+
Support bundles and switch dumps reflect your real deployment and should
46+
be treated as confidential. Share them only through the channel your
47+
support contact provides, not in a public issue or channel.

0 commit comments

Comments
 (0)