Persistence across services

but we cannot use Cookie hash because the server does not use cookies

Do you mean the client (requester) doesn't support cookies? Cookie persistence doesn't rely on the back end servers supporting cookies, on the client (normally a browser).

The trick is providing some form of information that the client will relay, and that is unique. HTTP is stateless, so you don't have many options other than cookies (the easiest method), source address (if you don't have to worry about NATs), and perhaps something in the payload that is persistent and unique (ie. a sessionid that's always in the request). If you cannot support any of those methods, then it will be VERY difficult to do any kind of persistence.

Kevin,

    thanks for the answer. Regarding your question:

"Do you mean the client (requester) doesn't support cookies? Cookie persistence doesn't rely on the back end servers supporting cookies, on the client (normally a browser)"

    I mean the servers that are load balanced have a web application that does not use cookies (and it is difficult for programming people to modify the application in order to support coockies). The clients do support cookies.

    In this scenario we need to use Match across services in order to autneticate in HTTPS and use the application in HTTP.

    What do you think?

Best regards

Sergio

Persistence is a client side process. The client (browser) sends something unique in its request, and that "token" is used to persist connections to a specified server on the back end. The server has nothing to do with the cookies. So if the clients support cookies, the HTTP and HTTPS virtual servers are using the same pool, and have the same host name, you could simply assign the generic cookie persistence profile to both. The BIGipServer cookie issued to one would be valid for the other.

Kevin,

     keep in mind that we are using the same nodes but in 2 different pools (one for HTTP and one for HTTPS) becasue we are using a server ssl profile in order to finish the traffic in HTTPS.

     I will wait for your comments

Thanks and best regards

Sergio

So just to be clear, the HTTP VIP uses a pool that sends traffic to nodes listening on port 80. The HTTPS VIP uses a different pool that sends traffic to the SAME nodes listening on port 443. Is that correct? If so, then you would probably need to roll your own cookie persistence iRule. Given the stated assumption, this is what that iRule might look like:

when RULE_INIT {
    set static::key "cookiekey"
}
when HTTP_REQUEST {
    if { not ( [HTTP::cookie exists MYSITEPERSIST] ) } {
        set needcookie 1
    } else {
        set ip [HTTP::cookie decrypt MYSITEPERSIST $static::key] 
        pool local-pool-80 member $ip 80
    }
}
when HTTP_RESPONSE {
    if { [info exists needcookie] } {
        unset needcookie
        HTTP::cookie insert name MYSITEPERSIST value [LB::server addr]
        HTTP::cookie encrypt MYSITEPERSIST $static::key
    }
}

Notice the section:

set ip [HTTP::cookie decrypt MYSITEPERSIST $static::key] 
pool local-pool-80 member $ip 80

When the initial request comes in, the client doesn't have a persistence cookie, so normal load balancing happens, and the response event is told to send back the load balanced server IP address in a new encrypted cookie called "MYSITEPERSIST" (arbitrary). On subsequent requests, the client sends this cookie, which the iRule decrypts and uses in the pool command. Here I've statically set the port 80 pool name (local-pool-80) and the listening port 80. You'd have the same iRule on the HTTPS VIP but with a different pool name and different listening port. When the client contacts the HTTPS VIP, using the same host name, it sends the cookie, which the iRule decrypts and uses in the pool command.

Kevin, you understood the situation perfectly.

I tried the iRule and it worked fine.

One question that I have is what if the clients comes behind a NAT device? It will not affect the persistence? I mean, if several clients comes from behind a NAT device, they will have only one IP address. These will not be treated as one client and persist all to the same member?

Another question: how the value of the cookie is different anytime? I'm asking because we have 2 static values: the server IP and the key.

Thanks a lot for your help

Best regards

One question that I have is what if the clients comes behind a NAT device? It will not affect the persistence? I mean, if several clients comes from behind a NAT device, they will have only one IP address. These will not be treated as one client and persist all to the same member?

Source IP address isn't used in persistence here, just the cookie sent from the client.

Another question: how the value of the cookie is different anytime? I'm asking because we have 2 static values: the server IP and the key.

The key in the iRule is just an encryption passphrase. It isn't technically required, but probably better that you encrypt the cookie data so that it isn't viewable in the wild. For the sake of simplicity, you'd create two versions of this iRule - one for the HTTP VIP and one for the HTTPS VIP, where you change the name of the pool and the port number in the pool command. The key should stay the same.

Kevin, thanks a lot for your help.

I created both iRules and they works very well.

Best regards

Hi, I used the iRule created above and it works fine.

The problem is that if a node becomes down, the iRule continue sending the data to the failed node.

As we use long persistence times, the irule will continue sending the data to the failed node during a long time.

How can this issue be avoided?

Thanks and best regards

The problem is that if a node becomes down, the iRule continue sending the data to the failed node.

may you use LB::status pool to check pool member status before sending traffic to?

LB::status