• 

A packet is the elemental source of data on a network. Packets are self-contained, including not only the information that is to be communicated, but also the routing instructions, addresses, protocols, etc. that allow the information to be correctly delivered, and possibly acknowledged. Packet delivery on a network is a lot like a letter in snail mail, with the contents of the envelope being the information to be transmitted, the envelope containing address and routing information, and the stamp describing the protocol to be used in delivery – first class, signature required at delivery, acknowledgement of receipt, etc. Also, just as with snail mail, issues can occur in transit that either damage the letter, or as many of us have experienced, prevent the letter from being delivered at all.

Extending this analogy, the contents of a letter, or in the case of packets the payload, are really of no concern to the Postal Service, and typically remain hidden inside the envelope. All the Postal Service needs to know is the address and the mode of delivery. They then determine the routing, without concern for the contents, until delivered to the final recipient. Only then do the contents (payload) become important.

So, what happens when something goes wrong? How would you even know it went wrong? Well, in the case of network analysis, this is where protocol and packet analysis become important. Often used interchangeably in the industry, protocol and packet analysis are in fact quite different. Protocol analysis relates strictly to the routing and delivery of packets. In terms of our Postal Service analogy, protocol analysis is performed using only the envelope – the contents of the envelope are never analyzed. Packet analysis goes one step further, performing both protocol and packet payload analysis.

Network engineers are typically concerned with only the delivery of data on the network, and not the data itself, so why worry about packet analysis at all? Isn’t protocol analysis sufficient? Well, in many cases yes, so it’s the best place to start. But even our simple Postal Service analogy can once again help us in understanding why packet (payload) analysis is important. Let’s say you’re communicating with a family member using letters (yes, the world used to communicate in this highly archaic manner just a few short decades ago), and suddenly your weekly communication is disrupted. Why didn’t you get the response you were expecting? Well, with protocol analysis we can see that (a) no communications have been processed that were addressed to you and (b) your “pen pal” recently received additional communications addressed to them. Even though you can see from the return address on the envelopes that one of the correspondences was from the Publishers Clearing House, you assume that’s just the typical junk mail and has no bearing on the delayed response. But let’s say you can see the contents of all of the letters as well (packet analysis), and that the letter from the Publishers Clearing House was not your typical junk mail – it was a notification that your “pen pal” just won $10 million dollars. With that bit of information the source of their distraction becomes clear, and it’s easy for you to understand why you didn’t hear back in the typical response time.

The above example made one basic, yet often unstated, assumption about our ability to even analyze the Postal Service (network). It assumed we had the proper tools in place, and were using them 24×7, to perform ongoing, real-time analysis, all the while archiving our network data so we could go back and analyze it as necessary. As in our example, it isn’t always immediately obvious that something did or did not happen as expected. You need constant monitoring, with ongoing data storage, so you can analyze the problem as it happens, not wait for it to happen again and hope you catch it. Way more network analysis time is spent trying to reproduce problems rather than solve them. Ongoing network monitoring based on packet analysis gives you all the information you need to analyze your network at its most elemental level.

So, the next time you sit down for some quality network analysis time, take a quick look at the packets per second. And then imagine that many little letters being delivered each second via your network infrastructure. At least for me, it provides a whole new perspective on just how hard my network works, and just how important my network monitoring and analysis software is to me when something goes wrong.

•