Forum Discussion
candc
Cirrus
CirrusRemoving the 'reject' keyword from a virtual, using TMSH / iApp
I have an iApp which creates a virtual server. Depending on one of my iApp choices, this is either configured as a normal load-balancing virtual server (displayed as "Standard" in the web GUI), or to reject all traffic (displayed as "Reject" in the web GUI)
However, I cannot seem to find a way to toggle the 'reject' value and turn it back into a normal virtual server.
For example, the current iApp template code contains:
set cmd "ltm virtual ${vname} destination ${ip}:${port}"
if {[iapp::is ::net__reject "yes"]} {
append cmd " reject"
}
iapp::conf create $cmd
If I create a new application based on this template and set the net.reject choice to no, it creates the virtual server without the reject keyword; if I then reconfigure and set the net.reject choice to yes it modifies the virtual server and adds the reject keyword; but if I reconfigure again and set the net.reject choice back to no it does not remove the reject keyword.
So how does one remove the reject keyword in my iApp (or in tmsh, for that matter)?
ekaleidoI don't see anything in your snippet that indicates it would ever append anything other than reject, after you have set reject.
candc@ekaleido - if you set the choice to 'no' the reject is not added to the cmd string, so when iapp::conf runs it shouldn't be included any more.
The re-entrancy rules of iApp say that subsequent calls to tmsh::create are changed to tmsh::modify. This works everywhere else I have tried.
Consider tmsh instead. How would you remove the reject keyword in a tmsh modify ltm virtual command (not an edit ltm virtual)?
What is the reasoning for using a explicit "reject" virtual server in this case? Can you not have the virtual not exist unless you need it? That would be the simplest way to handle this case and most standard. The problem for you here is that once you specify reject, even if your modify statement(which is what the iapp framework turns the create into after the initial save) does not contain the reject keyword unless something else is specified to override it then it wont go away.
For example specifying ip-forward will cause reject to go away and it will become a forwarding virtual server.
- candc
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.
- candc
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.