Cisco ACE Modules with Windows Sharepoint 2010

I recently ran into issues with a Windows Sharepoint 2010 environment that is load-balanced by Cisco ACE modules. 

I’m no Sharepoint expert so if I get the WSS terminology slightly wrong – you’ll know why!

Basically the issues presented themselves in the following ways:

1. A Sharepoint site had some sort of webpart that enabled “live” view of Excel spreadsheets within the browser.

When you first visited the page, everything was fine and the spreadsheet loaded successfully, however upon navigating away to a different page, any subsequent requests were either met with a browser dialog box stating that an error occurred finding the file, or an HTTP 503 Gateway error.

2. Miscellaneous authentication issues (HTTP 401 Unauthorised)

From an networking perspective, this was occurring across a number of resilient pairs of ACE’s.  All were set for session persistency using a named cookie that was inserted by the ACE.

Nothing unusual so far!

Where it got interesting was when doing some packet captures, and Fiddler HTTP traces.

In these I could see that the cookie the ACE was insterting was present within the browser session, and an additional cookie set by WSS for keeping the session authenticated.  I also noticed that were two other entries in the cookie, that to me, looked like random characters, but I concluded that these were inserted by the WSS server.

After some investigation, I determined that the HTTP header was larger than 4096 bytes – the extra entries that WSS was added were around 3400 bytes each (there were two! ).

It transpires that there is a default number of bytes that the ACE checks for a cookie in the HTTP header is 4096 bytes. If a cookie, HTTP header, or URL exceed this 4096 value, the ACE drops the packet and sends a RST to the client.

The solution for our environment was to increase this value to overcome the large HTTP header size containing the WSS inserted data.

Changes needed on the ACE:

parameter-map type http HTTP_MAP_HEADER_LENGTH
set header-maxparse-length 16384

This defines a greater value. You can also set the ACE to passthrough any oversize packets if you choose to.

Then you need to apply that parameter-map to a policy.

policy-map multi-match my-policy-name
class my-class-name
appl-parameter http advanced-options HTTP_MAP_HEADER_LENGTH

Hope this helps someone out. Any questions or feedback is welcome via the comments link below.