Packet Deduplication

Depending upon the packet capture method you use, you might send multiple copies of the same packet to the NetShark. This can occur when you are:

port mirroring multiple VLANs from the same monitoring port and the packet is routed on the device from one VLAN to another. Even if you are mirroring only ingress to the VLAN, the switch can mirror a copy of the packet when it enters the first VLAN, and mirror a second copy when it enters the second VLAN.

port mirroring both ingress and egress on the port or VLAN and the packet is routed into and out of the same port or VLAN.

using an aggregating TAP and the packets are detected on both ports being aggregated.

using an intelligent monitoring solution that is capturing the same packet from multiple ports and is not performing deduplication.

If any of these actions apply to your environment, Riverbed recommends that you use port deduplication on the NetShark and NetExpress. The NetShark can deduplicate packets when necessary. You must enable this feature on the NetShark for each capture port. The NetShark deduplicates packets by evaluating the packet identifier along with other information in the packet. Deduplicated packets can capture TCP retransmissions; and duplicate packets, due to instrumentation, are dropped. The NetShark performs duplication on a per-port basis.

Some network devices might retransmit TCP packets as part of their normal operation. If you are collecting packets on both sides of such devices to the same port on the NetShark or the NetExpress, enabling packet deduplication does not remove retransmission counts as these are true retransmits. The following are two examples:

If you capture traffic between an Interceptor and SteelHead and are using full transparency, the packets appear as retransmissions to the NetProfiler and NetExpress if the packets are captured is on the same port as the originating packets. To avoid this, do not capture traffic between the SteelHead Interceptor and SteelHead if configured with full transparency.

If you capture traffic on either side of a Cisco ASA firewall to the same port on the NetShark, the ASA has a security feature that is enabled by default to help protect against TCP session hijacking. This feature causes the ASA to rewrite sequence numbers for packets traversing it, resulting in observed retransmitted packets if the packets are captured on the same NetShark or NetExpress monitoring port. To avoid this, you can disable the connection random-sequence-number feature on ASA, or you can change your instrumentation so that you do not capture traffic from both sides of the firewall to the same monitoring port.