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

Sheila_Liu_8576's avatar
Sheila_Liu_8576
Icon for Nimbostratus rankNimbostratus
Mar 17, 2006

picking a pool member with source_addr persistence

Working on the following irule, no luck so far

 

the requirement is that when http request comes in, if the request is made by any poop member, connection should go back to the requsting member, there are two members in the pool.

 

 

If http request comes from user, use source_addr persistence.

 

 

I'm seeing request from poop memebrs not going to itself but also in /var/log/ltm, I do see the irule being hit.

 

 

Please help.

 

 

when HTTP_REQUEST {

 

if { [IP::addr [IP::client_addr] equals 172.19.10.70] } {

 

pool LMS-lms.lnh.bislab.pwj.com.80 member 172.19.10.70

 

log "hit member 172.19.10.70"

 

} elseif { [IP::addr [IP::client_addr] equals 162.66.195.95] } {

 

pool LMS-lms.lnh.bislab.pwj.com.80 member 162.66.195.95

 

log "hit member 162.66.195.95"

 

} else {

 

pool LMS-lms.lnh.bislab.pwj.com.80

 

persist source_addr 10800

 

log "hit pool"

 

}

 

}
application delivery
dev
devops
iRules

8 Replies

  • JRahm's avatar
    JRahm
    Icon for Admin rankAdmin
    Mar 17, 2006
    I'm confused...the server's in the pool need to request something of themselves? Perhaps a greater picture of what you are trying to accomplish would be helpful.
  • Sheila_Liu_8576's avatar
    Sheila_Liu_8576
    Icon for Nimbostratus rankNimbostratus
    Mar 17, 2006
    unfortunately, yes. The servers are calling themselves.

     

     

    This is due to a limitation in an application called saba. Saba referes to the URL even when the request is coming from the server itself. The idea in Saba was that the server can call contents anywhere using a URL, not limited to its own contents.
  • JRahm's avatar
    JRahm
    Icon for Admin rankAdmin
    Mar 17, 2006
    You could try this:

    
when CLIENT_ACCEPTED {
  if { [IP::addr [IP::client_addr] equals 172.19.10.70] } {
    use snat snat_a_IP
  } elseif { [IP::addr [IP::client_addr] equals 162.66.195.95] } {
      use snat snat_b_IP
  }
}
when HTTP_REQUEST {
  if { [IP::addr [IP::client_addr] equals snat_a_IP] } {
    pool LMS-lms.lnh.bislab.pwj.com.80 member 172.19.10.70
    log "hit member 172.19.10.70"
  } elseif { [IP::addr [IP::client_addr] equals snat_b_IP] } {
      pool LMS-lms.lnh.bislab.pwj.com.80 member 162.66.195.95
      log "hit member 162.66.195.95"
  } else {
      pool LMS-lms.lnh.bislab.pwj.com.80
      persist source_addr 10800
      log "hit pool"
  }
}

    This, of course, is assuming the client IP is snatted before the HTTP_REQUEST event occurs. Not tested!
  • Sheila_Liu_8576's avatar
    Sheila_Liu_8576
    Icon for Nimbostratus rankNimbostratus
    Mar 17, 2006
    looks like I hit a bug. If I create a pool with only the server in it, then I refer to this pool instead of a pool member, it works.

     

     

    anyone had seen this behavior before?
  • Sheila_Liu_8576's avatar
    Sheila_Liu_8576
    Icon for Nimbostratus rankNimbostratus
    Mar 17, 2006
    Thanks for your reply. The workaround makes sense but somehow it's not working for me. see below client 172.19.10.70 not going to itself

     

     

    [root@LB-6400-LH-BISLAB-1:Active] config b conn client 172.19.10.70 show all

     

    VIRTUAL 162.66.65.141:http <-> NODE 162.66.195.95:http

     

    CLIENTSIDE 172.19.10.70:48783 <-> 162.66.65.141:http

     

    (pkts,bits) in = (5, 6992), out = (3, 1360)

     

    SERVERSIDE 162.66.65.2:48783 <-> 162.66.195.95:http

     

    (pkts,bits) in = (3, 1392), out = (4, 6592)

     

    PROTOCOL tcp UNIT 1 IDLE 0 (300) LASTHOP 4093 00:30:96:b0:e4:00