Can any one explain what causes a TCP window trace like this.

DevilWAH

Hi,

Got a 100mbs site to site link that has started playing up, from the A end to B end I can get 100mbs throughput, but trying from B to A I only see about 10mbs.

So i tested by connecting a PC to router at site B, with a static route pointing across to the A end, and took a capture at the receiving port at A which is on a 6500.

PC -- Router -- WAN link -- Cisco 6500



I am use to seeing the windows size grow and then drop as the traffic hits the bandwidth link. This gradual drop in window size I was not sure how to explain.

any ideas?

philz1982

A couple things I would check. First throttling due to a Bandwidth restriction on the B to A side. Can you post your WAN port Config? Are your settings right/ identical from a QoS/Speed perspective?

DevilWAH

Hi,

Taken all the QOS off both sides while I am testing, just ip address and hard coded to 100/Full. The problem was identical before removing QOS, and link utilization B to A never exceeds 20% of a 100mbs link.

If I was hitting the bandwidth I would have expected to see a jagged line, raising to threshold and then dropping before rising again, this is exactly what i see using the same mirror port to capture when sending traffic A to B.

more like this

http://tcp.cs.st-andrews.ac.uk/cgi-bin/window_evo_sim.cgi?prob=1&num=1000&mws=99999&mss=1400&width=500&height=350

I have never seen such a smooth TCP window size and gradual a run down. If a TCP connections "see's" congestion it takes a big chunk out of the window size, but this is a real gradual shrinking.

philz1982

It remains the same no matter the traffic type and/or machine used to test the connection? Also, do you have a different router to test out to validate it is not the link. Can you post your config, Minus IP's.

SteveO86

Yea that is a smooth decrease of the window size. Almost too smooth for packet loss. Shaping policy maybe?

Are the clients sending TCP Window updates and call the decrease of the window size?

Could also be application behavior.. I've seen a lot of funky application behavior in wireshark.

DevilWAH

philz1982 wrote: »

It remains the same no matter the traffic type and/or machine used to test the connection? Also, do you have a different router to test out to validate it is not the link. Can you post your config, Minus IP's.

I can type config

#ip address x.x.x.x y.y.y.y
#speed full
#duplex full

every thing else is removed from the interface.

OSPF is configures with and is updating routes correctly, but have tried it with static routes.

Tried it with a 3945 and this 3845 router.

same results what ever end device i test from at the B end, Linux and windows boxes.

d4nz1g

It seems like an issue with your WAN link. What kind of link is it? Maybe your ISP misconfigured the shaping on one side to 10Mb

DevilWAH

d4nz1g wrote: »

It seems like an issue with your WAN link. What kind of link is it? Maybe your ISP misconfigured the shaping on one side to 10Mb

This is what I have thrown back to them, and hopeful they come back to me today.

DevilWAH

OK,

So Vodafone took down the link last Friday and ran a test where they passed traffic at 97% of the 100mbs link.

I have set up a capture on the link between the core switch and our router at the B end and on the incoming port from there equipment at the A end.

Core ---|---Router---Vodafone link ---|---Cisco 6506.

| = capture point

What I see is that packets seem to go out fine from the core to the router, but by the time they hit the 6506 many have been dropped (not captured) and many others are out of order. No ports either the cisco 6506, router (LAN and WAN side) or core show any errors.

any one think of what could be causing this issues, have swapped out SFP's, fibre/copper patch leads and tried other structured fibre pairs but issues remains the same?

cheers

SteveO86

So the packets are getting dropped with Vodafones cloud? Could be QoS within the Cloud. Sometimes you have to go after the SP's more than once. (It took them some time to find where one of my Multicast streams were getting rate-limited)

Can you see any pattern with the dropped packets? Perhaps the dropped packets are of a certain packet length or larger?

Are you capturing with a SPAN session or a network tap? any drops on the SPAN link?