For more information regarding the security incident at F5, the actions we are taking to address it, and our ongoing efforts to protect our customers, click here.

Forum Discussion

Hartono_Tjung_1's avatar
Hartono_Tjung_1
Icon for Nimbostratus rankNimbostratus
Apr 25, 2011

Solution for persistence

Hi All,

 

 

 

 

Currently I have 4 source client (S1, S2, ...S4) and 1 VIP with 4 pool members (lets say D1,D2,..D4). Those pool members is a TCP based server.

 

Before I go to the problem, I explain the work flow first:

 

 

 

1. F5 let say will give the pool connection randomly when S1 request to VIP. Let say , S1 will get D3.

 

2. After some moments, that S1 needs to clear/delete/remove the session which is connected (This is one of the procedure that must be followed from my customer)

 

 

3. After that, S1 will again get random pool member... let say D1.

 

 

Those are the basic work flow that F5 give. But, my customer doesn't want that way. Whenever S1 server session is removed/delete , it will still get the same Pool Members D3 (exactly before the session is removed).

 

 

My customer questions are:

 

1. Is there any solution for the persistence above? I have tried Source Persistence, and Destination Persistence. But still not resolve his issues.

 

2. He ask me about "One to one mapping persistence". Is there any solution regarding that persistence? Maybe, my friends here can share me a iRule regarding that persistence?

 

 

 

 

Thanks

 

Hartono

 

config
design

7 Replies

  • JRahm's avatar
    JRahm
    Icon for Admin rankAdmin
    Apr 25, 2011
    To clarify, you want S(x) to always go to D(x) unless it's down? Or do you want S1->D1, S2->D2, S3->D3, and S4->D4? Please advise.
  • Hartono_Tjung_1's avatar
    Hartono_Tjung_1
    Icon for Nimbostratus rankNimbostratus
    Apr 26, 2011
    Posted By Jason Rahm on 04/25/2011 03:42 PM

     

    To clarify, you want S(x) to always go to D(x) unless it's down? Or do you want S1->D1, S2->D2, S3->D3, and S4->D4? Please advise.

     

    Hi Jason,

     

     

     

    I want S1->D1 , S2 ->D2, S3 ->D3 , S4 -> D4

     

     

    Thx

     

  • Steffen_Beach_8's avatar
    Steffen_Beach_8
    Icon for Nimbostratus rankNimbostratus
    Apr 26, 2011
    Are there really only 4 S, and 4 D systems, or could there be 200 S and 10 D for example?
  • Hartono_Tjung_1's avatar
    Hartono_Tjung_1
    Icon for Nimbostratus rankNimbostratus
    Apr 27, 2011
    Posted By Steffen Beach on 04/26/2011 07:39 AM

     

    Are there really only 4 S, and 4 D systems, or could there be 200 S and 10 D for example?

     

    Hi Steffen,

     

     

     

    Yes, there are only 4S and 4D. Because the S's are the front servers and D's are the backend servers.

     

     

     

     

    thx

     

  • JRahm's avatar
    JRahm
    Icon for Admin rankAdmin
    Apr 27, 2011
    Create four pools, designating one of your servers as priority in each, cascading down respectively:

    pool1 pool2 pool3 pool4

    1.1.1.1:80 pri 40 1.1.1.2:80 pri 40 1.1.1.3:80 pri 40 1.1.1.4:80 pri 40

    1.1.1.2:80 pri 30 1.1.1.3:80 pri 30 1.1.1.4:80 pri 30 1.1.1.1:80 pri 30

    1.1.1.3:80 pri 20 1.1.1.4:80 pri 20 1.1.1.1:80 pri 20 1.1.1.2:80 pri 20

    1.1.1.4:80 pri 10 1.1.1.1:80 pri 10 1.1.1.2:80 pri 10 1.1.1.3:80 pri 10

    Then, it's a simple irule:

    
when CLIENT_ACCEPTED {
  switch [IP::remote_addr] {
    "src_ip_S1" { pool pool1 }
    "src_ip_S2" { pool pool2 }
    "src_ip_S3" { pool pool3 }
    "src_ip_S4" { pool pool4 }
    default { pool default }
  }
}

    Makes sure your servers will always go to the right member as long as it's up, but will survive outages as well. HTH...Jason

  • Hartono_Tjung_1's avatar
    Hartono_Tjung_1
    Icon for Nimbostratus rankNimbostratus
    Apr 28, 2011
    Posted By Jason Rahm on 04/27/2011 12:20 PM

    Create four pools, designating one of your servers as priority in each, cascading down respectively:

    pool1 pool2 pool3 pool4

    1.1.1.1:80 pri 40 1.1.1.2:80 pri 40 1.1.1.3:80 pri 40 1.1.1.4:80 pri 40

    1.1.1.2:80 pri 30 1.1.1.3:80 pri 30 1.1.1.4:80 pri 30 1.1.1.1:80 pri 30

    1.1.1.3:80 pri 20 1.1.1.4:80 pri 20 1.1.1.1:80 pri 20 1.1.1.2:80 pri 20

    1.1.1.4:80 pri 10 1.1.1.1:80 pri 10 1.1.1.2:80 pri 10 1.1.1.3:80 pri 10

    Then, it's a simple irule:

    
when CLIENT_ACCEPTED {
  switch [IP::remote_addr] {
    "src_ip_S1" { pool pool1 }
    "src_ip_S2" { pool pool2 }
    "src_ip_S3" { pool pool3 }
    "src_ip_S4" { pool pool4 }
    default { pool default }
  }
}

    Makes sure your servers will always go to the right member as long as it's up, but will survive outages as well. HTH...Jason

    Hi Jason,

    Thanks for your great answer. But if I create this iRules. Do I need to bind those pools into the Virtual Servers?

    Let say I have created one VS with this following parameter

    VS_A_Server {

    snat automap

    pool pool1 ----> which pool from above (pool1 ....pool2 I must put into this VS?)

    destination 2.2.2.2:any

    }

    Do I need to create the VS as much as the pool number ? Or I just only create one Virtual server?

  • JRahm's avatar
    JRahm
    Icon for Admin rankAdmin
    Apr 28, 2011
    One virtual server with this iRule attached. No pool definition is required on the virtual. The default clause in the switch statement is where you'd specify the default pool if you have one, which could be p1->p4 or a separate one entirely. It is a best practice to configure a default pool on the virtual server, and it can be anything. It will be overrided by the iRule, but is a nice safety net.