The first and most accessible tool is a packet capturing application, known as a sniffer or a protocol analyzer. Any network engineer should have one of those installed on his laptop. Commercial or freeware, just make sure you have one. In here I’ll use a freeware protocol analyzer, windows based, called Wireshark. Some might know it by its previous name, Ethereal. It’s a free distribution which I’m used to, there are others, but since it is not a protocol analyzer review, Wireshark was selected.
First thing I’d check is broadcasts per second, which is measurable by starting a capture and then selecting Statistics and IO Graphs, another window will open and you will see a line graph showing packets per second hitting your network interface card. Change the properties of the window as showed and you will have a graph showing broadcasts per second:
This image was lost when Geocities went down, comment if you need it and I'll try to reproduce
If you would like to test the multicast per second rate, then your window should look like the following:
This image was lost when Geocities went down, comment if you need it and I'll try to reproduce
For utilization just get rid of all the filters and make your Y axis to be based on bits/tick, as shown below, you should compare that to the link speed that Wireshark is connected to. Since utilization is bandwidth used/bandwidth supported*100. In a 100mb link you need 80mbps to be at 80% utilization:
This image was lost when Geocities went down, comment if you need it and I'll try to reproduce
Those are the basic vitals you should measure on a network, and they should be measured in multiple places, with focus on problematic ones. If you discover that there are behaviors which do not match the thresholds I mentioned in the previous post, look deeper and figure what is causing them. Multiple broadcasts can be a virus, but can also be a problematic workstation or malfunctioning application. Wireshark can help to identify that.
It is also important to mention that your view is limited to the vlan and the port you are connected to, unless you are supporting a hub based network, which means something might be happening somewhere else in the network and you have no clue. For a wider view you need to get into the network devices, a topic I’ll discuss next time.
Later, Avner.
Avner Izhar is an experienced IT professional; he has 14 years of experience in the networking area, on multiple continents, and has filled positions in post sales, pre sales and training. He currently holds CCIE in Voice (#15999), CCSI (#31623), CCVP and others. He is also the author of two CCIE voice training related books: CCIE Voice Technology Workbook and CCIE Voice written study guide, both published under NLI. When he is not blogging for Network World, he work as a Consulting System Engineer for World Wide Technology.
Through this blog, Avner will share his personal experience and assist junior and senior engineers in their IT tasks.