Is anyone able to tell me if you can store data in the session table using an iRule on one VS then recover it on a second VS, if the second VS is called via the virtual command in an iRule on the first VS. I can recover data from the session table added by a separate VS but not the data added by the first VS, the one that calls the second VS.

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.4vs1 with this irulewhen 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 irulewhen 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 meOct 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 blockedis your situation (very) different then this?

Session table with Virtual Command

F5-Hopeful

Nimbostratus

Oct 16, 2019

This is th

Log
 
Oct 16 16:22:31 ip-10-0-0-200 debug tmm1[9810]: Rule /Common/CLIENT_PROFILE <CLIENT_ACCEPTED>: client accepted VS1 on irule CLIENT_PROFILE
Oct 16 16:22:31 ip-10-0-0-200 info tmm1[9810]: Rule /Common/CLIENT_PROFILE <CLIENT_ACCEPTED>: This is irule CLIENT PROFILE. FTPS_CLIENT1 10.0.1.85
Oct 16 16:22:31 ip-10-0-0-200 debug tmm1[9810]: Rule /Common/VIP_1 <CLIENT_ACCEPTED>: client accepted VS1
Oct 16 16:22:31 ip-10-0-0-200 debug tmm1[9810]: Rule /Common/VIP_1 <CLIENT_ACCEPTED>: New TCP connection from 10.0.1.85:56112 to 10.0.1.50:21
Oct 16 16:22:31 ip-10-0-0-200 debug tmm1[9810]: Rule /Common/VIP_1 <CLIENT_DATA>: client data VS1
Oct 16 16:22:31 ip-10-0-0-200 debug tmm1[9810]: Rule /Common/VIP_1 <CLIENT_DATA>: AUTH TLS   is the payload VS1
Oct 16 16:22:31 ip-10-0-0-200 debug tmm1[9810]: Rule /Common/VIP_1 <CLIENT_DATA>: New TCP connection from 10.0.1.85:56112 to 10.0.1.50:21
Oct 16 16:22:31 ip-10-0-0-200 debug tmm1[9810]: Rule /Common/VIP_1 <CLIENT_DATA>:  is the payload (should be empty) VS1
Oct 16 16:22:31 ip-10-0-0-200 info tmm1[9810]: CLIENT_DATA     found client data
Oct 16 16:22:31 ip-10-0-0-200 info tmm1[9810]: CLIENT_DATA     send to virtual vs-test-02
Oct 16 16:22:31 ip-10-0-0-200 debug tmm1[9810]: Rule /Common/VIP_1 <CLIENT_DATA>: TCP Release Completed VS1
Oct 16 16:22:31 ip-10-0-0-200 info tmm1[9810]: Rule /Common/VIP_1 <CLIENTSSL_CLIENTHELLO>: This is clientssl_clienthello - VS1
Oct 16 16:22:31 ip-10-0-0-200 info tmm1[9810]: Rule /Common/VIP_1 <CLIENTSSL_CLIENTCERT>: This is clientssl_clientcert - VS1
Oct 16 16:22:31 ip-10-0-0-200 info tmm1[9810]: Rule /Common/VIP_1 <CLIENTSSL_CLIENTCERT>: CLIENTSSL session ID is d531cee3d86573361dd958caa18c7b9f807e1e788d4a42cc6a6bc0c731dc8b6e
Oct 16 16:22:31 ip-10-0-0-200 info tmm1[9810]: Rule /Common/VIP_1 <CLIENTSSL_CLIENTCERT>: Count of certificates is 1
Oct 16 16:22:31 ip-10-0-0-200 info tmm1[9810]: Rule /Common/VIP_1 <CLIENTSSL_CLIENTCERT>: this is VAR value 1122334455
Oct 16 16:22:31 ip-10-0-0-200 info tmm1[9810]: send to virtual vs-test-02
Oct 16 16:22:31 ip-10-0-0-200 info tmm1[9810]: result is 1122334455
Oct 16 16:22:31 ip-10-0-0-200 info tmm1[9810]: Rule /Common/VIP_1 <CLIENTSSL_HANDSHAKE>: This is clientssl_handshake - VS1
Oct 16 16:22:31 ip-10-0-0-200 debug tmm1[9810]: Rule /Common/VIP_1 <SERVER_CONNECTED>: This is server connected event VS1
Oct 16 16:22:31 ip-10-0-0-200 debug tmm1[9810]: Rule /Common/VIP_1 <SERVER_CONNECTED>: New TCP connection from 10.0.1.85:56112 to 10.0.1.85:56112
Oct 16 16:22:31 ip-10-0-0-200 info tmm1[9810]: table is bluelist and returns STRING
Oct 16 16:22:31 ip-10-0-0-200 debug tmm1[9810]: Rule /Common/VIP2 <CLIENT_ACCEPTED>: client accepted VS2
Oct 16 16:22:31 ip-10-0-0-200 debug tmm1[9810]: Rule /Common/VIP2 <CLIENT_ACCEPTED>: New TCP connection from 10.0.1.85:56112 to 10.0.3.50:21
Oct 16 16:22:31 ip-10-0-0-200 debug tmm1[9810]: Rule /Common/VIP2 <CLIENT_ACCEPTED>:
Oct 16 16:22:31 ip-10-0-0-200 debug tmm1[9810]: Rule /Common/VIP2 <CLIENT_DATA>: USER user   VS2 client data event
Oct 16 16:22:31 ip-10-0-0-200 info tmm1[9810]: Rule /Common/VIP2 <CLIENT_DATA>: This is client data
Oct 16 16:22:31 ip-10-0-0-200 debug tmm1[9810]: Rule /Common/VIP2 <CLIENT_DATA>: USER user
Oct 16 16:22:31 ip-10-0-0-200 debug tmm1[9810]: Rule /Common/VIP2 <CLIENT_DATA>: This is line 29
Oct 16 16:22:31 ip-10-0-0-200 debug tmm1[9810]: Rule /Common/VIP2 <SERVER_CONNECTED>: VS2 server connected event - on inner F5 this is connection to FTP server
Oct 16 16:22:31 ip-10-0-0-200 debug tmm1[9810]: Rule /Common/VIP2 <SERVER_CONNECTED>: New TCP connection from 10.0.1.85:56112 to 10.0.3.201:56112
Oct 16 16:22:31 ip-10-0-0-200 info tmm1[9810]: Rule /Common/VIP2 <SERVERSSL_CLIENTHELLO_SEND>: This is SERVERSSL_CLIENTHELLO_SEND - VS2
Oct 16 16:22:31 ip-10-0-0-200 info tmm1[9810]: Rule /Common/VIP2 <SERVERSSL_SERVERHELLO>: This is SERVERSSL_SERVERHELLO - VS2
Oct 16 16:22:31 ip-10-0-0-200 info tmm1[9810]: Rule /Common/VIP2 <SERVERSSL_SERVERCERT>: This is SERVERSSL_SERVERCERT - VS2
Oct 16 16:22:31 ip-10-0-0-200 info tmm1[9810]: SERVERSSL_SERVERCERT result for 10.0.1.85 is .
Oct 16 16:22:31 ip-10-0-0-200 info tmm1[9810]: table is bluelist and returns
Oct 16 16:22:31 ip-10-0-0-200 info tmm1[9810]: Rule /Common/VIP2 <SERVERSSL_HANDSHAKE>: This is SERVERSSL_HANDSHAKE - VS2
Oct 16 16:22:31 ip-10-0-0-200 debug tmm1[9810]: Rule /Common/VIP_1 <SERVER_DATA>: this is server data event VS1

