02-18-2009 04:15 AM
I am in need of troubleshooting a situation where a user wants to access the load balanced web application (J2EE) with an application called "portal drive".
From my understanding this application utilizes the WebDAV extension and is more or less WebDAV client with "explorer" functionalities.
Application team now complains about following symptoms:
- The Portal Drive client connects to the rservers directly just fine.
- PortalDrive client won't connect using the VIP.
Therefore i sniffed the setup from my client to the VIP and i can see following behavior.
After the initial TCP setup the first HTTP Request used is "Method: OPTIONS". After this request the ACE sends and RST,ACK and drops the connection. This happens every time i connect using the VIP.
So now my approach to find the root cause circles around the two following scenarios.
A: ACE does not support a first request with Method OPTION.
or
B: After the initial request trough the VIP address the server maybe has to be SNAT'ed into the client side vlan.
I hope you guys have an idea how to fix this.
Thanks for reading
Roble
02-18-2009 04:55 AM
Roble,
do they inspect http configured ?
What version do they run ?
I added webdav support for http inspection a while ago, so new releases should be ok.
Without inspection, it should work as well I believe.
Gilles.
02-18-2009 05:08 AM
Hi Gilles,
we switched of the whole http inspection a while backed due to a previous issue with the PROPFIND option, you might remember that.
I was not aware that the Inspection of WebDAV is now officially supported. So therefore the inspection is unlikely the root cause if this issue.
What about the SNAT thingy, could that be a valid reason?
Roble
02-26-2009 03:49 AM
Anyone an idea what might be the source of this behavior, otherwise my only option will be another TAC case.
Roble
02-26-2009 06:17 AM
This should work.
What version do you run ?
Gilles.
02-26-2009 09:43 AM
Hi Gilles,
if i recall correct it's A2(1.3) currently. To be sure i have to check back @ the office tomorrow. This behavior has been observed for some time now and 2 previous updates didn't fix it. Either my config needs some major tweaking or there is a bug. I will try to get a TAC case opened tomorrow.
Roble
03-19-2009 05:19 AM
Hi Gilles,
the guys at TAC found the reason.
My class-map was only matching on:
The 3rd party tool was requesting <80> or <443> which had no exact match in the class map therefore and got dropped.443>80>
Adding the qualifiers in the class-map did the trick.
Roble
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: