Forum Discussion
NimbostratusHandle more than one application with one virtual server
Hello together,
our problem is that we have one VIP configured on the F5, which has currently one pool in the background. But now we configured a second pool which holds a different application, which should also handled via this VIP.
Therfore we created an iRule to hand over the traffic to the new pool when the app is called:
when HTTP_REQUEST {
if { [HTTP::uri] starts_with "/new-app" } {
pool new-app
}
}
So this is all working but the new-app is not starting each uri with "/new-app" so the idea was to add a persistance cookie or something like that to the iRule. Then when a client open the connection to /new-app and have the cookie all traffic will be forwarded to the pool to the new-app.
Is this possible? Maybe you can provide me a working iRule for this.
Thank you very much.
Cheers, Christoph
12 Replies
VernonWellsEmployee
No need for an addition to your iRule. You can simply turn on Cookie Persistence for the Virtual Server:
This would insert the cookie for all traffic, of course, but it sounds like that's what you want, anyhow.
CirrusCirrus
No that's not working as expected, because von the VIP there is a different pool configured. Therfore we created the iRule to route all traffic with /new-app to the second pool.
Do you have any other idea?
- Cirrus
No that's not working as expected, because on the VIP there is a different pool configured. Therfore we created the iRule to route all traffic with /new-app to the second pool.
But the problem is that the string "/new-app" is only appearing the first time when i start the app. Afterwards the traffic is routed again to the default pool. And here was my idea to add a persistance for "/new-app" that the traffic is still routed over the pool from the new-app and not over the default pool.
I hope this was a little bit more clear. Hope you have another idea to solve this.
No need for an addition to your iRule. You can simply turn on Cookie Persistence for the Virtual Server:
This would insert the cookie for all traffic, of course, but it sounds like that's what you want, anyhow.
- Cirrus
No that's not working as expected, because von the VIP there is a different pool configured. Therfore we created the iRule to route all traffic with /new-app to the second pool.
Do you have any other idea?
- Cirrus
No that's not working as expected, because on the VIP there is a different pool configured. Therfore we created the iRule to route all traffic with /new-app to the second pool.
But the problem is that the string "/new-app" is only appearing the first time when i start the app. Afterwards the traffic is routed again to the default pool. And here was my idea to add a persistance for "/new-app" that the traffic is still routed over the pool from the new-app and not over the default pool.
I hope this was a little bit more clear. Hope you have another idea to solve this.
- VernonWells
I'm afraid I don't follow. You can assign the cookie persistence method and continue to use the iRule you have above.
- Cirrus
Yeah i understand the configuration might be a lillte bit confusing, maybe there is a easier way. So let me give you the config from TMOS output:
This is the VIP:
ltm virtual vs_default-app { description default web app destination 193.xxx.xxx.xxx:https ip-protocol tcp mask 255.255.255.255 pool pool_default-app profiles { clientssl_default-app { context clientside } http { } serverssl-insecure-compatible { context serverside } tcp { } } rules { irule_new-web-app } source 0.0.0.0/0 source-address-translation { type automap } vs-index 15 }So this VIP has the pool default-app, now we have the situation that we should deliver a new app over the same DNS alias so let's say now it's like this https://www.default-app.com is routed to the VIP and to the default-app pool.
The new app should be access via https://www.default-app.com/new-app therfore the irule that all traffic where the uri starts with /new-app is going to the second pool (pool new-app).
But here we have the problem because we only have /new-app on the first access in the uri. And therefore i want to add a persistence to this rule.
Do you know if this is working or not? Or maybe you have a not so confusing configuration idea for me.
Thanks, Christoph
I'm afraid I don't follow. You can assign the cookie persistence method and continue to use the iRule you have above.
- Cirrus
Yeah i understand the configuration might be a lillte bit confusing, maybe there is a easier way. So let me give you the config from TMOS output:
This is the VIP:
ltm virtual vs_default-app { description default web app destination 193.xxx.xxx.xxx:https ip-protocol tcp mask 255.255.255.255 pool pool_default-app profiles { clientssl_default-app { context clientside } http { } serverssl-insecure-compatible { context serverside } tcp { } } rules { irule_new-web-app } source 0.0.0.0/0 source-address-translation { type automap } vs-index 15 }So this VIP has the pool default-app, now we have the situation that we should deliver a new app over the same DNS alias so let's say now it's like this https://www.default-app.com is routed to the VIP and to the default-app pool.
The new app should be access via https://www.default-app.com/new-app therfore the irule that all traffic where the uri starts with /new-app is going to the second pool (pool new-app).
But here we have the problem because we only have /new-app on the first access in the uri. And therefore i want to add a persistence to this rule.
Do you know if this is working or not? Or maybe you have a not so confusing configuration idea for me.
Thanks, Christoph
JGCumulonimbus
See: "sol7964: Persistence may fail for subsequent requests on Keep-Alive connections" ( https://support.f5.com/kb/en-us/solutions/public/7000/900/sol7964.html ).
- VernonWells
I follow. I was just being a bit thick about the actual thing that is persisted (the pool member, not the pool). So, you can do this:
when HTTP_REQUEST { if { [HTTP::uri] starts_with "/new-app" } { set new_app 1 pool new-app } elseif { [HTTP::cookie exists NewAppPath] } { pool new-app } } when HTTP_RESPONSE { if { [info exists NewAppPath] } { HTTP::cookie insert name NewAppPath value true path / } }You must use OneConnect or add an
for Keep-Alive values to work, as noted by somebody else above. What this does is set a second cookie -- NewAppPath -- when the first condition is met. If later that cookie is present (we don't really care about the value), then theLB::detach
pool is selected again.new-app
