As seth mentions, the capture-loss script is quite robust, because it
essentially computes an end-to-end value. I don't know of any situations
where in practice it makes poor estimates. These stats:
on the other hand come from the kernel's statistics. If packets are lost
prior to the kernel even seeing them (such as due to an overwhelmed SPAN
port - quite common), then while it reports no drops, that's not a
useful end-to-end measure. (Also, some kernels have bugs in how these
statistics are captured, for example missing out on packets dropped by
the NIC rather than the kernel.)
If you’re seeing nearly 50% of dropped traffic, perhaps the SPAN session is monitoring one direction of traffic flow across a NAT’d interface or proxy server? On the external interface monitoring inbound, and on the internal interface monitoring inbound? Any introduction of non bi-directional traffic would very likely confuse the capture loss script.
Thanks for all the responses. I put an Intel Pro 1000 in this morning and still using PF_Ring. I three hours of running Bro, I don’t see any reported packet loss. Looks like the Broadcom Card was most likely the problem.
Thanks for all the responses. I put an Intel Pro 1000 in this morning and still using PF_Ring. I three hours of running Bro, I don't see any reported packet loss. Looks like the Broadcom Card was most likely the problem.
Oh yeah, I would never use Broadcom for sniffing. I've had way too many problems with them.
Use Intel or ... use Intel. Too many stability problems with other vendors, and all of them resolved using X520.
Yep, for people with 10G links they're monitoring I'd almost always go with Myricom with the sniffer drivers. They have commodity pricing on their NICs and they do the hash based load balancing and it's extremely easy to setup (and it works on freebsd and linux).
