Showing results for 
Search instead for 
Did you mean: 
Create Post

Deep Packet Inspection - Traffic Optimisation and Troubleshooting

Level 10

In my last post, I talked about some of limitations of DPI and the kind of tools used to combat it. However, DPI is useful in a couple of other scenarios and in this final post, I’ll cover them also.

Traffic Optimisation

As traffic flows across a network, it needs to be managed as it crosses points of contention. The most common point of (serious) contention are WAN links, but even inter-switch links can be put under pressure. Simple source/destination/port policies are often used to match protocols against prioritisation queues. However, for much the same reasons port matching is not good enough for security (lack of specificity), it’s not really good enough for traffic optimisation.

In an enterprise network, consider a branch office that accesses applications in a server farm at a remote data centre. Creating a class for HTTP alone isn’t much use it’s used by many distinct applications. Creating a class based upon destination subnet alone isn’t going to be much cop either. In a virtualized or VDI environments server IPs are going to change often. IP/Port classes are helpful when you need to pull protocols (such as Citrix or Oracle) to the top of pile, but that isn’t good enough in the context of highly contended or long-haul WAN links.

DPI is used by packet shaping and WAN optimization devices to identify traffic flows to the molecular level; individual user and/or Citrix/Virtual Desktop application. This is necessary for two reasons:

  1. So that the administrator may apply granular policies to individual applications
  2. To identify traffic that may be optimized; either as simple priority access to bandwidth, or something more invasive such as Layer 4-7 protocol optimization. 

In the context of protocol optimisation (read, WAN optimization or acceleration) correctly identifying traffic flows is critical. As an example, many years ago Citrix moved the default port for sessions from TCP 1494 to TCP 2598. Many bandwidth management policies identified Citrix by the TCP port alone. When the port moved, unless the network or Citrix administrator was paying particular attention, latency-sensitive traffic was thrown in with the “best effort” class. Unsurprisingly, this usually resulted in an overwhelmingly negative user experience.


Deep packet inspection is incredibly useful when it comes to troubleshooting network behaviour. DPI can be used to identify applications on the network (such as the Citrix example above) but also for identify the behaviour of applications, and is the final tool to identify a “something bad” happening on the network.
Just to recap, here is a summary of the “something bad” that DPI technologies can address:

  1. Firewall PAD: Filtering out a deliberately malformed packet that would crash a web server
  2. Firewall Signature: Identifying an otherwise correctly formatted packet that produces bad behavior on a web server that otherwise would lead to an exploit (such as dropping a root kit onto a vulnerable host)
  3. Firewall SSL Inspection: Looking into an encrypted session for either of the previous two attacks.
  4. Traffic Optimisation: Identifying and the limiting applications that wish to use excessive amounts of bandwidth
  5. Identifying applications that are behaving badly despite being from a security perspective “clean” and correctly optimized.

Making this a bit more real world; consider the following scenario. External users complain that a web application you host is performing very badly. Firewall PAD and signatures shows that the traffic between the client and the web server is clean; and there are no other apparent attacks.  Traffic optimization ensures this critical application has priority access to bandwidth between the Web server and it’s Database server. However, performance still sucks. DPI tools can be used to analyze the flows between the client, web, and database server. With access to the entire application flow, poorly optimized SQL queries may be identified. This cascade effect can only be identified by tools that understand the application flows not from a security or bandwidth perspective, but in it’s native context. In my view, these kinds of tools are the least well-implemented and understood, and their widespread and proper use could massively improve the time-to-resolution on faults, and identify many things that were previously not in use.

Deep Packet Inspection techniques are used in many places on the network to address a variety of challenges; I’ve focused on security but there are many other applications of DPI technology. And hopefully I’ve made clear that the  correct identification of network traffic is critical to the proper operation of networks and application management in general.

This is my last post in Geek Speak, I'd like to thank everyone who's read and commented. I've really enjoyed writing these articles for this community, and the feedback has steered the conversation in a really interesting direction.  I've no doubt that I'll continue lurking here for some time to come!