e log .....

F5-Hopeful
Nimbostratus
Oct 17, 2019
Hi, thanks for the reply. The build follows the FTPS F5 build from:
https://devcentral.f5.com/s/articles/ftps-offload-via-irules
As well as FTPS, i want to take a value from the first VS (a dynamic value which changes with each connection) and make it available to the second VS. It works with a global variable. But since the value is dynamic, saving it in the session table is recommended by F5, rather than using the global variable (which would not scale with concurrent connections). However, maybe because of the ssl::disable/ssl::enable, the table seems not to save the value in the same table where it performs the lookup. That, or the table is reset by the time it does the lookup in the second VS. I thought, at one point, that the way the F5 handles the CMP (the VS is demoted from CMP when global variables are used), might have something to do with it - the global variable being available to the second VS might have meant that the memory was available to both. But, at this stage, i have no clue, it is becoming frustrating. I know that using the persistence profiles screws up the table config because values are retained and the "wrong" value is returned from a lookup in the same VS sometimes, so i'm not using persistence. Anyway, thanks for looking into it. I'm just grateful someone else is interested. I don't want to do IP blacklisting. Anyway, i'd be interested to know what you think. Because of where the table lookup occurs in the log, i don't think it is a race condition. Would you agree?
- boneyard
  MVP
  Oct 17, 2019
  i agree that logically you wouldn't expect a race condition.
  
  while i would like to built something similar i don't know if that is gonna happen soon.
  
  my strong advise remains to get F5 support involved, they can built something similar and check, they also should know if something like ssl::disable/enable or persistence might have an effect.
F5-Hopeful
Nimbostratus
Oct 17, 2019
Thanks a lot for having a look. I really appreciate it. I shall pursue through F5 and see if they respond. I shall let you know if i get anywhere with them
F5-Hopeful
Nimbostratus
Oct 30, 2019
Hi Boneyard,
I didn't get anywhere with F5. But it's working now. There were server events in the iRule on the first VIP. Even when they were hashed out it didn't work. When the iRule was re-created from scratch without the hashed out server commands in the first iRule, it worked. There have been some problems compiling the iRules and this complicated the problem even further.
Thanks for your help though.
Since you like a challenge ;-) i have another problem with selecting an SSL server profile in SERVER_CONNECTED via a data group and a class lookup, which logs but does not actually set the profile. I'm just about to raise a question about it on this forum.
Anyway, thanks for your help with this one
- boneyard
  MVP
  Nov 02, 2019
  thanks for sharing the solution, it might help others. replied on your other question.

Forum Discussion

Session table with Virtual Command

Recent Discussions

F5 looses the token for the first call

iRule - Url rewrite and header replace and pool selection not working

Switch ssl profile based on weak cipher detection via IRULE

full-proxy HTTP2

Decode ObjectSID from Base64-encode string

Related Content

iRulesLX: Invalid command name

APM Manage Session

Session persistence in LTM

APM sessions broken out by access policy?

Getting started with a script to delete user APM session(s)

ABOUT DEVCENTRAL

RESOURCES

SUPPORT

PARTNERS