Forum Discussion

Chris_Hotchkiss's avatar
Chris_Hotchkiss
Icon for Nimbostratus rankNimbostratus
Nov 12, 2010

Maintaining Same Session between 2 servers

Bear with me. Very new to this. Hope I am able to explain issue well enough.

 

 

We are running iplanet web servers using netegrity for authentication. The ltm is performing all the ssl functions.

 

 

We are bringing up another web server-iis- that is going to be used for a particular function. This function will be called upon by users who are signed into the iplanet web servers.

 

 

When a user is signed into the iplanet webserver and has an active ssl session, we want him to have the ability to click on a link that will go to the iis server yet maintain the same session, and then be able to return to the iplanet if neccessary.

 

 

Can an irule accomplish this and if so, could you provide the framework or point me in the right direction if this has been requested before?

 

 

Thank you.

3 Replies

  • Hi Chris,

    It sounds like you could use an iRule which selects either the iPlanet pool or IIS pool based on the requested URI. You could set two different persistence cookies to ensure clients are persisted back to the same pool member.

    
    when HTTP_REQUEST {
    
        Check the requested URI
       switch -glob [HTTP::uri] {
          "/path1/* -
          "/path2/* {
              Request was for an IIS URI so select the pool and set a pool-specific cookie
             pool iis_pool
     persist cookie insert iis_persist 0
          }
          default {
              Request was for an iPlanet URI so select the pool and set a pool-specific cookie
             pool iplanet_pool
     persist cookie insert iplanet_persist 0
          }
       }
    }
    

    Or you could use the default cookie insert profile with no custom name specified and then remove the persist commands from the iRule. LTM will handle the persistence automatically for you.

    Make sure to use a OneConnect profile with cookie persistence or URI-based pool switching to ensure each HTTP request is parsed and load balanced/persisted to the correct pool and pool member. If you're using SNAT you can use the default OneConnect profile. If you're not using SNAT, then you can use a custom OneConnect profile with the source mask set to 255.255.255.255. This ensures that serverside connections are only re-used for one client IP and that the server logs accurately reflect the client IP address.

    Aaron
  • Thanks Aaron. After some trial and error I was able to get things working like we wanted with a combination that was kind of similar to what you explained. Thank you for the response.
  • Hi Chris,

     

     

    If you get a chance, could you post an anonymized copy of your rule for future reference?

     

     

    Thanks, Aaron