Session table with Virtual Command

you are talking about the iRule table command right?

in that case i believe the session table is not connected to a single virtual server in any way, it is a global concept. what you write from one irule (virtual server) can be read by another irule (virtual server).

not sure how you believe the virtual command is related to it.

Hi, thank you for your reply.

Yes I am talking about the session table, and I am able to add a value in an iRule on one virtual server and retrive that value in another iRule on a different virtual server, but when I call the second virtual server using the virtual command on the first virtual server I am not able to retrieve the value. I am not sure that the virtual command is related but this is the only difference between when it works and when it doesn't. I can not find anything to indicate there should be any issue doing this when using the virtual command.

ah, thanks for clearing that up.

so how doesn't it work? do other iRule commands on the VS used via virtual work? is it just the lookup that doesnt work? it isn't some timing issue? that you send the traffic earlier then when the table is filled?

I can't work out why it doesn't work, all the documentation says it should work. I can look up the value in another event in the first iRule but when I try to look it up it in the second iRule its not there, its as if the first iRule stores it in a local session table and not in the global session table. I have tried using the session command, the table command and the subtable command and increasing the timeout but still no luck. I can also put the lookup in the first iRule before I actually add the value, then run the iRule again and the value is there from the previous hit. The key I am using is client IP but I have logging on to ensure that both iRules see the traffic coming from the same IP address and therefore should both be accessing the same table. It makes no sense, I can't work out why it doesn't work.

ok, did a quick test, tmos 13.1.1.4

vs1 with this irule

when HTTP_REQUEST {
 
  set srcip [IP::remote_addr]
  table add -subtable "blacklist" $srcip "blocked" 360 360
 
  log -noname local0.info "send to virtual vs-test-02"
  virtual /Common/vs-test-brt-02
 
}

then vs-test-02 with this irule

when HTTP_REQUEST {
 
    set srcip [IP::remote_addr]
    set result [table lookup -subtable "blacklist" $srcip]
    log -noname local0.info "result is $result"
 
}

and this works for me

Oct 14 09:44:59 bigip1 info tmm[21812]: send to virtual vs-test-02
Oct 14 09:44:59 bigip1 info tmm[21812]: result is blocked

is your situation (very) different then this?

Hi, thank you for your code above, the only difference is that I am not using HTTP, the flow I have is for FTPS so I am adding the info to the table in CLIENT_ACCEPTED in the first iRule then retrieving it in CLIENT_ACCEPTED in the second iRule, and I don't call the second VIP in client accepted, it is in CLIENT_DATA. I have also tried to add the data to the table in CLIENT_ACCEPTED but this did not work either. I pasted your config into my both iRules under CLIENT_DATA of both iRules, I also put the logging into both iRules and as you can see from the output below I am able to get the data from within the iRule that put it in the table but not from the second iRule.

iRule 1

Oct 14 21:47:25 ip-10-0-0-200 info tmm[9777]: send to virtual vs-test-02

Oct 14 21:47:25 ip-10-0-0-200 info tmm[9777]: result is blocked

iRule 2

Oct 14 21:47:25 ip-10-0-0-200 info tmm[9777]: result is 

I am using AWS F5 BIG-IP Virtual Edition instances, I don't know if this is what is causing the issue as everything I have read says it should work, and as you displayed above it is clearly working for you.

not meant unkind but it helps if you explain the full situation at the start. things like the iRule events can matter in cases like this. the environment (AWS in your case) might also be related, i don't expect it, but it is good to know in general.

so i moved my previous setup to one closer to yours, please let me know the difference if there are any left.

iRule on VS1

when CLIENT_ACCEPTED {
 
  set srcip [IP::remote_addr]
  log -noname local0.info "CLIENT_ACCEPTED put $srcip with value blocked in blacklist subtable"
  table add -subtable "blacklist" $srcip "blocked" 360 360
  log -noname local0.info "CLIENT_ACCEPTED collect 15 bytes of data"
  TCP::collect 15
 
}
 
when CLIENT_DATA {
  log -noname local0.info "CLIENT_DATA     found client data"
  
  log -noname local0.info "CLIENT_DATA     send to virtual vs-test-02"
  virtual /Common/vs-test-02  
}

iRule on vs-test-02

