Play around with these statistics screens after performing some typical operations on your own network. Then, stroll over to the top bandwidth users and politely ask them to stop using your corporate file servers to back up their MP3 collections! To save yourself some NSLOOKUP queries, make sure that your Wireshark capture options include the “Enable network name resolution” flag so that you can see hostnames in place of IP addresses when viewing the conversations traffic report. The “Bytes A -> B” and “Bytes A<-B” headings show bandwidth usage by direction. You can click the “Bytes” column heading to sort the report so that the largest bandwidth conversations appear at the top. You can then take information like that and use it for capacity planning, network performance optimization, baselining, and troubleshooting.Īnother item on the Statistics menu is “Conversations.” The dialog box comes up by default to the Ethernet tab, but if you’re interested in where network traffic is being generated on your LAN, click the IPv4 tab and view the byte traffic by conversations between IP addresses. With appropriate capture filters, this kind of information can help you see firsthand the network impact of user actions such as opening a share, copying a file over the network, opening an intranet or Internet page, and so forth. The resulting dialog box gives you relevant capture details in the top half and some useful performance details in the bottom half, such as the average packet size, average number of packets per second, and average bytes per second (or Mbits if you prefer). First, start a capture so that you have some data to work on, then stop it and choose Statistics > Summary. There are a couple of techniques that are handy for this sort of thing, and they’re both on the Wireshark “Statistics” menu. (For example, I was a little surprised to see on my own network that the simple act of navigating to a subfolder on a network share generated about 2000 SMB packets.) You might want to test certain procedures and user actions to learn which are more “expensive” in terms of bandwidth. You might be interested to see which computers seem to be creating more traffic than others. So, if y you're using Windows Server 2008, not Windows Server 2008 R2, then you'll need 2.2, which you can find by going to the "Go Spelunking" section of the Download page, select the appropriate site depending on where you're located, and then click on "win64" (or "win32" if you're using a 32-bit server, but I don't know whether Windows Server 2008 still supported 32-bit machines), then click on "all-versions", and then click on "Wireshark-win64-2.2.17.exe" to get the installer for Wireshark 2.2.One of the most useful things you can do with a packet sniffer like Wireshark is gain an understanding of who and what is responsible for the lion’s share of communications traffic on your network. If you're using Windows Server 2008, without the R2, that appears to be the server equivalent of Windows Vista, and 2.2 was the last version to support Windows Vista. So, if you're using Windows Server 2008 R2, try using version 3.0, which is the current release. The "End of Life planning" section of the Wireshark Wiki Release Life Cycle page says that Windows 7 is still supported, and that 3.2 - which will be the next major release of Wireshark, and isn't available yet - will be the last release to support it. At least according to the Windows 7 Wikipedia article, the server equivalent of Windows 7 is Windows Server 2008 R2 - which, the "2008" in its name notwithstanding, was released in 2009, the year when Windows 7 was released.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |