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...
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.
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.