Cisco Support Community
Showing results for 
Search instead for 
Did you mean: 
New Member

11501 VIP not reachable for HTTP/HTTPS

There are multiple VIPs, (HTTP/HTTPS) and (FTP/SFTP) that work.

A new VIP, does not properly work for HTTP/HTTPS. Behind this VIP there are two servers: and

In the load balancer GUI, under Web Content Services, the service bfqwww2_https shows as alive while the remaining show as down. While testing and both respond to HTTP/HTTPS requests on their real addresses.

Why are the other services showing as down?


Re: 11501 VIP not reachable for HTTP/HTTPS

What is the default gateway on and real servers?

If its any ip other than then you need group to source nat the traffic.

Syed Iftekhar Ahmed

New Member

Re: 11501 VIP not reachable for HTTP/HTTPS

The default route is currently set to

I found that the keepalive http / ssl was failing on the new HTTP/ HTTPS services for these servers. By changing it to keepalive type tcp, it now works but this obviously is not a solution as it would create a service black hole if the HTTP/HTTPS services malfunction on the server.

Any ideas?


Re: 11501 VIP not reachable for HTTP/HTTPS

If probe fails for all the services configured for a VIP then obviously there will a service outage/black hole.What else do you expect should happen in this case

If you want to avoid that outage and get some kind of message then you have an option of configuring a Sorry Server that shows a sorry page.

Syed Iftekhar Ahmed

New Member

Re: 11501 VIP not reachable for HTTP/HTTPS

Thanks for the replies.

This ended up being related to a bug, an upgrade to 8.10 resolved the issue:


Bug Details

Class A keepalives get stuck into a DOWN state The CSS services are transitioning for the ports used for class A keepalives are getting stuck in the wrong state, and therefore the CSS is leaking ports.

Engineering update:

The CSS is processing a FIN received from the server at the same time as the connection is being closed for a class A keepalive. There is a race condition possible in this scenario that could cause the port to become stuck in the wrong state if the connection is closed before the FIN is finished being processed. We now make sure that the FIN state transition is processed before the connection is cleared.

A workaround for this issue would be to have the server configured to not send a FIN back to the CSS for class A keepalives.


CSS keepalive fails service incorrectly

CSS may mark a service as dying or down if an HTTP keepalive is used and the HTTP response from the service spans more than one packet.


The keepalive was failing because the first packet ended with an 0x0d0a which the CSS was incorrectly interpreting as the end of the response header, and therefore, since it did not receive sufficient data from the server, the keepalive would fail

CreatePlease to create content