disabled virtual server continues to serve - apparently!

I verified that it is indeed still serving as I threw new uris at it and it showed them correctly on the page. The log too shows the irule continuing to be exercised.

Hi Greg,

 

 

Are you sure you're testing to the disabled virtual server? On 10.2.1 when testing to a disabled VS, I get a TCP reset and the following logged to /var/log/ltm:

 

 

warning tmm[5343]: 01200006:4: Packet rejected remote IP 10.1.0.1 port 62599 local IP 10.1.0.15 port 80 proto TCP: Destination VIP disabled.

 

 

Aaron

Actually, I think the issue is that you have an existing TCP connection to the virtual server, disable the virtual server and then continue to make requests over the pre-existing connection. If you want to ensure no pre-existing connections are allowed, you can disable the virtual server and then clear the connection table entries for that VS:

 

 

b conn server 10.1.0.15:80 delete

 

 

Aaron

Yep. I'm sure. Leave it long enough (minutes) and reload the page and you get a reset from the F5. Then I get

 

warning local/tmm tmm[3481] 01200006 Packet rejected remote IP 192.168.22.1 port 63698 local IP 192.168.22.11 port 80 proto TCP: Destination VIP disabled.

 

 

I'm using the LTM Virtual Edition

 

BIG-IP 10.1.0 Build 3341.1084 Final

 

 

Regards,

 

Greg

Existing connection is what I suspected. The intent in the future is to use icontrol to disable a service but that won't be enough to stop it dead immediately. So, I will look to see if I can get the virtual server status in the irule to stop it at that layer. It is not the behaviour that I expected and it begs the question why there aren't at least two modes of disable - go away slowly and STFU now. I'll see what can be done.

 

 

Thanks

Out of curiosity, what's the use case for killing active connections to the virtual server?

 

 

Short of deleting the connection table entries, there isn't a built in way to kill existing connections. You can set the virtual server down, but existing connections will still be allowed. Likewise, you can set a pool member or node to forced offline to prevent new connections or connections from clients with a persistence record from being allowed.

 

 

There isn't a way to get the virtual server status from an iRule. You can get a count of active members in the pool using the active_members command. I suppose you could disable the pool instead and then check in HTTP_REQUEST for [active_members [LB::server pool]] == 0 and send an HTTP response with HTTP::respond or a TCP reset with reject.

 

 

Aaron

The use case is that I actually want the service to stop. The connections are active in as much as they are not closed at the tcp layer but the connection is idle. I tried different uri's about increasing time intervals between - 15 secs, 30 secs, 45 secs .... After over 5 minutes of doing this the server was still responding. I don't know how long the last one was as I was starting to dig through the LTM Config manual and looking through LTM screens.

 

 

The server uses the tcp profile and the http profile. The default value for idle timeout in the tcp profile is 300 seconds and I expect that this is the controlling setting. At the very least I want to understand what is controlling the current behaviour. I'm about to look at the production big-ips and see what values are in the http class and the tcp profile.

 

 

Regards,

 

Greg

By default, TMM will keep a connection open as long as neither the client or server close it and it's actively used before the TCP idle timeout expires. 300 seconds for an idle timeout is fairly high for production HTTP virtual servers. If your servers respond reasonably quickly to requests you could probably lower this.

 

 

Regardless, the idle timeout isn't really the issue here. If you disable the virtual server a client could continue sending requests over the same TCP connection as long as the server doesn't close the connection and they each request before the idle timeout expires. I think the simplest and most efficient solution for this is to delete the connection table entries after you disable the virtual server. If that's not appealing, you could try the iRule approach I outlined above.

 

 

If you think it would be useful to have an option to disable a virtual server, pool or node with active connections deleted automatically you could always open a case with F5 Support and ask them to consider a request for enhancement.

 

 

Aaron