Performance (HTTP) Profile

So I have a VIP, myvip1.company.com that is set up as a Performance HTTP VIP. I have multiple applications that point to this VIP. The VIP basically checks AD to see if an email address is valid and is used when we do not use LDAP authentication. Some apps work totally fine using this VIP, others do not and I cannot figure out why. What's not working makes no sense:

 

 

I send a call to this VIP asking if "John.Public@domain.com" is a valid email address in AD (it is) and the app comes back and says "yes, this a valid email address".

 

 

The problem is this: When a bad call is made (say, "John.Publik@domain.com" (a non-valid email address)) we get a proper response of "no, that is not a valid email address", but the very next call to the VIP asking if "John.Public@domain.com" is valid returns an answer of "no". the very next call for John.Public returns yes and continues until another bad call is made, at which time that bad call and the following good one both fail. following good calls are then successful again.

 

 

If I point this app to a test VIP with a standard TCP profile instead of performance http, this behavior is not observed--good calls return good responses, bad calls bad ones, but the bad never interfere with the good.

 

 

For reasons beyond my control, I cannot change the VIP to a standard TCP profile now. So I was hoping to create an iRule on the VIP that looked at the source address of the incoming request, and if it was coming from this app server, redirect it to a standard TCP VIP. The iRule that I put in place was this:

 

 

when HTTP_REQUEST { if { [IP::addr [IP::remote_addr] equals 10.108.31.73] } { HTTP::redirect "http://10.114.112.70.domain.com/" }}

 

 

I used the IP as I have not registered this test VIP in DNS yet.

 

 

However, when I send traffic from 10.108.31.73 to this VIP, it is not redirected to a new VIP of 10.114.112.70. Instead, it simply passes through the VIP to the node in the pool--that's problem one.

 

 

Problem two is that I cannot use this iRule on a performance http vip because a performance VIP uses a fasthttp profile instead of an http profile so the BigIP throws an error when I try to apply the iRule. So I made my test VIP a standard TCP VIP and applied the iRule but still it would not redirect to 10.114.112.70.

 

 

I'm really at a loss here. TCP dumps on the front and back side of the BigIP have not shown anything really wrong that would cause the goofy behavior, I can't simply change the VIP to a standard TCP VIP, and I'm not able to redirect from performance to standard or even from standard to standard.

 

 

Anyone experienced anything like this before?

 

 

Scott