soudce address persistency

This sounds like an iRule post then iControl post. Next time please post in iRule otherwise your question would have been overlooked.

 

 

 

I think the most efficient way is to to create an irule that uses the crc32 checksum against the [IP::client_addr] and do a modulo against the result to see if it's odd or even. Then basically drive the odds over to pool member 1 and evens over to pool member2.

 

 

 

Hope that helps?

 

 

CB

 

 

 

 

Thanks for you quick response

 

 

I just gave an example.

 

In reality I'll have much more than 2 pool members (more like 20-50)

 

As long as the same source IP always goes to the same pool member its good (I dont care about specific mapping. like 172.17.1.1 doesnt have to go to member1. it can go to member17 as long as it will ALWAYS go to member17)

 

 

I used "source_addr" persistence. edited the profile and changed the default timeout from "180" to "indefinite" and it seems to do the job

 

however it stored each and every record in the persistency table forever. if I'll have a lot of source IPs wouldn't it overload the device?

 

 

In Alteon I just use "metric hash" and even if the session was aged out, next time a packet comes from the same source IP it will be sent to the same pool member (guess it uses MD5)

 

define each and every pool member with its MOD result is going to be ugly. especially when I add new servers

 

 

 

b persist show all

 

| Mode source addr Value 172.17.1.1

 

| virtual any:http node 172.17.3.102:any age 1494sec

 

| Mode source addr Value 172.17.1.4

 

| virtual any:http node 172.17.3.102:any age 3313sec

 

| Mode source addr Value 172.17.1.7

 

| virtual any:http node 172.17.3.101:any age 3018sec

 

| Mode source addr Value 172.17.1.3

 

| virtual any:http node 172.17.3.102:any age 3494sec

 

| Mode source addr Value 172.17.1.6

 

| virtual any:http node 172.17.3.102:any age 3154sec

 

| Mode source addr Value 172.17.1.9

 

| virtual any:http node 172.17.3.101:any age 3277sec

 

| Mode source addr Value 172.17.1.2

 

| virtual any:http node 172.17.3.101:any age 3216sec

 

| Mode source addr Value 172.17.1.5

 

| virtual any:http node 172.17.3.101:any age 3104sec

 

| Mode source addr Value 172.17.1.8

 

| virtual any:http node 172.17.3.102:any age 2927sec

Setting the time out in Source Address (SAA) to indefinite will create a large table over time as you pointed out and lead to overload if you know you are going to have a large list of addresses. You can mitigate some by setting the mask to coverage a large range, but ultimately I think it's going to inefficient.

As I mentioned you could use a CRC32 with modulo to gain the same type of effect.

I.E.

  
 when HTTP_REQUEST {  
 set poolnum [crc32 [IP::client_addr]]  
  The following takes poolnum variable, divides it by 4 and assigns the remainder to poolnum.   
  This will result in the following answers 0,1,2,3.  If you divded by 5 then it's 0,1,2,3,4, etc,.  
  4 is equal to the total  of nodes in pool_member.  
  If a node is added then you must increment by N number of nodes that were added.    
  I.E., if 2 nodes are added then 4 + 2 = 6.  
 set poolnum [expr $poolnum % 4 ]  
 switch $poolnum {  
 0 { pool pool_member member 192.168.8.1 80 }  
 1 { pool pool_member member 192.168.8.2 80 }  
 2 { pool pool_member member 192.168.8.3 80 }  
 3 { pool pool_member member 192.168.8.4 80 }  
 }  
 }  
  Triggered when the selected members fails in the selected pool, all connections on the failed node will be forced to re participate in load balancing during the failed event.  Otherwise it will return back  
 when LB_FAILED {   
 pool pool_members  
 persist source_addr 1800   This allow you stick to a specific host for x amount of time until the member comes back up.  
 LB::reselect  
 }  
 

I hope this helps

CB