Troubleshooting: Protocol Captures on Cisco VCS

This is just a quick write up on how to pull network traces from the Cisco Video Communications Server (VCS). As anyone who has been in the business of integrating solutions in existing networks knows, having the ability to pull protocol traces goes a long way to streamlining the troubleshooting process. Deploying a VCS is no different.

Background

So, why would one need to pull traces from the VCS? Well, one reason could be self-education. That's right: education. When I was first tinkering with the VCS, I set all of my SIP and H.323 configurations to use channels that weren't encrypted and I pulled traces to see what was happening under the hood. It is a good learning tool.


OK, maybe trolling through protocol traces on a Saturday evening isn't your bag. Another good use for protocol traces is to narrow down the fault domain. Maybe you want to check DNS resolution, clustering, AD/LDAP integration, or device registrations. I recently deployed a VCS in a customer network and things weren't working initially. My colleague who was riding in the firewall saddle said he wasn't seeing traffic. While he was jumping around network devices, looking at port counters, I pulled down a protocol trace from the VCS. In no time at all I was able to determine the packets were being sent where they needed to go. 


Another good use case is to do a traffic study. I like to pull traces into Wire Shark and break down conversations. It helps to make sure you have accounted for all of the network flows you were expecting as part of the design. 


So, in summary you can use protocol traces to: learn, troubleshoot, and validate your deployment.

Launching The Trace

You have to SSH to the console of the VCS to access the facility you can use to gather protocol traces. The VCS runs a Linux distribution that includes the ubiquitous "tcpdump" facility (well, maybe ubiquitous is overstating things a tad). To access tcpdump, you will want to log on as root.


I like to create a folder for traces: mkdir /tmp/traces/

I put the traces in this temp directory so that I know where they are. It makes clean up easy when I am done playing around. No sense in leaving a mess behind me.

To start the trace I typically use a command like the following:


tcpdump -s 1500 -w /tmp/traces/h323regcheck.cap

If you have a VCS with the Dual Network Interface (DNI) option, you may find using the -D and -i command switches handy. 


A good resource for the various command line options is the Tcpdump Manpage.

Collecting the Files

You have a couple of options for getting the trace files off of the VCS and loaded on your workstation. You can off load the files using SFTP or SCP from the VCS. This means you'll need an off box location that hosts a SFTP or SCP daemon. You can also SCP from the VCS. This is my preferred method. For example:


silversurfer:~$ scp root@10.10.10.10:/tmp/traces/h323regcheck.cap . 

Considerations


As previously noted, make sure you put the traces in a directory that you can easily access and clean up. I like to do clean up after I finish running our validation routine. I archive debugs, logs, traces, etc. and clean up anything that doesn't need to be left behind.


When you are attempting to capture device registrations and call flows from the VCS you need to keep in mind that you may won't be able to fully dissect the packets if you have encryption enabled. The old tricks of loading a certificate into Wire Shark and decrypting the packets won't necessarily work. For H.323, if you enable encryption the initial call setup isn't encrypted. SIP, on the other hand, does encrypt the setup messages. Both use Diffie-Hellman so there is no way to load the keys into Wire Shark.