I'm trapping a problem with replication between our on-site and off-site san. The data goes from the onsite san, across a fiber-scsi to ethernet switch, over dark fiber to the offsite location, across another ethernet to fiber-scsi switch and onto the off-site san.
The fiber to ethernet switch continually registers retransmissions and slow tcp starts. However the ports on the cisco ethernet switches show no drops, no errors of any kind. utilization statistics of the links (including the ports that connect the dark fiber and the ports that connect the fiber-ethernet switch) all show low utilization, as in not even a 10th of the available bandwidth. CPU on the cisco switchs is under 10%.
So I trapped packets with wireshark on the port where the fiber-ethernet switch connects to the cisco switch. What I see are frequent TCP Sequence issues that will say "The frame acks a segment we have not seen". I see that for transactions going in both directions.
If find this odd. For point "A" to generate an Ack it had to get the packet in the first place. For point "B" to say, "I never saw the packet this is acking" is insane...who put the packet on the wire for A to ack if B did not ever see it? B had to generate it to begin with!!
Is it possible this error is a result of using a port mirroring situation instead of a real wiretap? Could wireshark just be missing something in the capture? It is interesting that these are not just at the start up capture these errors are seen through out the trace. And I don't see any legimate packets with the sequence number that the packets are supposed to be acking...they really aren't there.
But then, at some point they had to be..unless the device on the other end is just randomly making up acks....
thanks for insight.
The fiber to ethernet switch continually registers retransmissions and slow tcp starts. However the ports on the cisco ethernet switches show no drops, no errors of any kind. utilization statistics of the links (including the ports that connect the dark fiber and the ports that connect the fiber-ethernet switch) all show low utilization, as in not even a 10th of the available bandwidth. CPU on the cisco switchs is under 10%.
So I trapped packets with wireshark on the port where the fiber-ethernet switch connects to the cisco switch. What I see are frequent TCP Sequence issues that will say "The frame acks a segment we have not seen". I see that for transactions going in both directions.
If find this odd. For point "A" to generate an Ack it had to get the packet in the first place. For point "B" to say, "I never saw the packet this is acking" is insane...who put the packet on the wire for A to ack if B did not ever see it? B had to generate it to begin with!!
Is it possible this error is a result of using a port mirroring situation instead of a real wiretap? Could wireshark just be missing something in the capture? It is interesting that these are not just at the start up capture these errors are seen through out the trace. And I don't see any legimate packets with the sequence number that the packets are supposed to be acking...they really aren't there.
But then, at some point they had to be..unless the device on the other end is just randomly making up acks....
thanks for insight.