Too many people just run `request support information` and call it a day. That gets you logs, but not the deep state for troubleshooting complex routing or security policy issues.
For a real audit or incident, you need the specific tech-support files. Here's the command that gives you everything, structured for Juniper support or your own analysis:
```bash
request support information
request support information | save /var/tmp/full-support.txt
file copy /var/tmp/full-support.txt /var/www/
```
Then download via HTTP from the device. But that's basic.
For security and state analysis, target these:
```bash
show security policies detail | no-more > /var/tmp/sec-policies-detail.txt
show security flow session summary > /var/tmp/session-summary.txt
show route protocol next-table detail > /var/tmp/routing-state.txt
show log messages | last 5000 > /var/tmp/messages-last.txt
```
Copy and download the same way. The key is `detail` and capturing protocol state. The generic support info lacks depth for forensics.
Always hash your collected files before and after transfer.
- `run file checksum md5 /var/tmp/full-support.txt`
-dk
Trust but verify, then don't trust.
Good point about the detail level in generic support captures. It's true that the standard output often filters out deeper state information that's critical for troubleshooting.
One thing I'd add is to consider the timing when pulling these state files. For routing or session issues, running the commands multiple times with a short delay can reveal flapping or convergence patterns that a single snapshot misses.
And on the hashing note, that's a smart practice for audit trails. Have you found a particular method works better for correlating those checksums with your case management system?
—HR
Finally someone gets it. The default support bundle is padded with filler.
But you're missing the key part: those detail outputs are useless if you don't also grab the `show configuration | display set` at the same moment. The running state and the config that produced it can drift, especially after a rollback or partial commit. Your session summary won't mean much if you don't have the exact policy config that was live.
Also, piping to `no-more`? Just set `set cli screen-length 0` first. Saves the extra flag on every command.
-- old school
This is a great breakdown of the specific commands that actually matter. I've always relied on the generic request support output and then found myself digging through endless log files while missing the real-time state data.
Your point about using `detail` for the security policies makes a lot of sense. In our environment, we've seen policies with multiple terms where the hit count only tells part of the story; the order and specific matches are what we needed during an incident. The generic bundle never seems to have that level of granularity.
A follow-up question on the hashing practice: do you find the MD5 checksum sufficient for internal audit trails, or is there a push to use something like SHA-256 for these support files to match other security documentation standards?
Totally agree on grabbing the config. That config-state drift is a silent killer during post-mortems. I've been burned by that exact scenario after a rollback.
Setting `screen-length 0` is a much cleaner habit, you're right. One caveat: if you're hopping between devices a lot in a shared terminal, it's easy to forget you left it on zero for the next engineer. I usually throw in a `set cli screen-length 50` at the end of my script, just to be polite.