Citrix ADC is restricted by not having scripting functionality? WRONG!

I had a customer tell me recently that their existing ADC could not be replaced with Citrix ADC, as there were complex custom rules for which the Citrix ADC couldn’t match. In my mind I heard the words “Challenge Accepted”. 🙂

The use case was to serve back a bespoke error page when a load balanced vserver was down. Simple. There are a number of ways to achieve this. Create a responder action with the custom response. We can use a responder policy using this expression: SYS.VSERVER(“Production-LB”).STATE.EQ(DOWN)
Job done. Or – Create a Dummy Vserver – with a responder policy bound to it with an expression of TRUE, and mark that as the backup VServer… Anyway, I was racing ahead, but the customer wasn’t finished. After 5 minutes time, if the back end server did NOT come up, they wanted to serve a different error message. I guess the first message was something like “Something’s gone wrong, please check back in a few minutes…” and the second message would say “Oops- something’s gone VERY wrong, maybe check back in an hour or two…”.


I asked what happened if the Vserver came up for a few seconds, then went back down again. The customer said that their existing solution restarted the timer, they would get the first error message again for 10 minutes, and then the second. Not a great solution in my opinion, as if you’re working to bring the back end system back online, the website users will think the problem is only temporary.

What we came up with was the following logic:
* Create two responder actions – one for “temporarily down, be right back” and the other for “Houston we have a problem”.
* Use a globally scoped variable that expires after 10 minutes ( This means a service flap doesnt reset the counter) – thereby improving the logic over the existing script.
* Set the vale of this variable with the system time the first time a request comes in and the production vserver is down. (We do this by binding the policy to a dummy BACKUP Vserver which only gets hit if all services in production are down).
* The responder policy expressions subtract the time the vserver went down from the current system time to check if it’s greater than 5 minutes.

Here’s the config:

add ns variable down_time_start -type ulong -expires 600
add ns assignment start-clock -variable "$down_time_start " -set SYS.TIME
add responder policy Resp-pol-Start-Clock "HTTP.REQ.IS_VALID && $down_time_start == 0" start-clock
add responder policy Resp-Pol-less-than-5-mins "(SYS.TIME - $down_time_start) < 300" temp-sorry-Action add responder policy Resp-Pol-Greater-than-5-mins "(SYS.TIME - $down_time_start) >= 300” Houston-sorry-Action
bind vserver -policyName Resp-pol-Start-Clock -priority 100 -gotoPriorityExpression NEXT
bind vserver -policyName Resp-Pol-less-than-5-mins -priority 200 -gotoPriorityExpression NEXT
bind vserver -policyName Resp-Pol-Greater-than-5-mins -priority 300 -gotoPriorityExpression NEXT

You might have to change some of the GoToPriorityExpressions to END if it’s the last policy to be evaluated, and the snippet above doesnt include the policy actions. But hopefully you get the idea. Variables and assignments – giving you conditional logic and configuration without having the break out to a customised scripting language. Thanks for reading.

Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.