when CLIENT_ACCEPTED {
 
    set srcip [IP::remote_addr]
    set result [table lookup -subtable "blacklist" $srcip]
    log -noname local0.info "CLIENT_ACCEPTED result for $srcip is $result."
 
}

and this works

Oct 15 09:34:19 bigip-01 info tmm[21812]: CLIENT_ACCEPTED put 192.168.64.191 with value blocked in blacklist subtable
Oct 15 09:34:19 bigip-01 info tmm[21812]: CLIENT_ACCEPTED collect 15 bytes of data
Oct 15 09:34:19 bigip-01 info tmm[21812]: CLIENT_DATA     found client data
Oct 15 09:34:19 bigip-01 info tmm[21812]: CLIENT_DATA     send to virtual vs-test-02
 
Oct 15 09:34:19 bigip-01 info tmm[21812]: CLIENT_ACCEPTED result for 192.168.64.191 is blocked.

i did some tests with the TCP::collect with bigger numbers of minimum bytes and i had once it didn't work, the lookup failed. but im unable to reproduce that. the collect which triggers a new event makes me a little worried, but then again, if you use the virtual in that _DATA event it shouldn't matter, but still is that choice required there?

im very interested in how your iRule looks (if possible to share more after cleanup of any internal only details) to see if a cause can be found there. but so far this works.

oh and if you haven't raise a ticket with F5 support, this is getting to the point where it indeed might be an internal things.

Hi, apologies for not giving enough information relating to this, and thank you for your help.

I tried your solution above but had to remove the 15 from TCP::collect as it would not work with that, I tried some larger numbers but that didn't work either. I am unable to put the config on now as I have to get it cleaned and approved before putting it up. I should hopefully be able to add it tomorrow. The value I am trying to add will actually be added under the CLIENTSSL_CLIENTCERT event but as this would not work I had moved it to CLIENT_ACCEPTED just to eliminate any race conditions that may have been occurring.

The main aim of what I'm trying to do is to get a value I pull from a certificate in iRule one into the session table so I can retrieve it in iRule 2. I have tried numerous times to raise a ticket with F5 but I have not had any reply and no pending tickets show tracked tickets.

The output is below from F5

iRule 1

Oct 15 20:04:28 ip-10-0-0-200 info tmm[9787]: CLIENT_ACCEPTED put 10.0.0.10 with value blocked in blacklist subtable

Oct 15 20:04:28 ip-10-0-0-200 info tmm[9787]: CLIENT_ACCEPTED collect 15 bytes of data

Oct 15 20:04:28 ip-10-0-0-200 info tmm[9787]: CLIENT_DATA  found client data

Oct 15 20:04:28 ip-10-0-0-200 info tmm[9787]: CLIENT_DATA  send to virtual vs-test-02

Oct 15 20:04:28 ip-10-0-0-200 info tmm[9787]: send to virtual vs-test-02

Oct 15 20:04:28 ip-10-0-0-200 info tmm[9787]: result is blocked

iRule 2

Oct 15 20:04:28 ip-10-0-0-200 info tmm[9787]: CLIENT_ACCEPTED result for 10.0.0.10 is .

The AWS image is F5 BIG-IP Virtual Edition - GOOD (PAYG, 200Mbps). I logged a ticket on the F5 Support page, raise a service request. I will put the cleaned config up tomorrow

You're right, small data pckts because of ftp-control.

Below is the first iRule calling the second. And then the log. I'd be very interested to see what you think might be happening.

The log lookup of both the STRING value and the $var value on the second virtual server does not work, despite occurring later in time than when they are put in the tables. It seems like they are saved to different tables, or that, the table is somehow reset before the lookup. The IP::client_addr is the same on both virtual servers, so the key is consistent - at least, that's what the log says. When the key is set as a string, it doesn't work either.

iRule 1
 
