iRule to direct specific IPs to specific members, not working as expected.

Question

I have a 6400 LTM HA pair, running 10.2.4HF5.
I have a oneconnect virtual server, ssl proxy, with both cookie and source_addr persistence to a pool with 12 members....as 6 different IPs, and two different ports on each of the 6 IPs.
pool ISIS-Web_SSL {
  lb method member observed
  snat disable
  monitor all https1.0
  members {
    10.10.10.72:5002 {}
    10.10.10.72:5004 {}
    10.10.10.85:5002 {}
    10.10.10.85:5004 {}
    10.10.10.102:5002 {}
    10.10.10.102:5004 {}
    10.10.10.108:5002 {}
    10.10.10.108:5004 {}
    10.10.10.110:5002 {}
    10.10.10.110:5004 {}
    10.10.10.115:5002 {}
    10.10.10.115:5004 {}
  }
}

We then have a webmethods cluster that is doing calls again this webserver, where during times of heavy traffic (which we anticipate will next occur on Jan 21, 2014 - the first day of classes....)  The heavy user traffic also causes heavier webmethods traffic.  Since the priority is user experience, the plan is to direct webmethods traffic  to one member, with an alternate member if its down, else reject the traffic.
So, I came up with this iRule.
when CLIENT_ACCEPTED {
    if { [class match [IP::client_addr] equals "TXHUB_IP"] } {                
      persist none
      ONECONNECT::reuse disable
      if { [LB::status pool ISIS-Web_SSL member 10.10.10.108 5004] ne "down" } {
        pool ISIS-Web_SSL member 10.10.10.108 5004                        
        return
      } elseif { [LB::status pool ISIS-Web_SSL member 10.10.10.110 5004] ne "down" } {
        pool ISIS-Web_SSL member 10.10.10.110 5004
        return
      } else {
        reject
        return
      }
    }
    pool ISIS-Web_SSL
}

Hopefully, I didn't make a typo...so its all like we're using.
Initially it was tested on our test stack, where we only have two servers, so its not quite a true representation (we started out with identical test and production stacks, but there was some growth of production capacity through reallocation from test.)
Anyways...same rule thrown in live on production today....didn't go so well.
We say the traffic shift to where we wanted it to go, but the webmethods admins said things weren't working right.  What was observed (both through netstat on the servers, and looking a 'b conn client  server ....' on the F5) was that there were connections going to both port 5002 and 5004.  Which is not expected and doesn't work....
Did I get something obvious wrong?  Or is there some other issue at play.... from oneconnect?
LKC

jpv_131616 · Answer

hmmmmmmmmm, ultimately what is your goal?&nbsp;
if you use both cookie and src_addr persistence the load won't be distributed evenly depending on client's (IP uniqueness, etc..).  best to use one persistence method or the other.&nbsp;
I think you can do all this with a basic VIP and correct pool config, e.g. ensure reselect option is enabled on the pool if a node goes down and you need to direct to another pool member.&nbsp;
cheers&nbsp;

iheartf5_45022 · Answer

Agree with JPV - if you use cookie and source IP you are asking for trouble - the first request of an HTTP 'session' never has a cookie,  so source IP will always be used!!
The problem is that your pool selection is being done in CLIENT_ACCEPTED,  but oneconnect means that the pool is reset to the default each time HTTP_REQUEST is triggered,  in addition, I think there is a slightly better way than your pool ISIS-Web_SSL member statements.  I would use another pool for the webmethods traffic;
pool ISIS-Web_SSL_webmethod {
    lb method member observed
    snat disable
    monitor all https1.0
    members {
        10.10.10.108:5004 {priority 3}
        10.10.10.110:5004 {priority 1}
    }
}

and then your iRule would become;
when HTTP_REQUEST {
    if { [class match [IP::client_addr] equals "TXHUB_IP"] } {                
        persist none
        pool ISIS-Web_SSL_webmethod
    }
}

iheartf5_45022 · Answer

The separate pool is purely a "I would do it this way" thing - your rule is fine - it's only the event that is causing you an issue

lkchen · Answer

On the cookie &amp; source_addr persistence, I have argued and even pointed out where in the F5 deployment guide that they keep forwarding to me, that it says in big red box to not use source addr persistence.  But, they keep wanting it put back in as the fall back.&nbsp;
It occurred to me later that maybe I was trying to do the member selection override in the wrong event.&nbsp;
I had also thought about separate pool...but worried that it'll lead to confusion for the application administrators (who have operator access to the F5) when they want to force a member down in preparation for maintenance.  But, I thnk that's what I'll try.&nbsp;
Though with a bit of change, since http profile has a redirect on failure which they don't want happening for this exception.&nbsp;

Forum Discussion

iRule to direct specific IPs to specific members, not working as expected.

4 Replies

Recent Discussions

F5 VE in Azure - troubles with Sentinel integration

Need help on i-rule to specific uri path

Stable Firmware for F5

BigIP Next - Health Monitors / Template

LDAPS and renegotiation

Related Content

Disabling Specific Weak Cipher Suites

find specific SNMP OID

Load balancing method specific decision

check the utilization on specific node

irule to Redirect client from specific Public IP to a specific node