Category: Top » View » Code-54908

Use the html code provided below to reprint the article: "What's So Great About Packet-Sniffers?" on your website
You can adapt the code to fit the style of your pages but you need to respect our Terms of Service

Title

Author

HTML code

article only

<h1>What's So Great About Packet-Sniffers?</h1> by Barry Koplowitz There are many products on the market that provide different levels of Network Management or Server Management. They are all easier to use than Packet-Sniffers and not nearly as cryptic. So, what’s so great about Packet-Sniffers anyway?
Many products are available that can monitor HTTP traffic that show cookies and header information. Your Network Operations Center (NOC) has all sorts of green, red and orange lights that go on and off, telling those who watch them the state of servers and infrastructure devices. You get emails and pages and even phone calls when important events are taking place. Switch goes down, a page goes out. Server goes down, a call goes out. Response time for some monitored application goes above the threshold you have set, an email goes out. So, again--what’s so great about Packet-Sniffers?
In the old days, you could put a Packet-Sniffer in a hub and see all relevant traffic. Those days are long gone in the enterprise. Now it can be a fairly complicated process. So, what’s so great about Packet-Sniffers anyway?
Part of the answer is that every other tool provides a summary, simulation or estimation of what is happening. They provide alerts that are very difficult to tune down to a reasonable level. These alerts are often not taken seriously due their being annoying, reflective of a moment in time rather than an issue--and a bit petty.
In the industry, there has been a growing trend away from utilizing a true Packet-Sniffer and an increase in dependency on tools that do the thinking for us. In part, this trend is driven by the lure of a fully automated process, a process where people are not required, except to act on alerts. Well, that doesn't work. If you want a true Root Cause Analysis, you will need a planned and proper test utilizing Packet-Sniffers.
An automated tool may tell you that an application is taking longer or that a circuit is slower than normal. How do you address that? For the network side, people start looking at the devices and their configuration, including routes. For the application—Packet-Sniffers are really the most reliable way—but they are underutilized.
Part of the problem is that there are few people that really know how to use them. Anyone can download WireShark. But WireShark, like the original Sniffer, is software. They show the packets but you have to understand what the packets are saying. That requires experience and training. Managers…invest in that training and seek those with the right experience. You will find many people who have the technical background to learn to read a capture file properly and plan Single Transaction Testing techniques. Find them and see that they get the training and support that they require. One such person can save weeks or years of unprofitable effort.
Here is a brief, but telling example from the Case Studies available on the Interpath Technologies (www.interpathtech.com) website.
A large Financial Organization underwent a relatively small server consolidation from an outdated system to a cluster of fast Servers on FiberChannel. After the cut-over to the new system, they began to lose transactions at a very alarming rate. This was costing them millions of dollars a day. The hardware vendor was there for days trying to fix the problem with no success.
We designed a systematic approach where we examined ALL the possible physical pathways from those servers--not just those designed by the vendor or those that were expected. It wasn't an inspired process--just a thorough one. We discovered the Oracle traffic from their lost transactions--that should have been exclusively in FiberChannel--on a 10Mbs Half Duplex copper segment! Their data had been falling into the "bit bucket." Once the problem was understood, they reconfigured the network interfaces and there was no further loss of transactions or dollars. Only a Packet-Sniffer can do that. The truth is in the packets—if you know how to read them.
So, what's so great about Packet-Sniffer? The truth of what is REALLY happening. They are not automatic and they do require much training and experience but they can show you what is happening in a way that nothing else can. That knowledge can save you millions of dollars a day or, years of aggravation.
This article is also available as a Podcast on "The Sniffer Guy" available through iTunes.
 <h2>About the Author</h2>Barry Koplowitz founded <a href="http://www.interpathtech.com">Interpath Technologies Corporation</a> in 1999. He was an instructor for Network General and NAI traveling around the USA teaching for Sniffer University and is a executive consultant to large enterprise environments in the area of Processes-Network/Application Analysis and Troubleshooting. He is the writer and host of <a href="http://www.itunes.com/podcast?id=270919666">The Sniffer Guy </a> podcast. <a href="http://www.interpathtech.com" title="www.interpathtech.com">http://www.interpathtech.com</a>
 <h3><a href="http://www.content4reprint.com/computers/whats-so-great-about-packet-sniffers.htm" title="What's So Great About Packet-Sniffers?">Article Source:</a> <a href="http://www.content4reprint.com" title="Free high quality articles">Content for Reprint</a></h3>

Tags/keywords

read the original article: http://www.content4reprint.com/computers/whats-so-great-about-packet-sniffers.htm

