http keepalive not working

[mchockalingam]

I am configuring a 11503 for load balancing. I have the following config

service iowa1

ip address x.x.x.x

keepalive frequency 10

keepalive type http

port 80

active

The http keepalive is not working. However, if I change the keepalive type to icmp it works fine. Any help would be appreciated.

[jfoerster]

HI,

you missed two commands. first ist the keepalive method which is get or head and it is missing which URI the CSS has to query (see http://www.cisco.com/en/US/products/hw/contnetw/ps792/products_configuration_guide_chapter09186a00801579c3.html#wp1026657)

If you only want to monitor port 80 use keepalive type tcp.

The keepalive HTTP is better because it checks if the webserver is running and not only if there is certain port listening.

Kind Regards,

Joerg

[mchockalingam]

Ok, I modified the config to use

service iowa1

ip address x.x.x.x

keepalive type http

keepalive method get

active

The uri string is the root which is / and its the default. Still I am not able to make the http keepalive working. The url mentioned on the uri string should exist on the server. Correct?

[Gilles Dufour]

you need a tcp port.

'keepalive port 80'

Regards,

Gilles.

[mchockalingam]

Now, the config looks like

service iowa1

ip address x.x.x.x

keepalive frequency 10

port 80

keepalive type http

keepalive port 80

keepalive method get

active

Still it does not work. Do I need to check anything on the web server side? But when I change the keepalive to ICMP, I have no problem getting to the page.

[d.parks]

I'd recommend against a "get" keepalive unless you need to fail the server in the event that the content changes.

If you do a keepalive method "head" (which is default with "keepalive type http" set), the CSS will just look for a "200 ok" message from the server.

If the server is not sending a 200 in response, then the CSS is not going to be happy. You may need to use a protocol analyzer to see what the webserver is sending.

I've also seen issues with name-based virtual hosting and CSS http checks. Can you browse to the web server using the IP address as the URL? That's what the CSS is trying to do.

If all else fails, try a "keepalive type tcp". Not as good as an HTTP check but at least it's better than a ping.

[mchockalingam]

When I try to browse the site using the private IP(the VIP address), I get "page cannot be displayed". However, when I use the public IP, I am ok. The webserver is sitting in the DMZ and firewall NATS the address between private (VIP address) and public.

Why am I not able to get to it using the VIP address The CSS has 2 interfaces. One i/f is connected to the DMZ and the other i/f to the firewall. The webservers are configured with the dmz i/f on the css as default gateways.

I can ping the VIP address of the servers but not able to connect on port 80. Sniffer shows http 403 bad request error when I tried to browse the VIP address.

Any ideas?

[mchockalingam]

When I try to browse the site using the private IP(the VIP address), I get "page cannot be displayed". However, when I use the public IP, I am ok. The webserver is sitting in the DMZ and firewall NATS the address between private (VIP address) and public.

Why am I not able to get to it using the VIP address The CSS has 2 interfaces. One i/f is connected to the DMZ and the other i/f to the firewall. The webservers are configured with the dmz i/f on the css as default gateways.

I can ping the VIP address of the servers but not able to connect on port 80. Sniffer shows http 403 bad request error when I tried to browse the VIP address.

Any ideas?

[d.parks]

That sounds very similar to the Apache v-hosting issues I've run into in the past. I'm not an Apache admin, but my understanding is that the web server is setup in such a way that it expects to see request headers containing the URL for the site. If it sees the IP address instead, it doesn't know what content to serve, hence the 403 error.

A handy test for this is to add a host file entry on your PC that points the site's domain name to the VIP address and open a new web browser. If the page starts loading properly using the name and host file, then you know your network topology is ok, and it's the configuration of the webserver that's most likely to blame.

To enable an http health check without changing the web server config, you'll likely need to use a scripted health check so the CSS can send the appropriate name in the header. I think there's a stock script that can be modified to accomplish this.

[mchockalingam]

I think I found the problem. It is asymmetric routing. When inside clients try to get to web server, the traffic goes thru the inside i/f the firewall and the CSS but the return traffic from the web server directly goes to the firewall bypassing the CSS due to a static route on the web servers. The firewall drops it due to asymmetric routing.

I guess the only solution is to pass all dmz traffic thru CSS and allow ACLs to bypass the content rules for non-load balanced server traffic.

Is this a good idea? Or moving the servers that needs load balance to a different vlan would be a good idea? I am trying to weigh the options.

[mchockalingam]

I think I found the problem. It is asymmetric routing. When inside clients try to get to web server, the traffic goes thru the inside i/f the firewall and the CSS but the return traffic from the web server directly goes to the firewall bypassing the CSS due to a static route on the web servers. The firewall drops it due to asymmetric routing.

I guess the only solution is to pass all dmz traffic thru CSS and allow ACLs to bypass the content rules for non-load balanced server traffic.

Is this a good idea? Or moving the servers that needs load balance to a different vlan would be a good idea? I am trying to weigh the options.

[d.parks]

You could use a source-group configuration on the CSS to NAT the clients' IP addresses to a CSS address. This would force the return traffic back through the CSS. This is typically used in a one-armed situation.

[cliff.bowles]

As far as the keepalive, I've run into situations where the default page is a redirect to a login page, therefore the CSS does not get a 200OK even though the page is up. You can resort to keepalive type TCP and keepalive port 80, although it's not as accurate. Also, sometimes your web guys are willing to put a up.html page in the root directory that you can check against. Or you can use a scripted login, but that is kind of ugly and there are a lot of factors which can cause failures which you have no control over. (Active Directory, etc...)

If your CSS is not the default gateway of the servers, you really should use a source-group, as suggested, with the servers as destination services. It will make content owners unhappy if they collect user demographics though.

I believe you can actually form an ACL which will NAT traffic from a certain segment on the CSS. I haven't tried it.

Hope it helps...

CWB