when CLIENT_ACCEPTED {
   log local0.debug "client accepted VS1"
   log local0.debug "New TCP connection from [IP::client_addr]:[TCP::client_port] to [IP::local_addr]:[TCP::local_port]"
   SSL::disable
   TCP::respond "220 My ftp server\r\n"
   TCP::collect 10
 
}
when CLIENT_DATA {
   log local0.debug "client data VS1"
   log local0.debug "[TCP::payload] is the payload VS1"
   log local0.debug "New TCP connection from [IP::client_addr]:[TCP::client_port] to [IP::local_addr]:[TCP::local_port]"
   TCP::respond "234 AUTH TLS Successful\r\n"
   TCP::payload replace 0 [TCP::payload length] ""
   log local0.debug "[TCP::payload] is the payload (should be empty) VS1"
   log -noname local0.info "CLIENT_DATA     found client data"
   log -noname local0.info "CLIENT_DATA     send to virtual vs-test-02"
   virtual /Common/VIP2
   SSL::enable
   TCP::release
   log local0.debug "TCP Release Completed VS1"
}
when SERVER_CONNECTED {
    log local0.debug "This is server connected event VS1"
    log local0.debug "New TCP connection from [IP::client_addr]:[TCP::client_port] to [IP::local_addr]:[TCP::local_port]"
	TCP::collect
}
when SERVER_DATA {
  log local0.debug "this is server data event VS1"
  log local0.debug "[TCP::payload] payload from server VS1"
  log local0.debug "New TCP connection from [IP::client_addr]:[TCP::client_port] to [IP::local_addr]:[TCP::local_port]"
  if { [TCP::payload] contains "220 " } {
    TCP::payload replace 0 [TCP::payload length] ""
    log local0.debug "[TCP::payload] (empty) payload line (server data event line 27) on VS1"
  }
  TCP::release
  TCP::collect
}
when CLIENTSSL_CLIENTHELLO {
   log local0. "This is clientssl_clienthello - VS1"
}
when CLIENTSSL_CLIENTCERT {
  log local0. "This is clientssl_clientcert - VS1"
  set sidc [SSL::sessionid]
  log local0. "CLIENTSSL session ID is $sidc"
 
   set myCount [SSL::cert count]
   log local0. "Count of certificates is $myCount"
 
   set client_cert [SSL::cert 0]
 
<<EXTRACT CERT VALUE in $var local variable>>
   
   log local0. "this is VAR value $var"
   set srcip [IP::client_addr]
   table add -subtable "blacklist" $srcip "$var" 5 5
   log -noname local0.info "send to virtual vs-test-02"
   set result [table lookup -subtable "blacklist" $srcip]
   log -noname local0.info "result is $result"
    }
 
when CLIENTSSL_HANDSHAKE {
   log local0. "This is clientssl_handshake - VS1"
}
 when CLIENT_CLOSED {
  log local0.debug "Closed TCP connection from [IP::client_addr]:[TCP::client_port] to [IP::local_addr]:[TCP::local_port]"
 
   }

iRule 2
 
when CLIENT_ACCEPTED {
   log local0.debug "client accepted VS2"
   log local0.debug "New TCP connection from [IP::client_addr]:[TCP::client_port] to [IP::local_addr]:[TCP::local_port]"
   TCP::release
   TCP::collect
}
when CLIENT_DATA {
  log local0.debug "[TCP::payload] VS2 client data event"
  log local0. "This is client data"
  log local0.debug [TCP::payload]
  log local0.debug "This is line 29"
  TCP::release
  TCP::collect
}   
when SERVER_CONNECTED {
  log local0.debug "VS2 server connected event - on inner F5 this is connection to FTP server"
  log local0.debug "New TCP connection from [IP::client_addr]:[TCP::client_port] to [IP::local_addr]:[TCP::local_port]"
  TCP::collect
}
when SERVER_DATA {
   log local0.debug "[TCP::payload] server data event VS2"
   TCP::release
   TCP::collect
}
when SERVERSSL_CLIENTHELLO_SEND {
   log local0. "This is SERVERSSL_CLIENTHELLO_SEND - VS2"
   TCP::collect
   TCP::release
}
when SERVERSSL_SERVERCERT {
   log local0. "This is SERVERSSL_SERVERCERT - VS2"
   set srcip [IP::client_addr]
   set result [table lookup -subtable "blacklist" $srcip]
   log -noname local0.info "SERVERSSL_SERVERCERT result for $srcip is $result."
   TCP::respond "VAR_$result\r\n"
   
}
when SERVERSSL_SERVERHELLO {
   log local0. "This is SERVERSSL_SERVERHELLO - VS2"
   
}
when SERVERSSL_HANDSHAKE {
   log local0. "This is SERVERSSL_HANDSHAKE - VS2"
  }
when SERVERSSL_DATA {
   log local0. "This is SERVERSSL_DATA - VS2"
   }