sample HTML code

full page

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
<meta name="keywords" content="sniffer,wireshark,protocol,analysis,troubleshoot,packet,filter,performance,tcp/ip,application,test" />
<meta name="robots" content="index, follow" />
<title>What's So Great About Packet-Sniffers?</title>
</head>
<body><h1>What's So Great About Packet-Sniffers?</h1> by Barry Koplowitz There are many products on the market that provide different levels of Network Management or Server Management. They are all easier to use than Packet-Sniffers and not nearly as cryptic. So, what’s so great about Packet-Sniffers anyway?
Many products are available that can monitor HTTP traffic that show cookies and header information. Your Network Operations Center (NOC) has all sorts of green, red and orange lights that go on and off, telling those who watch them the state of servers and infrastructure devices. You get emails and pages and even phone calls when important events are taking place. Switch goes down, a page goes out. Server goes down, a call goes out. Response time for some monitored application goes above the threshold you have set, an email goes out. So, again--what’s so great about Packet-Sniffers?
In the old days, you could put a Packet-Sniffer in a hub and see all relevant traffic. Those days are long gone in the enterprise. Now it can be a fairly complicated process. So, what’s so great about Packet-Sniffers anyway?
Part of the answer is that every other tool provides a summary, simulation or estimation of what is happening. They provide alerts that are very difficult to tune down to a reasonable level. These alerts are often not taken seriously due their being annoying, reflective of a moment in time rather than an issue--and a bit petty.
In the industry, there has been a growing trend away from utilizing a true Packet-Sniffer and an increase in dependency on tools that do the thinking for us. In part, this trend is driven by the lure of a fully automated process, a process where people are not required, except to act on alerts. Well, that doesn't work. If you want a true Root Cause Analysis, you will need a planned and proper test utilizing Packet-Sniffers.
An automated tool may tell you that an application is taking longer or that a circuit is slower than normal. How do you address that? For the network side, people start looking at the devices and their configuration, including routes. For the application—Packet-Sniffers are really the most reliable way—but they are underutilized.
Part of the problem is that there are few people that really know how to use them. Anyone can download WireShark. But WireShark, like the original Sniffer, is software. They show the packets but you have to understand what the packets are saying. That requires experience and training. Managers…invest in that training and seek those with the right experience. You will find many people who have the technical background to learn to read a capture file properly and plan Single Transaction Testing techniques. Find them and see that they get the training and support that they require. One such person can save weeks or years of unprofitable effort.
Here is a brief, but telling example from the Case Studies available on the Interpath Technologies (www.interpathtech.com) website.
A large Financial Organization underwent a relatively small server consolidation from an outdated system to a cluster of fast Servers on FiberChannel. After the cut-over to the new system, they began to lose transactions at a very alarming rate. This was costing them millions of dollars a day. The hardware vendor was there for days trying to fix the problem with no success.
We designed a systematic approach where we examined ALL the possible physical pathways from those servers--not just those designed by the vendor or those that were expected. It wasn't an inspired process--just a thorough one. We discovered the Oracle traffic from their lost transactions--that should have been exclusively in FiberChannel--on a 10Mbs Half Duplex copper segment! Their data had been falling into the "bit bucket." Once the problem was understood, they reconfigured the network interfaces and there was no further loss of transactions or dollars. Only a Packet-Sniffer can do that. The truth is in the packets—if you know how to read them.
So, what's so great about Packet-Sniffer? The truth of what is REALLY happening. They are not automatic and they do require much training and experience but they can show you what is happening in a way that nothing else can. That knowledge can save you millions of dollars a day or, years of aggravation.
This article is also available as a Podcast on "The Sniffer Guy" available through iTunes.
 <h2>About the Author</h2>Barry Koplowitz founded <a href="http://www.interpathtech.com">Interpath Technologies Corporation</a> in 1999. He was an instructor for Network General and NAI traveling around the USA teaching for Sniffer University and is a executive consultant to large enterprise environments in the area of Processes-Network/Application Analysis and Troubleshooting. He is the writer and host of <a href="http://www.itunes.com/podcast?id=270919666">The Sniffer Guy </a> podcast. <a href="http://www.interpathtech.com" title="www.interpathtech.com">http://www.interpathtech.com</a>
 <h3><a href="http://www.content4reprint.com/computers/whats-so-great-about-packet-sniffers.htm" title="What's So Great About Packet-Sniffers?">Article Source:</a> <a href="http://www.content4reprint.com" title="Free high quality articles">Content for Reprint</a></h3></body></html>