ANNOUNCEMENT: Live Wireshark University & Allegro Packets online APAC Wireshark Training Session
April 17th, 2024 | 14:30-16:00 SGT (UTC+8) | Online

Wireshark-users: Re: [Wireshark-users] FCIP issues with SAN replication

From: Bill Meier <wmeier@xxxxxxxxxxx>
Date: Tue, 29 Jun 2010 12:08:12 -0400
Chandler, Mel wrote:
Greetings all,

> <snip>
Now the problem, although we have one gigabit of bandwidth, they'll only
use about 13Mbps of it each, we've verified this with iperf.  Each
connection we'll only take 13Mbps of bandwidth, parallel tests show each
connection gets 13Mbps of bandwidth.  The HP engineer told us that at
5Mbps we get approximately 1.3Mbps of actually data, which means that
FCIP has 80% over head?  Can that be right?  The big huge problem is
that after running for several hours they'll eventually just die and
have to rebooted to start replicating again.  They're already on the
latest firmware (2.4.4.1).  The only error we get from the statistic
screen of the MPX's says they're getting TCP timeouts.

I've performed captures on both sides' MPXs' and the errors I see in a
60 sec sample are FCP malformed packets (~4300), duplicate ACK's (~41),
previous segment lost (~3), fast retransmission (~3).  When HP was
questioned about the FCP malformed packets they stated that they use a
proprietary protocol and that wireshark wouldn't be able to decode it.
I've since searched for this protocol but can find no references to it
anywhere.  The other errors seem so minor and few it would be hard to
believe that they're impacting the data stream that much if at all.

I'll include a small sample of the captures, if it lets me.


Taking a quick look at one of the captures (SNA) (and if I haven't missed anything) I see the following.

The rate appears to be limited because of the "TCP window size" being used and the TCP "acknowledge time" for the connection.

1. It appears that the "ack time" is about 35 millisecs (interval between when a frame is sent and when an ack is received).

2. The 'TCP window size is 32768 bytes).


If we assume "infinitely fast" transmission then the pattern is
essentially:

- send 32K bytes;
- wait 35 ms for the acks
(and so on)

So: ~ 1/.035sec * 32KBytes can be sent per second
 which is ~ 8Mbits per/sec

If my analysis is correct I suggest you may want to consult with ?? about the configuration of the TCP connection.

You can see the pattern in the SNA capture by:

1. Filter on the TCP/FC connection (Statistics ! Conversations ! TCP)
2. Select the first frame
3. Do Statistics ! TCP Stream Graph ! Tine sequence Graph (tcptrace).