Simple Packet Captures with SLX and CloudShark

April 27, 2018
by Lindsay Hill

Packet Captures are a necessary evil when you need to prove network innocence. But they’re tedious to configure, collect & analyze. What if you could simplify the setup, collection and viewing? That’s what we’ve done here, combining StackStorm, Extreme Insight Architecture, CloudShark, and of course Slack.

Demo: Running Packet Captures from Slack

Check out the video here – we show entering some commands in Slack, which triggers a packet capture on multiple switches. The PCAPs are automatically uploaded to CloudShark, so we can view the packets in our browser:

Read on for more about how to set this up.

Background: What’s Going on Here?

There’s a few key technologies in use here:

1. Extreme Insight Architecture: the Extreme SLX series of switches run a separate ‘Guest VM’ in addition to the default SLX-OS VM. This Guest VM is running Ubuntu 14.04. There is an onboard hardware path that connects the packet processor ASIC(s) to this VM. This lets us mirror data plane traffic directly to this guest VM. We can collect it in that VM, and/or copy the data elsewhere.
2. CloudShark: This is a 3rd-party service that offers “Wireshark in your browser” – upload a PCAP file, and view the packet details in your browser. They have an API for uploading PCAPs. Once a PCAP is uploaded, that file can then be shared with others. This can either run as a hosted SaaS model, or on-premises.
3. Slack: IRC for hipsters, of course.

Plus of course StackStorm, which is the operational ‘glue’, stitching together these elements, co-ordinating inputs, actions and outputs across our environment.

Setup: System Configuration

Here’s the basics for how to set this up:

1. StackStorm & ChatOps: Install & configure StackStorm. Create a Slack team if you don’t already have one, and add a Hubot configuration, and get a HUBOT_TOKEN. Edit the /opt/stackstorm/chatops/st2chatops.env file on your StackStorm server, and add that HUBOT_TOKEN. Set HUBOT_ADAPTER=slack, and restart the st2chatops service. Invite the bot to your Slack channel, and it should start responding to !help.
2. CloudShark: You will need an account with CloudShark. You can use either the SaaS offering, or on-premises. Get a CloudShark API Key.
3. SLX Setup: Enable the Guest VM on your SLX switches. Copy stanley’s public SSH key to authorized_keys on the Guest VM. Add entries to DNS or your hosts file so that you can ssh from your StackStorm server to the switches and their guest VM. Use the format switch_name-tpvm for the guest VM DNS entries.

Setup: Packs, Workflows & Aliases

Install the st2_demos pack with st2 pack install https://github.com/StackStorm/st2_demos. This contains the alias file /opt/stackstorm/packs/st2_demos/aliases/multicap.yaml, and the workflow metadata and definitions, /opt/stackstorm/packs/st2_demos/actions/multicap.yaml and /opt/stackstorm/packs/st2_demos/actions/workflows/multicap.yaml. You can of course edit these files, and move them to other packs.

Install the clicrud and CloudShark packs with st2 pack install clicrud cloudshark.

Configure the CloudShark pack with st2 pack configure cloudshark – you will need to use your API key from above.

Copy /opt/stackstorm/packs/clicrud/clicrud.yaml.example to /opt/stackstorm/configs/clicrud.yaml, and configure as required.

Afterwards, run sudo st2ctl reload --register-all

Try it Out!

You should now be ready to test it out. From Slack, run !help capture.

If this is responding, try running a capture. Something simple like multicapture 'port 179' on switches slx1,slx2.

You can get more complicated, by adding timeout=30 or count=20. If you don’t specify a timeout or count, it will use the default maximums of 300s or 100 packets.

Future Improvements

This workflow can be improved, and made more robust. Potential improvements include:

• Use ACL-based filtering on the SLX
• Clean up old PCAPs – both those on the ST2 server, and in CloudShark
• Modify to work by collecting packets on a server, rather than an SLX
• Pause (or cancel) the workflow if there are other captures in progress. This could be done within the workflow itself, or by using policies.