Forum Discussion

som_86408's avatar
som_86408
Icon for Nimbostratus rankNimbostratus
Feb 18, 2012

source IP based persistence

Hi,

 

 

I have a requirement where clients must stick to the same server for HTTP to HTTPS and decided to use source address persistence but in a document (http://devcentral.f5.com/wiki/iRule...tence.ashx) it's written that source IP based persistence is inconsistent in load distribution across the servers. Why would it result in imbalance? Please explain.

 

 

10 Replies

  • I agree that the source you are referring to is not overly clear, i may be on the wrong track here although the only thing i can think of would be the biggest drawback of Source address persistence:

     

     

    If an address is NAT'd then in multiple connections behind this address from different connections will be load balanced to the same backend servers. Traditionally this is an issue with ISP mega proxies such as AOL, who used to route all traffic via a single IP for the obvious reasons, fortunately Mega Proxies at carrier level are not such an issue and not commonly used. theoretically 20K connections behind a megaproxy could connect to a VIP with 500 servers behind it and all be LB'd to the same server.

     

     

     

    Hope this helps.

     

     

     

    Craig

     

     

     

  • thanks, what I understand - if at the client end there is firewall/proxy which is using dynamic NAT to go outside then all the client behind this firewall/proxy will get the same NAT'd IP as source IP address when connecting to the F5 VIP and automatically directed to same backend pool member if source IP persistence is used. Please correct me if I am wrong.

     

     

    Thanks

     

    som
  • have you enabled match across option?

     

     

    sol5837: Match Across options for session persistence

     

    http://support.f5.com/kb/en-us/solutions/public/5000/800/sol5837.html
  • not done yet, planning to do as below..Is this ok? What about inconsistencies in load distribution across the servers for source ip based persistance?

    
    HTTP Virtual Server: 10.254.14.172:http 
    Type of Persistence Used: Source Address and Match Across Services enabled
    HTTP Pool Name: BKC.http_pool 
    HTTP Pool Members: 
    10.254.49.126:80 
    10.254.49.127:80 
    10.254.49.128:80
    HTTPS Virtual Server: 10.254.14.172:https
     Type of Persistence Used: Source Address Affinity and Match Across Services enabled 
    HTTPS Pool Name: BKC.http_1010_pool 
    HTTPS Pool Members: 
    10.254.49.126:1010
    10.254.49.127:1010 
    10.254.49.128:1010
    
  • planning to do as below..Is this ok?it looks ok for me.

     

     

    What about inconsistencies in load distribution across the servers for source ip based persistance?isn't it an expected behavior when using persistence??

     

     

    sol10430: Causes of uneven traffic distribution across BIG-IP pool members

     

    http://support.f5.com/kb/en-us/solutions/public/10000/400/sol10430.html
  • thanks, can you also please let me know how to use cookie persistance for same purpose (HTTP to HTTPS)?

     

     

  • can you also please let me know how to use cookie persistance for same purpose (HTTP to HTTPS)?match across option is not available in cookie persistence. thus, we have to use other persistence method such as universal persistence instead which is shown in the link you have posted.

     

     

    HTTP To HTTPS Cookie Persistence by marek.skrobacki

     

    http://devcentral.f5.com/wiki/iRules.HttpToHTTPsCookiePersistence.ashx

     

     

    do i understand your question correctly??
  • yes you are correct. I have checked the i rule but unable to understand clearly. Can I copy and paste the the below rule , will this ok? or so i need to edit anything?

     

    It'll really help me a lot!

     

     

     

    01 rule cookie_persist_http_plus_s {

     

     

    02 Check if there is a cookie and lookup persistence table

     

     

    03 if the entry does not exist, loadbalance and save record

     

     

    04 when HTTP_REQUEST {

     

     

    05 if { [HTTP::cookie exists "bIPs"] } { ------------>What is "bIPs" ?

     

     

    06 persist uie [HTTP::cookie value "bIPs"]

     

     

    07 }

     

     

    08 }

     

     

    09 For initial requests, we have to calculate MD5

     

     

    10 checksum of the server's IP, convert it to hex,

     

     

    11 then finally store it as a cookie and create persistence record

     

     

    12 when HTTP_RESPONSE {

     

     

    13 if { ![HTTP::cookie exists "bIPs"] } {

     

     

    14 binary scan [md5 [IP::server_addr]] H* md5var junk -------------> what this line will do?

     

     

    15 HTTP::cookie insert name "bIPs" value $md5var -------------> what this line will do?

     

     

    16 persist add uie [HTTP::cookie value "bIPs"]

     

     

    17 }

     

     

    18 }

     

     

    19 }

     

  • 05 if { [HTTP::cookie exists "bIPs"] } { ------------>What is "bIPs" ?it is a cookie name. you can change to whatever name you want.

     

     

    14 binary scan [md5 [IP::server_addr]] H* md5var junk -------------> what this line will do?this will create md5 checksum of pool member ip address, convert it to hex and assign it to md5var variable.

     

     

    15 HTTP::cookie insert name "bIPs" value $md5var -------------> what this line will do?this will insert cookie name "bIPs" with md5var value which will be sent to client.
  • This is really helpful; please help to understand below two lines as well.

     

     

    persist uie [HTTP::cookie value "bIPs"]

     

     

    persist add uie [HTTP::cookie value "bIPs"]