Slow network problems--revisited

[christopher_hall]

Greetings, I posted about a month ago (Feb 18) issues with our network running slow (file coping, printing as a couple of examples). At this point, we're still having issues. How is untagged versus tagged traffic treated? If frames aren't tagged properly, what would happen? I still see our switches running free of errors, so not sure what else to look at.

[christopher_hall]

Thanks....keep it simple, right;O. In fact, Friday afternoon, browsed through youtube and actually found some vids on wireshark and filtering.

I'll post back.

[ksjonak217]

Chris,

I would suggest you try another copy application and see what happens. Find one that allows you to set the TCP window size. You might want to start by downloading iperf and running it across your WAN link. I have encountered so many prblems with file copies over WAN links that can be resolved by (usually) upping the TCP window size.

Cheers!

Keith

[suthomas1]

Sorry guyz to barge in between..but even we have a similar issue with some applications over WAN MPLS link being slow especially when the users get inside the app & trying moving thru the different options or performing actions.The Network between this users site & the server destination n.w is perfeclty fine with, no errors on switches or nodes,b.w is also fine.

But i did find retransmissions using one of our tools..bt i can parse in further as no sniffing is allowed & the tool only shows the retransmissions.

Any clues on this?

thanks!

[Joseph W. Doherty]

TCP retransmissions, often indicates lost packets (could also indicate timed out packets or out of sequence packets). If you're using a WAN MPLS cloud, one place drops commonly can happen is on a congested MPLS egress link (PE to CE). Common causes for this are asymetrical bandwidths between sites (e.g. HQ having more bandwidth than remote) or multiple sites sending to one site. Since the drops are within the MPLS cloud, you won't see them registered as drops on your equipment as you might for traffic entering the cloud (CE to PE).

Detecting TCP retransmissions can be one of your best clues that this might be happening. Another might be high load rate inbound, but if the drops are bad enough, you might only see a low average utilization (caused by TCP flows be driven into slow start).

If this is happening, "fixes" include better usage of MPLS vendor's QoS, shaping on CE egress (if there's no multiple site-to-site traffic), and/or increase available bandwidth.

[christopher_hall]

I'm coming back with a trace. I don see some arp requests (hard to tell how many.....in one minute, I grabbed 35000 packets). I also see this [TCP Out-Of-Order] and this happens with several protocols...HTTP/Telnet/TCP. Are these restransmissions?

[christopher_hall]

Sorry, mistyped....I DO see some ARP requests.

[Joseph W. Doherty]

re: TCP Out-Of-Order

If you don't have multiple paths, then it likely only indicates lost packets.

[sdoremus33]

Yes these are reffred to as SAcks (Sequential Acks), meaning in its basic lets sy Hst x sends some data to Hst y in 8 byte chunks, so Hst y receives the following Frame 1-2-4-5-6-7, so what happens is that Hst Y sends an ack to Hst x and says I diodnt receive 3-8 of the packet, so Hst x retransmitts the packet knowing that 3-8 need to be retransmitted. You will see this in Wireshark as a Seq ACK. This definetly can dause latency issues, One thing you can do is to Adjust the TCP Window size.

[suthomas1]

Its known that even mtu issues cause slowness.How do we check if mtu is the cause of the issue & ways to correct it..

Pls suggest?

[christopher_hall]

Hey Keith,

What about copying via DOS? Not sure that allows the resizing of windows, which is really too large (ha--pun!). I think once of my peers has a Linux box, so I'll look into that.