Removing the 'reject' keyword from a virtual, using TMSH / iApp

Yes, I could set ip-forward, which removes reject, but then how do you remove ip-forward? For what it is worth, setting ip-forward doesn't result in a "Standard" virtual server (as per the web GUI) either.

Ultimately, the use case was to support disabling the virtual server from within the iApp, while leaving the rest of the config intact (e.g. for review).

I started off using enabled and disabled (and may go back to it) but this leaves existing open connections active until they are closed, so I thought I'd try setting reject to see if it behaved any differently.

It just seems odd to me that, once you have added the reject keyword in tmsh, you can't remove it again, without tearing down the whole virtual server and recreating it.

Ah, ok. The use case makes sense now. My suggestion is I would just revert back to using disabled/enabled as that is the correct way to leave VS intact without removing it from the box. I would argue that wanting active connections to continue would be a value add and not a negative thing so as a soft service shutdown occurs correct? Does the VS have a pool attached for load balancing, because also in that case you could set the pool memnbers to force offline which you terminate active connections as well.

And i do agree that switching from reject to full VS and back is unique as you have experienced, however the use case for using reject is not meant for this as the enabled/disabled provides that (albeit with observed behavior about open connections). Reject is more designed for if you have a network virtual server for example and want to deny a specific host ip in that range, or if LTM is acting as a firewall and instead of silently dropping packets you want a reset to be sent to the client so they are aware.

It's only a value-add if it is the desired behaviour at the time.

The reason I want to be able to disable the node and abort open connections, is that this particular virtual server acts as a site-wide probe target for another upstream load balancer (outside of my control).

That device uses a long-poll mechanism, so the connection is maintained through the enable/disable configuration.

There is no pool behind the server, it merely points to an iRule which implements a rudimentary echo server. I don't really want to have to implement dropping the connection from within the iRule.

I have gone with with simply deleting the virtual server for now but, for review purposes, I would've preferred the virtual server was there but explicitly disabled, rather than missing and possibly forgotten.

Understood. Feel free to submit a case if you like that can be bubbled up into a bug/feature enhancement. The initial thought here is reject isn't the issue directly, the goal is to provide an option to stop active connections in addition to new+persistent.

One additional thought in the meantime. You could always clear out the active connections from the connection table (more dangerous) Steps outlined below, if all connections are going to the VS address for example you could delete all client side connections destined to that address which would force them to be reset for any subsequent packets that come in.

For example, to delete all port 80 connections to the virtual server 10.10.10.211:http, you would type the following command:

tmsh delete /sys connection cs-server-addr 10.10.10.211 cs-server-port 80

I thought you might be onto something there, and that I could call tmsh::delete /sys connection cs-server-addr ${ip} cs-server-port ${port} from within the iApp, but it just hangs and eventually tells me it is restarting the configuration utility...

set     cmd         "ltm virtual ${name}"
append  cmd         "  description \"${desc}\""
append  cmd         "  destination ${vip}:${port} ip-protocol tcp"
append  cmd         "  [expr {$enabled == 0 ? {disabled} : {enabled}}]"

iapp::conf create $cmd

catch {
    if {$enabled == 0} {
        tmsh::delete "/sys connection cs-server-addr ${vip} cs-server-port ${port}"
    }
}

Change the section from catch on down to look like the following, I am not sure about the quoting...and also changed the catch format to encapsulate the command as opposed to two extra lines of code. Also, then you could log $err to see if that adds any info.

if {$enabled == 0} {
    [catch {tmsh::delete /sys connection cs-server-addr ${vip} cs-server-port ${port}} err]
}

Same outcome. $err is never populated and a puts statement either side of the catch never runs the one after the catch -- it just hangs at that point and restarts the web GUI after 2-3 mins.

Is delete /sys connection... perhaps expected to run on another thread, or something? Perhaps some sort of transaction thing?

OK, I got it. Assuming a threading/transaction issue, I have updated the tmsh::delete call to be an exec tmsh delete instead. Now the reconfiguration does not hang and the connection drops as expected.

Whether or not that is an arbitrarily safe operation is another matter -- should I attempt to sanitise my input to $vip and $port in any way?

if {$enabled == 0} {
   catch { exec tmsh delete /sys connection cs-server-addr $vip cs-server-port $port }
}

Perfect, was going to suggest exec'ing out to have it be a separate transaction. That should be a safe enough operation assuming you wrap the exec in the catch statement, as well as ensuring the connections you are deleting are in fact the expected connections.(Sanitizing as you mentioned, you will have to come up with the use case for checking it is correct.) One other thought is you add a "sleep 1" right above that catch to ensure the delete of connections happens after the vip has been fully updated to disabled.

Is there a place where I can put this that guarantees that the transaction is committed and/or the service is disabled first?

On reflection, sleep 1 seems a bit racy to me...