This is our old Q&A Site. Please post any new questions and answers at

let's assume I have the proper (capable) NIC and CPU power needed. nearly nothing is running on the machine.

(which will be best to monitor via? tap or span?)

would it be able to handle a 10Gbps network rate ?

afterwards, lets assume I also run some investigator (such as NetWitness Investigator) on the machine. would Wireshark still be able to handle the network rate?

asked 28 Jan '16, 04:29

n2disk's gravatar image

accept rate: 0%

converted to question 28 Jan '16, 04:45

sindy's gravatar image


@n2disk, what you wrote was definitely not an Answer to your older Question. It could have been a Comment, but it seemed to me it would serve you better to convert it into a new Question rather than a Comment to an Answer to the original one.

(28 Jan '16, 04:47) sindy

Of course, if you don't like my title, you can use "edit" to change it to a more appropriate one.

(28 Jan '16, 04:48) sindy

If you ask about "which will be best method of monitoring, span or tap", I guess you need to monitor a single link of 10 Gbps, not a complete traffic of a switch with several 10 Gbps traffic ports on it. If this is true, then a tap has a lower potential of errors than a span port. There is a whole page dedicated to the details on Wireshark wiki.

If by chance you had in mind capturing on a switch where multiple 10 Gbit/s ports are in use, a single 10 Gbit/s SPAN port is quite likely to be overbooked - but as a single tap is not applicable at all for such case, I guess you didn't have this in mind.

But regardless whether you use SPAN on a switch or a tap, you need two 10 Gbit/s ports on the capturing machine to be able to capture all traffic from a single full-duplex 10 Gbit/s line (and, logically, also two SPAN ports on the switch. Taps usually come with one mirror port for each direction).

Wireshark or tshark do much more than just capture, and so does the "investigator" software. So if you do not need to analyse your captured traffic online and round-the-clock, your best bet is to use only dumpcap, which just saves the captured packets into a file and does not analyse them at all (except that you may use capture filter to prevent some packets from being saved to the file). This reduces the CPU requirements to an absolute minimum, and also switches off any memory problems, as @Jasper has explained in this nice article.

permanent link

answered 28 Jan '16, 05:02

sindy's gravatar image

accept rate: 24%

Thank you for you answer.

as you were saying, I'm monitoring on a single link of 10 Gbps.

I'm afraid I wasn't clear about my question. My main goal is to monitor and save ALL(!) my network traffic and later analyze the captured .pcap (I could use an On-The-Fly indexing but I don't think Wireshark support it).

what will be the best way to do so, while supporting 10Gbps network rate (on a single link as you suggested) if even possible with Wireshark.

(28 Jan '16, 08:22) n2disk

OK. In modern servers, the network cards use direct memory access to store packets, and the hard disk controllers use direct memory access to retrieve data; the CPU just organizes that process but does not need to touch every single byte. So you need some 3 GByte/s minimum transfer rate of your disk and preferably a hardware architecture where the network cards' operation does not interfere with disk controller operation, and also about 3 Gbytes of disk space for each second of your intended capture. Or, seen from the other end, a 1 TB disk is sufficient for about 330 seconds of capture, which is just about 5 minutes. Logically, the disk must be connected to the capturing machine using a faster interface than a 10 Gbit/s Ethernet, so use of network storage to have sufficient capacity would need even faster links to be used. Is all this (disk capacity and available channel bandwidth) a non-issue for you?

You can get at half of those values if you capture each direction separately and merge them later.

(28 Jan '16, 08:45) sindy

It sounds to me that you are trying to capture and analyze a large amount of data. I would recommend to investigate other solutions rather than Wireshark.

I write this knowing that I might get some negative feedback from the Wireshark community. However, there seems to be two different types of thinking when it comes to capturing and analyzing network traffic:

  1. Macro-capturing = the need to capture all traffic and analyze a large amount of data. This type of capturing is done by IT departments to ensure connectivity across the network. There are many solutions for this need, but nearly all require some type of purchase (i.e., you need to spend some money to get the correct hardware, software and post-analysis tools). For example, NetScout and Savvius are 2 companies that provide these types of products.
  2. Micro-capturing = the need to capture specific traffic between two devices (or a few devices) and analyze the stream from a particular device. This type of capturing is mainly done by development and testing teams to ensure proper communication and protocol analysis. The best solution for this type of need is Wireshark.

If you are trying to capture a 10Gbps link over an extended time, you might want to investigate option one further.

permanent link

answered 28 Jan '16, 08:38

Amato_C's gravatar image

accept rate: 14%

No negative feedback allowed on this comment, as it is essentially correct. Always use the right tool for the job, and these cases require such distinction.

(28 Jan '16, 13:57) Jaap ♦
Your answer
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here



Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text]( "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Question tags:


question asked: 28 Jan '16, 04:29

question was seen: 2,176 times

last updated: 28 Jan '16, 13:57

p​o​w​e​r​e​d by O​S​Q​A