Why Deep Packet Inspection Isn't Just for Network Engineers

Network troubleshooting using deep packet inspection is a tried and true approach for network engineers - no one would ever doubt this approach when a difficult problem is plaguing the network. But suggest the use of deep packet inspection for troubleshooting slow applications and you'll likely get some blank stares. Deep packet inspection is the domain of network engineers, not application engineers, right?

Not necessarily. Analyzing decoded packet headers is definitely more suited to a network engineer, but what about the payload data from all the packets? Most network engineers find little value in the payloads, often times they filter them out to conserve analysis resources. But payloads can be of high interest to application engineers investigating application problems, including slow response time.

Consider the example of a help desk application used by a large online retailer. Support professionals, who access the help desk application for each customer call they receive, begin to experience slow response times from the application and of course the initial report is that the network is the problem. A network engineer begins his investigation and after a short time, calls in the application designer stating the problem is the application, not the network. "How do you know that," asks the application engineer? "Simple", says the network engineer. "Your application is generating the following messages. Your server command was deadlocked with another process and has been chosen as a deadlock victim. Re-run your command. And The rollback transaction request has no corresponding BEGIN TRANSACTION". Flabbergasted, the application engineer exclaims, "Where did you get that information?" "From the packet payloads involved in the slow response time transactions on the network, using deep packet inspection network analysis troubleshooting. You should try it sometime."

Deep packet inspection can provide greater value than simple network troubleshooting. Application engineers can certainly benefit, both in troubleshooting application problems and analyzing the overall behavior of an application before trouble is reported. The following four steps should be done to quickly isolate and analyze specific application data:

1.  Capture data at the appropriate location
For application analysis and tuning, it's best to locate a distributed network analysis software probe or appliance in the data center in line with the application and database servers. This will capture the data for all application users, whether local or remote

.

2. Save packet data to disk
By saving packets to disk and employing post-capture analysis, you can take your time in doing your analysis, without worrying about missing key data.

3. Filter stored packet data for the application of interest
Some solutions make this easier than others, but this step is crucial in creating a data set that is manageable and applicable to the application you wish to analyze. This can often be done by filtering out all traffic except traffic that has the source or destination IP of your application server or servers. If it's a troubleshooting exercise and the problem is isolated to a particular client, you can even further refine the filter to just the IP to IP conversation between the client and the server. 

4. Use built-in analysis features to look for common faults

Before diving in and looking for complex, one-off faults, use the built-in fault detection and analysis capabilities of your analysis software (again, these features can vary wildly between competing solutions) to look for common issues, like one-way traffic, database client errors, slow server response time, failed login, resource errors, etc.

Overall, even though you may get some awkward stares for suggesting deep packet inspection  to troubleshoot slow applications, in the end it's worth it because, you'll not only keep the network healthy but employees happy and productive.