Glen Kemp (@ssl_boy)

Level 10

Hi Glenkemp,

Thanks so much for this great article. Honestly, this community is full of such great resources that we the engineers needed for day to day acyivities.

Thanks a bunch.

Level 11

Thanks for the article on DPI.  I couldn't agree with you more especially on how valuable DPI is in troubleshooting a network.

Level 11

Excellent! The article I've been waiting for. glenkemp this series has been excellent, thank you for sharing!

Level 14

Great article.  Thank you for your articles.  They are very informative and have been interesting to read.  I have enjoyed the conversations.

Level 13

Thanks for the great series. It's been one of the best in a while.

Level 11

Great set of articles and hopefully your wrong about it being your last.


Level 11

glenkemp, thanks for your informative series. I have really enjoyed reading it.

In the scenario in the Troubleshooting section of this article, I find often the solution chosen for these kind of issues is to throw more bandwidth at the problem instead of doing some deeper analyzing.


Very good article glenkemp !  I haven't delved much into DPI but I will try and make the time to do so in the future.

I would like to see more from you in the future as well.

Level 12

great article glenkemp cant wait to read more about it.

Level 12

Great post, article, writeup....Thank you glenkemp. keep the articles coming. I am so grateful .

Level 12

Great article in similar stride to its predecessors.

Please continue to post these invaluable bits. I hope to see more in the future

DPI has alerted me to anomalous activity on my network and it is something that I will continue to keep my eyes on.

Level 8

Awesome read!

I didn't realize how many resources were available for DPI until just the past few days. I would love to see some sort of way to do this on a network device link (i.e. a trunk between key locations) without an external node polling a mirror.

Level 17

Who would have thought that my hap hazard SQL queries were mucking up the network. I should have never asked for real world applications.. now I have to buy or at least print a SQL book

** Excellent scenario application, just a peek into the broad use of DPI. I like this idea of being able to easily identify traffic. Making it easy for others as well is nice. I like packet captures but given to someone who isn't familiar with them makes it easy for them to skip over something intrusive, or even be curious about a stream they see and a copy and paste into notepad rebuilds the malware to infect the network further. The real time application and alerting abilities make this a far more advanced tool than simple stream or packet watching and interpretation. Besides, who has a Rain Man they can sit in front of the screen to analyze that real time.

glenkemp with stuff like this I am sure they will ask you back for more. And if not, I'll get my camcorder and we can start a Utube channel.

Level 14

It is too bad this is your last one

Level 10

glenkemp, thanks for the articles, they've been very good reads and provided good information.

Level 9

Thanks for your posts. ALL have been very informative to me.

Level 9

Articles like this are why I love thwack. It is a collective of information that seems nearly endless. This series of articles was fantastic.

Level 12

This whole series has been excellent.  Thanks for your contribution, glenkemp!

Level 10

No worries, been a pleasure!

Level 10

Thanks, I have too!

Level 10

Thanks, but I have to say I have been thoroughly impressed with contributions from the entire community. Nice place you've got here!

Level 10

Thanks, I hope so too!

Level 10

Thanks, I'll see what I can do!

Level 10

Umm..There are ways of doing this, but certainly it's not easy..Maybe a topic for another post, if not here then somewhere else..

Level 10

Ha; as you maybe can tell, this was a real-world scenario that I've seen.  It was only by looking deep into to the packet flow did we understand what was going on..

Level 10


Level 10

I've said before, I've been really impressed by the quantity and quality of the contributions here..

Level 10

Thank you for reading!

Level 15

Thanks for your contributions. 

About the Author
Glen Kemp is a professional services consultant for Fortinet Inc. in the U.K. His words are his own and do not necessarily reflect those of the company he works for. He designs and deploys network and application security tools, including access control, remote access, firewalls and other "keep the bad guys out" technologies. His blogs can be found at and at the Packet Pushers Podcast. Follow him on Twitter @ssl_boy.