11501 VIP not reachable for HTTP/HTTPS

Unanswered Question
Aug 27th, 2008
User Badges:

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


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


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


Why are the other services showing as down?



  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
Syed Iftekhar Ahmed Wed, 08/27/2008 - 09:36
User Badges:
  • Blue, 1500 points or more

What is the default gateway on 192.168.0.25 and 192.168.0.27 real servers?


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


Syed Iftekhar Ahmed

mgierach1 Wed, 08/27/2008 - 12:16
User Badges:

The default route is currently set to 192.168.0.253.


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?


Thanks

Syed Iftekhar Ahmed Wed, 08/27/2008 - 13:02
User Badges:
  • Blue, 1500 points or more

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

mgierach1 Wed, 08/27/2008 - 19:36
User Badges:

Thanks for the replies.


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


CSCei81533


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.


CSCeb68203


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.


8/13/2003


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


Actions

This Discussion