i-rules and persistence

I don't see any reason why source address persistence wouldn't work. I'd say you don't need the SNAT for the 10.1.1.170 virtual as the sources and destinations are on two different subnets.

 

 

Can you elaborate on "...it is not working correctly." please.

 

 

Also, FYI, OneConnect seems to fix most persistence issues, you might want to try turning that on in the first instance before we get into more detail.

 

P.S Where do iRules come into the equation?

 

 

Not long after I posted this I realized I did not need snat on that 10.1.1.170 virtual and have turned that off. We will be testing again later.

 

 

If we turn off one of the servers in that pair the initial page loads correctly, but if we dont it loads correctly some of the time 1 in 3 maybe.

 

 

It seems like some of the requests for the page load are being sent to more than just a single server int he pair and all of them for any single page request.

 

 

So by not work I mean that sometimes the menu of tabs across the top of the page will not load correctly. I am not the application person so I only have a vague grasp of what it is really doing.

OK, so this is a web application? SSL anywhere? What's the actual application? Just so I'm clear, the persistence appears to be failing with the first Virtual Server yes?

Its a web application, SSL lands at the F5, but it stops being SSL traffic at that point. The first Virtual a customer hits is just a reverse proxy that pulls data from the Spotfire servers on port 8080 which is the 10.1.1.170 Virtual and that is what breaks right at the start.

 

 

I will also try OneConnect as you recommended.

 

It sounds like you have two tiers that you're load balancing. To do this you could use cookie insert persistence on the web VS and a UIE persistence rule on the app VS:

 

 

https://devcentral.f5.com/Community/GroupDetails/tabid/1082223/asg/50/aft/1177049/showtab/groupforums/Default.aspx1224595

 

 

I'd first try testing with one only web server and one app server enabled to make sure the rest of the logic is working and then test persistence.

 

 

Aaron

Actually, here's a more complete post:

 

https://devcentral.f5.com/Community/GroupDetails/tabid/1082223/asg/52/aft/2161049/showtab/groupforums/Default.aspx2237284

 

 

Aaron

OK, so there are three Virtual Servers? The client facing (proxy) one that lb's to 1.1 and 1.2 and terminates the SSL, then the Spotfire one (2.170), then a third (.2.171) that the Spotfire servers communicate with;

 

 

Client --> First VS --> Reverse Proxy Servers x2 --> Second VS --> Spotfire Servers x2 --> Third VS --> Servers x2

 

 

So what's the persistence method for the first VS, we've kind of missed that out? Do you actually need persistence anywhere else? Do the proxy servers open multiple connections to the Spotfire servers on behalf of a single client that's opened multiple connections to it? Same for Spotfire to whatever the last set of servers are?

I am not using any persistence on the first VS, it is not needed. I only need persistence between the reverse proxies that are behind the first VS and the second VS. I was hoping I could just use source persistence or OneConnect or even cookie persistence, but that has not worked.

 

 

I am assuming this is a persistence issue because if I shutdown either server that is behind the 2.170 VS it all works fine, but if I have them both on it works randomly.

 

 

At this point I am thinking I must use insert cookie persistence like what is in the post Hoolio linked.

 

 

 

Thanks

 

Chris

 

 

 

One last thing, the reason I have SNAT on the the 2.170 VIP is that I can not use the F5 as my Gateway and then send traffic to any of its Virtual servers so I had to change my gateway or the traffic would not get there. I am not sure why this is the case when the other VS was in the same route domain I thought it would just forward it over, but it didn't and my solution was to make its GW the core and had to turn on SNAT so it could still respond to requests through the F5

Chris,

 

 

If I understand you correctly, you're going to implement cookie persistence on the first VS yes? If so, I'd agree with that.

 

 

Ideally you need to understand how the proxies talk to the Spotfire servers when handling multiple client connections, for all you know the proxies will 'collapse' multiple client connections into a single one (a bit like OneConnect) and if so, you wouldn't need persistence between the proxies and Spotfire servers. It's a similar story for the Spotfire to the third set of servers, only in that case it might be single, short lived connections opened and closed per request or one or more longer lived connections, no persistence required in the first case, definitely required in the second.