CSM in transparent mode having issues with OWA

[dcherry]

I'm having a bit of an issue with OWA servers outside the network. Basically, they won't load at all. Here is the config, minus all the proprietary info.

You can see by the abundance of header maps that I am having trouble with any page that utilizes certain redirects. Is my config goofy, or is there a better option than what I am doing.

Cache engines are NETAPP ver.6.0.1, directly connected to the csm via VLAN 20. Firewalls are also on Vlan 20 (PIX 535)

If I bypass the Cache with a policy on the CSM, or the Cache engine ACL's, the OWA sites work fine. However we are at the limit of Policy's on our config. One more, and we get out of memory issues. The Cache engines are also at their limit of bypass sites.

I've tried simple URL maps, I get no hits on the policy when I add them. Basically I'm out of ideas, and need some assistance.

----EDIT-----

Forgot to mention, CSM is version 3.1.4 (yes, I know). When I upped to 4.2.3a, the CSM stopped passing traffic after 1.5 hrs. So I had to revert back.

________________________________________

module ContentSwitchingModule 5

variable SYN_COOKIE_INTERVAL 3

variable SYN_COOKIE_THRESHOLD 5000

!

vlan 10 client

ip address 10.0.240.10 255.255.255.0

gateway 10.0.240.1

!

vlan 20 server

ip address 10.0.240.10 255.255.255.0

!

probe CACHEPROBE icmp

!

probe PIXPROBE icmp

!

map NETACAD header

match protocol http header Host header-value *.netacad.net*

!

map EDCOM-APPLE header

match protocol http header Host header-value *.apple.com*

!

map RMCITY header

match protocol http header Host header-value *.rmcity.org*

!

map POWERSCHOOL header

match protocol http header Host header-value *.powerschool.com*

!

serverfarm CACHERESPONSE

no nat server

no nat client

predictor forward

!

serverfarm OUTBOUND

no nat server

no nat client

predictor forward

!

serverfarm PIXFARM

no nat server

no nat client

predictor leastconns

real 10.0.240.250

inservice

real 10.0.240.245

no inservice

probe PIXPROBE

!

serverfarm WEBFARM

no nat server

no nat client

predictor hash address destination 255.255.255.0

real 10.0.240.50

inservice

real 10.0.240.60

inservice

probe CACHEPROBE

!

policy BYPASS

client-group 10

serverfarm PIXFARM

!

policy EDUCOM-APPLE

header-map EDCOM-APPLE

serverfarm PIXFARM

!

policy NETACAD

header-map NETACAD

serverfarm PIXFARM

!

policy RMCITY

header-map RMCITY

serverfarm PIXFARM

!

policy POWERSCHOOL

header-map POWERSCHOOL

serverfarm PIXFARM

!

vserver CACHENET

virtual 10.0.240.0 255.255.255.0 any

serverfarm OUTBOUND

persistent rebalance

inservice

!

vserver FROMCACHE

virtual 0.0.0.0 0.0.0.0 any

vlan 20

serverfarm CACHERESPONSE

persistent rebalance

inservice

!

vserver PIXOUT

virtual 0.0.0.0 0.0.0.0 any

serverfarm PIXFARM

advertise active

idle 600

persistent rebalance

inservice

!

vserver TRANSPARENT

virtual 0.0.0.0 0.0.0.0 tcp www

serverfarm WEBFARM

persistent rebalance

parse-length 4000

slb-policy BYPASS

slb-policy NETACAD

slb-policy EDUCOM-APPLE

slb-policy RMCITY

slb-policy POWERSCHOOL

inservice

!

________________________________________

[Gilles Dufour]

I'm not sure what you expect from us here.

You already mentioned that bypassing the caches solves the problem but you can't add more slb policy due to memory limit.

And you also can't fix the cache.

So, if the solution is not possible on the CSM, not possible on the caches, then unless you find a way to bypass it before the traffic hits the CSM, I don't see what you can do.

Could you identify the OWA traffic based on destination ip address instead of parsing the http content ?

Gilles.

[dcherry]

>So, if the solution is not possible on the CSM, not >possible on the caches, then unless you find a way >to bypass it before the traffic hits the CSM, I >don't see what you can do.

I'm asking for Cisco to help find the way to bypass it. If the CSM is not intelligent enough to do this, then I need a recommended solution.

Maybe I was a bit unclear there, my apologies. I need a solution for this other than a header map, which I can no longer do. Since our staff of 40,000 visit a plethora of different OWA sites, I need a way to increase the amount of sites allowed to bypass my cache solution. This needs to be done from the CSM.

If the CSM is not capable of doing this, then I need to find another solution. Is this possible with the CSM, or is there another Cisco solution I need to be looking at?

Now for the questions:

Why is the CSM ignoring a URL Map policy for bypassing this site, and forcing me to use a header map?

Is this an IOS issue, CSM software issue, or simply a misconfig on my part?

What parts of the URL string are ignored?

Why am I getting out of memory errors when I use more than 4 header maps?

Are there any documented TAC cases that address OWA issues on the CSM?

example:

---

serverfarm PIXOUT

nat server

no nat client

!

map SITEBYPASS url

match protocol http url exchange.site.com/*

match protocol http url http://exchange.site.com/*

match protocol http url https://exchange.site.com/*

!

policy SITEBYPASS

url-map SITEBYPASS

serverfarm PIXOUT

!

vserver TRANSPARENT

virtual 0.0.0.0 0.0.0.0 tcp www

serverfarm WEBFARM

persistent rebalance

parse-length 4000

slb-policy SITEBYPASS

inservice

---

This will not generate a match when I point a browser to http(s)://exchange.site.com. It sends it directly to the cache engines, not my PIXOUT serverfarm. What am I missing?

If you would like some sample sites that give the CSM fits, I have a few.

www.netacad.net (not an OWA site, but same issue)

any OWA site.

[Gilles Dufour · Accepted solution]

For the url map, don't fortget he url that you type in your browser is not what will be sent in the network.

A url is actually splitted in 2.

One part is the host and the rest is the uri/url.

So when you type "exchange.site.com/*", the host is exchange.site.com and the url is /*.

To match on a host you need the header map because host is inside the http header.

Using a url map is not good either in your case.

It will also require more memory.

The CSM is using a complex algorithm to quickly match regexp but the drawback is that this algorithm uses a lot of memory which increases quickly with the amount of map you configure/use.

So, the solution I mentioned already previously is to match on TCP/IP info - not HTTP data - to avoid the use of regexp.

If you want to bypass traffic for "exchange.site.com", try to find what is the ip address used for this site and create a new vserver to catch this traffic and use a serverfarm with predictor forward to bypass your caches.

Gilles.