[Gerald Combs <gerald@xxxxxxxxxxxxx>]

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