cancel
Showing results for 
Search instead for 
Did you mean: 

iRule: Direct request to specific server, but you use pool if that server is down not working.

Richard_D
Altostratus
Altostratus

I tried to use the resources to create an iRule to force specific users (via IP) to connect to a specific server in the pool. Any other user will just hit the pool as usual which round robins. The problem is when one of the specific pool members go down and that specific user tries to connect, it does not use the pool, it appears to try and connect to the down node, therefore never connects.

 

 

Person A goes to 1.1.1.1

Person B goes to 2.2.2.2

Person C goes to 3.3.3.3

Person D goes to 4.4.4.4

Person E goes to 5.5.5.5

Person F goes to 6.6.6.6

Everyone else goes to pool and round robins

 

when CLIENT_ACCEPTED {

 if {[IP::addr [IP::client_addr] equals A.A.A.A] } {

  node 1.1.1.1 60006

 } elseif {[IP::addr [IP::client_addr] equals B.B.B.B] } {

  node 2.2.2.2 60006

 } elseif {[IP::addr [IP::client_addr] equals C.C.C.C] } {

  node 3.3.3.3 60006

 } elseif {[IP::addr [IP::client_addr] equals D.D.D.D] } {

  node 4.4.4.4 60006

 } elseif {[IP::addr [IP::client_addr] equals E.E.E.E] } {

  node 5.5.5.5 60006

 } elseif {[IP::addr [IP::client_addr] equals F.F.F.F] } {

  node 6.6.6.6 60006

 } else {

  pool SERVICE_60006_pool

 }

}

when LB_FAILED {

  pool SERVICE_60006_pool

}

1 ACCEPTED SOLUTION

MaximP
Cirrus
Cirrus

Hi Richard.

I suggest that you need to check pool member state before node choosing

 

when CLIENT_ACCEPTED {

 if {[IP::addr [IP::client_addr] equals A.A.A.A] } {

if { [LB::status pool SERVICE_60006_pool member 1.1.1.1 60006] != up } {

pool SERVICE_60006_pool

}

else {

node 1.1.1.1 60006

}

 } 

 elseif {[IP::addr [IP::client_addr] equals B.B.B.B] } {

if { [LB::status pool SERVICE_60006_pool member 2.2.2.2 60006] != up } {

pool SERVICE_60006_pool

}

  else { node 2.2.2.2 60006 

}

 }

 else {

  pool SERVICE_60006_pool

 }

}

View solution in original post

4 REPLIES 4

MaximP
Cirrus
Cirrus

Hi Richard.

I suggest that you need to check pool member state before node choosing

 

when CLIENT_ACCEPTED {

 if {[IP::addr [IP::client_addr] equals A.A.A.A] } {

if { [LB::status pool SERVICE_60006_pool member 1.1.1.1 60006] != up } {

pool SERVICE_60006_pool

}

else {

node 1.1.1.1 60006

}

 } 

 elseif {[IP::addr [IP::client_addr] equals B.B.B.B] } {

if { [LB::status pool SERVICE_60006_pool member 2.2.2.2 60006] != up } {

pool SERVICE_60006_pool

}

  else { node 2.2.2.2 60006 

}

 }

 else {

  pool SERVICE_60006_pool

 }

}

Richard_D
Altostratus
Altostratus

ok, let me try that and have end user do the testing.

Richard_D
Altostratus
Altostratus

So we went with the following in a test environment and it worked. I would prefer if its up to do something, instead of if its not up do something in your example. Only because our team is new to iRules and think my way is a little bit more clear for the casual reader. That being said your formatting and how to check the status made the difference. Thank you so much. As I type this I do see how your way is a better choice.If member is down, immediately go to the pool, instead of checking the rest of the iRule then defaulting to the available pool.

 

 

 

 

# Force A.A.A.A to go to 1.1.1.1

# Force B.B.B.B to go to 2.2.2.2

# Unless destination node is down

# All other clients will use pool

 

 

when CLIENT_ACCEPTED {

  if { ([LB::status pool SERVICE_60006_pool_pool member 1.1.1.1 60006] eq "up") && [IP::addr [IP::client_addr] equals A.A.A.A] }

   { node 1.1.1.1 60006}

  elseif { ([LB::status pool SERVICE_60006_pool_pool member 2.2.2.2 60006] eq "up") && [IP::addr [IP::client_addr] equals B.B.B.B] }

   { node 2.2.2.2 60006}  

  else {pool SERVICE_60006_pool_pool}

}

MaximP
Cirrus
Cirrus

I'm happy to help. Your way to make if statement posibble too, of course, just a matter of taste:)