Symptoms

Slow network performance when accessing back-end servers through a Cisco CSS running 8.20.3.03 (or higher).

Background

Cisco CSS 8.20.3.02 (and lower) did not support window scaling. This meant that the initial window scale option announced within the 3 way handshake was not propagated to the server.
This issue was resolved within 8.20.3.03 (CSCsk92868), however even though the initial window scale (WS) option is propagated to the back-end server, the WS response from the back-end server is cleared and set to 0 by the CSS.

Below shows this behaviour (via the 3 way handshake):

CLIENT.3202 > SERVER.80: Flags [S], cksum 0xf7eb (correct), seq 1112270373, win 65535, options [mss 1260,nop,wscale 1,nop,nop,sackOK], length 0
SERVER.80 > CLIENT.3201: Flags [S.], cksum 0x5d1b (correct), seq 2130167885, ack 33254730, win 8760, options [mss 1380,wscale 0,eol], length 0

This results in the incorrect negotiation of the TCP window size and subsequently network delays.

Solution

In resolve this issue there are 2 configuration options available (based on your CSS software level):

• Cisco CSS 8.20.5.01 (and higher)  - on the CSS run the command - flow tcp-window-scale disabled
• Cisco CSS lower then 8.20.5.01    - on the server run the command - netsh interface tcp set global autotuning=disabled

Note : The command flow tcp-window-scale disabled is only configured on Cisco CSS 8.20.5.01 (and higher) due to caveat CSCtf70895.

Reference - Cisco Caveats

-- Software Version 8.20.3.03 Resolved Caveats
CSCsk92868--The Windows Vista Operating System (OS) can use the TCP Window Scale (WS) option in the TCP SYN.
The TCP WS option is not propagated to the back-end server and this may cause the application to fail.

-- Software Version 8.20.5.01 Resolved Caveats
CSCtf70895--If you configure the flow tcp-window-scale disabled command, the CSS may incorrectly send the TCP Window Scale (WS) Option to the backend server.