Hi, I've come along some strange behavior of Wireshark. During a couple of captures, a lot of warnings appeared saying [TCP Previous segment lost]. Normally, this could occur is packets get lost or something, but you would suspect that the missing packets would be retransmitted some time later on (after the number of bytes in the send window are send and the first (missing) packet is not acknowledged by that time). Looking in the capture file I see the following (exported to CSV to make it clear text): Frame 1616 would suggest that the next sequencenr would be 1394188, but it's 1396948 so indeed it seems like a packet is missing. However, in frame 1627 sequence 1401088 is acknowledges meaning that all bytes before are received correctly. But I cannot find any (re)tranmission of the frame with sequence 1394188 so what's going on here? Is this a bug in Wireshark? Hope someone can answer this for me asked 07 Jan '11, 03:00  lutetia edited 07 Jan '11, 03:06 |
3 Answers:
I'm curious if it is possible that either the traffic rate was to fast for Wireshark to deal with or if there was some other path that that packet could have taken. The receiver certainly received 2 frames that would follow 1616 as indicated by the non-duplicate ack's that follow. This looks to me like wireshark some how is not getting all of the packets. answered 07 Jan '11, 03:28  Paul Stewart |
Hi Paul,there was no other path, and I've seen this in five or six captures I've made. I've used a Dell laptop with a 1 Gbps Broadcom network interface on a spawnport of a 3750 Cisco switch, to monitor all traffic on another 1 Gbps link on that switch. In the Capture options I've filtered one IP address to capture (10.74.37.2 in this case). That PC was attached to a 100 Mbps link so it's hard to believe that my laptop couldn't see all traffic from that PC. So to me it looks like some bug in Wireshark. Regards John Lasschuit answered 07 Jan '11, 03:38 lutetia 1 If you span 1 Gbit link, you will get both RX and TX frames, resulting in 2 Gbit/s of traffic on a fully utilized link. This will oversubscribe the spanport. Filtering on one specific IP addres takes place on the capturing host after the switch has dropped packets due to the oversubscription. It does not matter that the filtered host only has a 100Mbit, unless you are able to filter before aggregating the two 1 Gbit/s flows to a 1 Gbit/s port. You can verify this by checking the counters on the destination span port. (07 Jan '11, 05:30) SYN-bit ♦♦ Of course it would be easier to span the 100 Mbit/s server port to your 1 Gbit/s monitor port :-) (07 Jan '11, 05:33) SYN-bit ♦♦ SYNbit, I think you're right. The ports appeared to be configured as fixed 100 Mbps FD (not Gigabit) however, the same you've pointed out applies. Unfortunaly the counters are only five minute intervals so they're gone. On Monday we try to configure the main and span port as auto sensing, hoping that the real port (connection to provider) will come up as 100 Mbps FD and the span port as 1 Gbps FD (because the laptop is 1 Gbps). Let's see if Cisco supports this :-) (07 Jan '11, 09:24) lutetia The drop counters don't use 5 min moving weighted average. So if you look the counters, you'll see the drops. This is why I presented a case like this in Sharkfest 2010. It is possible to infer a lot by looking at the traces. Looking at IP ID can help you gather some information etc. But to me, it looks like the span dropped it. (07 Jan '11, 13:29) hansangb I agree with and second what hansangb is stating. Those drop counters will not reset or loop every 5 minutes. They may reset when the interface bounces though. It certainly looks like Wireshark does not have a complete view. This is one drawback of aggregating 2 direction traffic into a span port that does not have 2x the output capacity. (08 Jan '11, 08:48) Paul Stewart |
Clear the 3750 interface counters and then do a "show interface counter errors" to check for drops on the span target port. answered 10 Jan '11, 06:43  erics |
Is wireshark showing any packet drops on capture? Also are you using a teaming NIC that might be load-balancing (and some packets are travelling across the other physical NIC)?