Forum Discussion
Mike_Maher
Nimbostratus
NimbostratusSwitching Classes on ASM based on pool availability
I have an ASM with no LTM license, currently it is setup that traffic comes into the VS and is sent to a class based on Host, then run through ASM policy and sent to a pool which contains a node for an internal pool on an LTM. We have created 2 pools per host one for each Data Center. We use DNS internally to control which DC the traffic is sent to, but since ASM is based on IP only and can't use DNS, whenever we fail from one DC to another I must go in and manually repoint the class to the active pool.
So I am trying to craft an iRule on the ASM that can handle this automatically. One thought I had was to create 2 classes one for each DC for each host and them use the iRule to check the pool availability and send to the appropriate class based on that, or perhaps find a way to change the pool that the class is pointed to based on pool availability.
I have gotten this so far I am just trying to figure out if I can assign 2 http classes to a VS that will both match on the traffic and then let this iRule sort out who gets the traffic, also I assume I will have to set a default pool in the VS as well for this to work. Any thoughts or sample code would be appreciated. Thanks
when HTTP_REQUEST {
if { [active_members [LB::server pool]] < 1
HTTP::class select $anotherHttpClass
else
HTTP::class select $anotherHttpClass
}
}
6 Replies
- Chris_Miller
Altostratus
Your iRule should always take priority so I don't see a problem with having two classes (or none for that matter) attached to your VS. If you don't want to use a default pool, you should be able to specify the pool within the iRule as well.Using what you have above: when HTTP_REQUEST { if { [active_members [LB::server pool]] } { < 1 HTTP::class select $anotherHttpClass pool server pool } else { HTTP::class select $anotherHttpClass pool another pool } }
Obviously spaces aren't compatible, but you get the idea. 
Mike_MaherChris
Thanks for the reply, I thought I read in the Wiki for HTTP class select that the class needed to be attached to the VS in order to use it. It is good to know that the iRule always takes precedence. So the logic you have here is it basically sending the traffic to a class and then specifying which pool it goes to after the class processes it? Because honestly that is ultimately what I am trying to do send the traffic to a class and then be able to chose what pools it goes to after the class based on pool availability.- Chris_MillerPosted By Mike Maher on 07/02/2010 11:18 AM
Chris
Thanks for the reply, I thought I read in the Wiki for HTTP class select that the class needed to be attached to the VS in order to use it. It is good to know that the iRule always takes precedence. So the logic you have here is it basically sending the traffic to a class and then specifying which pool it goes to after the class processes it? Because honestly that is ultimately what I am trying to do send the traffic to a class and then be able to chose what pools it goes to after the class based on pool availability.
Your assumption is how I understand the flow, yes. I'm told iRules always get executed first. If the user matches your criteria, the iRule should say to use the class, and then to use that pool. If someone wants to correct me, they're welcome to. 
hoolioCirrostratus
The HTTP class selected with HTTP::class in an iRule does need to be associated with the VS or you'll get a runtime error when the rule is executed. You can use an iRule to override the HTTP class selection done by LTM, but you'll need to do this in the HTTP_CLASS_SELECTED event (and possibly HTTP_CLASS_FAILED if there is a chance a request might not match any HTTP class).
Also, if you're trying to check the default pool on the VS, you'd want to save the name of it in CLIENT_ACCEPTED as 'LB::server pool' will return the name of the currently selected pool. This wouldn't be the default pool if a prior request on the same TCP connection went to the other class.
However, if you want to use the same HTTP class regardless of which pool is up, you could not bother selecting the class in the iRule and just select the pool:when CLIENT_ACCEPTED { Save default pool name set default_pool [LB::server pool] } when HTTP_CLASS_SELECTED { if { [active_members $default_pool] > 0 } { pool $default_pool } else { pool alternate_pool } }
Aaron- Mike_MaherAaron,
Thanks for the information, I figured that the class needed to be attached to the VS in order for this to work. So just to make sure I am understanding you correctly, if I have a VS with a single class attached to, I can use this logic to select which pool the traffic goes to after the class processes the traffic? If that is the case it might be the cleanest way for me to do this, because for the most part I have a bunch of VSs with one class attached to them, there are a few cases where I have multiple classes attached to a VS being sorted by host, and in those case something a little more elaborate will have to be worked out in the iRule. I need to make sure the traffic passes through the class and gets processed by the App Security before going to the pool though, which it sounds like that is what you are saying for instances where there is only one class in the VS.
Mike - hoolioHi Mike,
You're correct. All traffic to the VS will be passed to the HTTP class and corresponding ASM web app and policy (assuming there aren't any filters configured on the class). You could have multiple HTTP classes with filters enabled as well.
The iRule just selects the pool based on the logic in the iRule. This selection is used after the request goes to ASM for validation.
Aaron
