Forum Discussion

Ted_Smith_11168's avatar
Ted_Smith_11168
Icon for Nimbostratus rankNimbostratus
Feb 27, 2006

seeing multiple app sessions from iRules?

This might be a long post, so please forgive me...

 

 

using a wide IP in 3DNS for aac.alliedinsurance.com

 

When a user comes into the aac.alliedinsurance.com site, I want to redirect them to aac2.alliedinsurance.com site (which is not a wide IP)

 

 

Setup:

 

 

1st iRule tied to aac.alliedinsurance.com on port 80:

 

agentcenter-80-redirect-443

 

when HTTP_REQUEST {

 

if { [HTTP::uri] starts_with "/plquoting/templates/receiveincomingfile.cfm" } {

 

HTTP::uri "/PersonalLines/Templates/receiveincomingfile.cfm"

 

}

 

else {

 

HTTP::redirect https://[HTTP::host][HTTP::uri]

 

}

 

}

 

 

Purpose of rule, match specific uri on port 80, otherwise re-direct to https

 

 

 

 

2nd iRule tied to aac.alliedinsurance.com on port 443

 

agentcenter-443-redirect-aac2

 

when CLIENT_ACCEPTED {

 

set ckname aac2

 

set ckvalue [IP::client_addr]

 

set ckdomain .alliedinsurance.com

 

set cookie [format "%s=%s; path=/; domain=%s" $ckname $ckvalue $ckdomain]

 

}

 

when HTTP_REQUEST {

 

set uri [HTTP::uri]

 

}

 

when HTTP_RESPONSE {

 

HTTP::respond 302 Location "https://aac2.alliedinsurance.com$uri" "Set-Cookie" $cookie

 

}

 

Purpose of rule, set cookie info, redirect to aac2.alliedinsurance.com

 

 

 

3rd iRule tied to aac2.alliedinsurance.com on port 443

 

aac2.alliedinsurance.com

 

when CLIENT_ACCEPTED {

 

set ckname aac2

 

set ckvalue [IP::client_addr]

 

set ckdomain .alliedinsurance.com

 

}

 

when HTTP_REQUEST {

 

set uri [HTTP::uri]

 

set host [HTTP::host]

 

set new_uri /center/templates/welcome.cfm

 

set new_url $host$new_uri

 

if {[HTTP::cookie exists $ckname]} {

 

if { $uri contains "agencyctr" } {

 

HTTP::redirect https://$new_url

 

} else {

 

pool Shared

 

}

 

} else {

 

HTTP::redirect "https://aac.alliedinsurance.com$uri"

 

}

 

}

 

 

Purpose of rule, check for cookie set in 2nd rule, allow user to site. If cookie not present redirect to aac.alliedinsurance.com:443 to set cookie.

 

 

Problem: During loadtesting developers are telling me that 2 application sessions are being set one one user accesses the site.

 

 

My fear is that on the first or second rule, the bigip is allowing the client back to the app server (which would set the session). My understanding is that the bigip should only allow client through to app server if iRule conditions are met.

 

 

Am I understanding this correctly or do I have a problem with my iRule logic. I have some network traces done, but ssl makes it hard (impossible) to see details. There is a lot of complexity here and I don't know if I have done a good job of explaining everything.

 

 

Please ask questions if something is not clear. I've got to get some hard answers back to developers.

 

 

Thanks,

 

 

Ted Smith

 

Allied Insurance
application delivery
dev
devops
iRules

9 Replies

