If I add a column for TCP bytes in flight the number never goes above
29568 for "SNA-small.pcap" and 2720 for "DFW-small.pcap". Do you have
window scaling enabled?
Chandler, Mel wrote:
> Greetings all,
>
>
>
> My company is attempting to perform replication from one HP EVA SAN
> array to another HP EVA SAN array across the WAN. We have a metro
> Ethernet connection between the two with one Gigabit of shared
> bandwidth. We share the bandwidth with our other business units, with
> no QoS in place, but we have been told that the pipe has never been
> completely saturated, and we’re not rate limited. The SAN arrays are on
> 4Gbps fiber channel brocade switches. There are two devices called
> MPX110’s that send the data from fiber channel to Ethernet. Each MPX
> has redundancy groups they perform replication for, and although they
> have two Ethernet and two fiber channel ports on each, we only use one
> on each. Each MPX110 has a path they perform replication for to their
> counter parts on the other side. It is my understanding they negotiate
> a tunnel between them, Fiber Channel over IP. They’re each on their own
> 6509 which have a uplinks to a 3750 and that goes across the metro
> Ethernet to a 3560 on the other side, then up to a 3560 acting as the
> core and out to two 3560’s with an MPX on each one.
>
>
>
> 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.
>
>
>
> Thanks in advance for your assistance.
>
>
>
> Chandler Bing
>
>
>
> ******************************************************************************************
> This message may contain confidential or proprietary information intended only for the use of the
> addressee(s) named above or may contain information that is legally privileged. If you are
> not the intended addressee, or the person responsible for delivering it to the intended addressee,
> you are hereby notified that reading, disseminating, distributing or copying this message is strictly
> prohibited. If you have received this message by mistake, please immediately notify us by
> replying to the message and delete the original message and any copies immediately thereafter.
>
> Thank you.
> ******************************************************************************************
> FACLD
>
>
> ------------------------------------------------------------------------
>
> ___________________________________________________________________________
> Sent via: Wireshark-users mailing list <wireshark-users@xxxxxxxxxxxxx>
> Archives: http://www.wireshark.org/lists/wireshark-users
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
> mailto:wireshark-users-request@xxxxxxxxxxxxx?subject=unsubscribe
