CSS load balance - Lock Outlook 2007 - RPC over http

Unanswered Question
Feb 17th, 2009

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!

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
Gilles Dufour Wed, 02/18/2009 - 01:42

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.

Gilles Dufour Wed, 02/18/2009 - 01:42

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.

jrmalmeida Wed, 02/18/2009 - 06:19

Hi Gilles!

Thank's for the information, but is loadbalancing Layer 4.

Any suggestions of what to do?

Thank's!

Gilles Dufour Thu, 02/19/2009 - 01:41

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.

jason.espino Wed, 02/18/2009 - 17:25

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!

jason.espino Thu, 02/19/2009 - 13:15

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

jason.espino Thu, 02/19/2009 - 13:57

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!

jrmalmeida Fri, 02/20/2009 - 11:43

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.

jrmalmeida Fri, 02/20/2009 - 12:53

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

Gilles Dufour Fri, 02/20/2009 - 15:06

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.

Actions

This Discussion