Sort By
  • JRahm's avatar
    JRahm
    Icon for Admin rankAdmin
    Feb 27, 2006
    If your server folks will give you the ssl key, you can use ssldump on your tcpdump captures. The executable is available on the BigIP system. The syntax I use:

     

     

    ssldump -Ad -r -k >

     

     

     

  • Ted_Smith_11168's avatar
    Ted_Smith_11168
    Icon for Nimbostratus rankNimbostratus
    Feb 28, 2006
    Ya, I am trying to convice powers that be to give me SSL info with password so I can see more details.

     

     

    Appreciate the specific syntax.

     

     

    More to the point though, If irule 1 is run against an incoming connection, it shouldn't make it past the bigip unless it matches the uri syntax compare.

     

     

    Same with iRule2... shoudl set cookie and re-direct client. Packet should not be passed to the defined pool.

     

     

    Is my assumption correct, or do I have something mis-configured?

     

     

    Thanks for any help
  • JRahm's avatar
    JRahm
    Icon for Admin rankAdmin
    Feb 28, 2006
    In the third rule, it looks like this will never be matched:

    if {[HTTP::cookie exists $ckname]} {

    if { $uri contains "agencyctr" } {

    HTTP::redirect https://$new_url

    }

    because you are setting ckname to aac2 directly above it. I'd remove this:

    when CLIENT_ACCEPTED {

    set ckname aac2

    set ckvalue [IP::client_addr]

    set ckdomain .alliedinsurance.com

    }

    from your third rule since the first line appears to overwrites the information you want out of the 2nd rule and the next two lines aren't used. I'd also recommend not setting variables unless you will use them frequently. If I were to rewrite your third rule, I'd do something like this:

    
when HTTP_REQUEST {
  if {[HTTP::cookie exists "aac2"]} {
    if { [HTTP::uri] contains "agencyctr" } {
      HTTP::redirect https://[HTTP::host]/center/templates/welcome.cfm
    } else { use pool Shared }
  } else { HTTP::redirect https://aac.alliedinsurance.com[HTTP::uri] }
}

    HTH

  • JRahm's avatar
    JRahm
    Icon for Admin rankAdmin
    Feb 28, 2006
    Hmm, not thinking straight, you're just looking for the cookie name, so that should work. I've updated the post to look for the cookie name without the variable. I'd add some logging throughout all the rules to see if you can find where the ball is being dropped.
  • Colin_Walker_12's avatar
    Colin_Walker_12
    Historic F5 Account
    Feb 28, 2006
    Well, looking at your second rule, it looks as though you have it configured to forward the traffic to teh application servers (or whatever is configured as the default pool for that VIP).

     

     

    Since the rule allows the connection through after setting the HTTP::uri on the HTTP_REQUEST event, the server is seeing the traffic and responding, which is how you're able to use the HTTP_RESPONSE event to set the cookie and send the client the 302 redirect.

     

     

    Then again in the third rule, you're redirecting people to the same host, with a specific URI.

     

     

    It sounds like a successful request would hit the servers behind your BIG-IP twice on a normal pass through this series of rules. Is this your intended setup?

     

     

    -Colin
  • Ted_Smith_11168's avatar
    Ted_Smith_11168
    Icon for Nimbostratus rankNimbostratus
    Feb 28, 2006
    Thanks again for your help. I'll do some editing to remove some of the variables. I inherited these a while ago and thought they were needed. I think I just mis-understood how to best use information already available from the client headers.

     

     

    Did I mention that I am not a coder :-)

     

     

    in rule 2 I re-direct the client and set a cookie:

     

     

    when HTTP_RESPONSE {

     

    HTTP::respond 302 Location "https://aac2.alliedinsurance.com$uri" "Set-Cookie" $cookie

     

    }

     

     

    Is this command different than using the:

     

    HTTP::redirect command?

     

    can cookie info be set the same way? Is one better than the other?

     

     

    Thanks!!
  • Ted_Smith_11168's avatar
    Ted_Smith_11168
    Icon for Nimbostratus rankNimbostratus
    Feb 28, 2006
    Colin,

     

     

    Thanks for the reply!

     

     

    Just to make sure I am referencing same rule, this is rule 2

     

     

    when CLIENT_ACCEPTED {

     

    set ckname aac2

     

    set ckvalue [IP::client_addr]

     

    set ckdomain .alliedinsurance.com

     

    set cookie [format "%s=%s; path=/; domain=%s" $ckname $ckvalue $ckdomain]

     

    }

     

    when HTTP_REQUEST {

     

    set uri [HTTP::uri]

     

    }

     

    when HTTP_RESPONSE {

     

    HTTP::respond 302 Location "https://aac2.alliedinsurance.com$uri" "Set-Cookie" $cookie

     

    }

     

     

    I've stared at this so long, I looked right past the most obvious cause!

     

    No, with this rule, I do not want the client being passed to the defined pool. Can I simply move the http::respond command to the HTTP_REQUEST section or do I need to use an HTTP::redirect command is there a difference?

     

     

    Looking at rule3 do I need:

     

    when CLIENT_ACCEPTED {

     

    set ckname aac2

     

    set ckvalue [IP::client_addr]

     

    set ckdomain .alliedinsurance.com

     

     

    When the cookie was set in rule2

     

     

    My oringial intent was to bring a user into rule2, set the cookie, redirect to rule3. In rule 3 verify that cookie has been set by rule 2. If cookie not set, go back to rule2 and set cookie.

     

     

    Thanks again for your help. You guys are the greatest!

     

     

  • Ted_Smith_11168's avatar
    Ted_Smith_11168
    Icon for Nimbostratus rankNimbostratus
    Mar 01, 2006
    OK, I modified my iRules and I am still seeing multiple sessions being created in my App servers.

     

     

    Here are my altered irules:

     

     

    UITAAC port 80 VIP RULE 1

     

    when HTTP_REQUEST {

     

    if { [HTTP::uri] starts_with "/plquoting/templates/receiveincomingfile.cfm" } {

     

    HTTP::uri "/PersonalLines/Templates/receiveincomingfile.cfm"

     

    }

     

    elseif { [HTTP::host] == "uitaac.allied.nwie.net" or [HTTP::host] == "uitaac"} {

     

    HTTP::redirect https://[HTTP::host][HTTP::uri]

     

    }

     

    }

     

     

    UITAAC port 443 VIP RULE 2

     

     

    when CLIENT_ACCEPTED {

     

    set ckname uitaac1

     

    set ckvalue [IP::client_addr]

     

    set ckdomain .allied.nwie.net

     

    set cookie [format "%s=%s; path=/; domain=%s" $ckname $ckvalue $ckdomain]

     

    }

     

    when HTTP_REQUEST {

     

    log "rule 2 incoming cookie is: [HTTP::cookie names]"

     

    HTTP::respond 302 Location "https://uitaac1.allied.nwie.net[HTTP::uri]" "Set-Cookie" $cookie

     

    }

     

     

    UITAAC1 port 443 VIP RULE 3

     

     

    when HTTP_REQUEST {

     

    log "rule 3 incoming cookie is: [HTTP::cookie names]"

     

    if {[HTTP::cookie exists "uitaac1"]} {

     

    pool UITShared

     

    }

     

    else {

     

    HTTP::redirect "https://uitaac.allied.nwie.net[HTTP::uri]"

     

    }

     

    }

     

     

    If the user uses http://uitaac.allied.nwie.net, app server only issues 1 session

     

     

    If user uses https://uitaac.allied.nwie.net, the app server issues 2 sessions.

     

     

    I can't see why there is a difference since rule1 redirects the user to rule2.

     

     

    Any ideas/help??