02-17-2009 11:53 AM
I have problema whit load balance for configuration of client Outlook 2007. (using protocol RPC over http). Through the CSS, after a period of utilization, the Outlook lock. And without the CSS doind load balance, no ocurred the problem.
I appreciate any help.
Thanks!
02-18-2009 01:42 AM
Are you doing L7 loadbalancing or L4?
If layer 7, you should try to enable RFC2518 http methods
CSS11503-2(config)# http-method parse ?
RFC2518-methods Enable full support of RFC2518 Extension Methods
user-defined-method Configure user-defined method
If it still fails, you will have to take a sniffer trace and see exactly which method do not make it through so you can enable it manually.
Gilles.
02-18-2009 01:42 AM
Are you doing L7 loadbalancing or L4?
If layer 7, you should try to enable RFC2518 http methods
CSS11503-2(config)# http-method parse ?
RFC2518-methods Enable full support of RFC2518 Extension Methods
user-defined-method Configure user-defined method
If it still fails, you will have to take a sniffer trace and see exactly which method do not make it through so you can enable it manually.
Gilles.
02-18-2009 06:19 AM
Hi Gilles!
Thank's for the information, but is loadbalancing Layer 4.
Any suggestions of what to do?
Thank's!
02-19-2009 01:41 AM
Can't be Layer4 as we don't look into the data and won't even know which method is being used at that level.
So we would not drop a packet because of the method.
Please, send us your config and sniffer trace.
G.
02-19-2009 12:15 PM
02-18-2009 05:25 PM
Do you have a source Group configured on the CSS referencing your VIP and services? If not, there might be an issue within the HTTP headers referencing the service addresses rather than the VIP address. If you create a source group the CSS will proxy outbound traffic as the VIP. Please be advised, if you create a source group normal outbound traffic for the services participating in the Group will appear as the VIP as well.
Hope this info helps!
02-19-2009 12:19 PM
02-19-2009 01:15 PM
Hello Jose,
The output provided from the show tech attachment on the CSS does not appear properly on notepad or wordpad (to much info clustered). The output of the running-configuration should suffice.
"sho run"
Thanks
02-19-2009 01:57 PM
Hello Jose,
Sorry about my previous post, no need to provide the "sho run" output. Looking at the Group configuration you currently have on your CSS the VIP is acting as an inbound proxy to your servers to allow internal load balancing to function. You can verify this by looking at the Apache or IIS logs on the Servers, which will show the VIP address initiating the connection each and every time.
"add destination service"
If you change the why the services were added to the Group with the following:
"add service"
Outbound traffic for your that content rule will proxy out as the VIP address. The header information will contain the VIP address rather than the server IPs. This also means if the servers initiate their own traffic it will also appear as the VIP address rather than their own.
The main issue I see is you can only have either one or the other. Lose the functionality of internal load balancing, and "test" if the outbound proxy group rule fixes your current issue. Or leave internal load balancing as is, and outbound proxy issue is never tested.
I'm not familiar with your application, or network layout so this decision would be up to you.
I hope this information helps!
02-20-2009 11:43 AM
Hi Jason!
Thank's for information.
So changing "add service" by add destination service", solve problem the Outlook lock?
Current Configuration:
content exchange2007rcvir
vip address 10.58.32.123
add service scmt801cto
add service scmt801cas
redundant-index 205
protocol tcp
advanced-balance sticky-srcip
sticky-inact-timeout 30
active
Change to:
content exchange2007rcvir
vip address 10.58.32.123
add destination service scmt801cto
add destination service scmt801cas
redundant-index 205
protocol tcp
advanced-balance sticky-srcip
sticky-inact-timeout 30
active
Thank's for help.
02-20-2009 12:53 PM
Jason,
CSS is not created in a source group of "exchange2007rcvir. Is that the problem is that?
**** OWNER ****
content exchange2007rcvir
vip address 10.58.32.123
add service scmt801cto
add service scmt801cas
redundant-index 205
protocol tcp
advanced-balance sticky-srcip
sticky-inact-timeout 30
active
content exchangehtvir
vip address 10.58.32.89
add service scmt700cto
add service scmt700cas
redundant-index 201
protocol tcp
advanced-balance sticky-srcip
sticky-inact-timeout 30
active
content exchangewavir
vip address 10.58.32.33
add service scmt800cto
add service scmt800cas
redundant-index 51
protocol tcp
advanced-balance sticky-srcip
sticky-inact-timeout 30
active
***** GROUP *****
group exchangehtvir
add destination service scmt700cto
add destination service scmt700cas
vip address 10.58.32.91
active
group grp_axiavir
vip address 10.58.32.83
add destination service scxt393cas
add destination service scxt394cas
add destination service scxt395cas
add destination service scxt393cto
add destination service scxt394cto
add destination service scxt395cto
active
** No have exchange2007rcvir
02-20-2009 03:06 PM
If this was a group issue, they would see the problem much earlier than the http request - the SYN would not even succeed.
This is indeed a L3 rule.
So, we have no reason to drop a packet based on its content.
Can we see your sniffer trace ?
Did you verify if it is always the same packet that gets dropped ?
Try to increase your sticky-inact timeout.
Gilles.
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: