Forum Discussion

jrmorris_151361's avatar
jrmorris_151361
Icon for Nimbostratus rankNimbostratus
Jul 30, 2015

How to view session table created with iRule

Hi, I have created the following iRule. I know the reject is commented out and the limit is high. But for now, I want to monitor what the iRule actually catches. Is there a way for me to view the tables created by the iRule? Maybe something similar to 'tmsh show sys connection'? Thanks.

  when CLIENT_ACCEPTED {
  set tbl "connlimit:[IP::client_addr]"
  set key "[TCP::client_port]"

  table set -subtable $tbl $key "ignored" 180
  if { [table keys -subtable $tbl -count] > 5000 } {
  table delete -subtable $tbl $key
  event CLIENT_CLOSED disable
  reject
  } else {
   set timer [after 60000 -periodic { table lookup -subtable $tbl $key }] }
 }
 when CLIENT_CLOSED {
   after cancel $timer
   table delete -subtable $tbl $key }

21 Replies

  • I tested your config in my box now and it worked, but I have a feeling that we might run different versions. I'm running 11.5.3.1.0.167 Hotfix 1.

    That said I'm about to run out of ideas.

    Try this rule to see if there actually is any content?

    when HTTP_REQUEST {
    
        set response ""
    
        foreach tablename [table keys -subtable "metatable"] {
            foreach key [table keys -subtable $tablename] {
                set value [table lookup -notouch -subtable $tablename $key]
                set response "$response
    $key = $value"
            }
        }
    
        HTTP::respond 200 content "$response"
        log local0. "HTTP RESPONSE: $response"
    }
    

    /Patrik

  • Thanks. You're right about being on different versions. I am on 11.6.0 Build 3.0.412 Hotfix HF3.

    I still only see a blank page. Here is the log entry...

    tmm2[16844] Rule /Common/TEST_View_Tables_3 : HTTP RESPONSE: 

    Thanks for all your help. No worries if you can't think of anything else.

  • Been wrecking my brain here for an answer and I can't come up with any obvious ones. I WOULD try something like below though in order to satisfy my curiosity.

    Please note, before trying, that if this Virtual server is in production and very busy you do NOT want to do this without filtering by client IP as it will write entries to your ltm logfile.

    The rule is basically just a combination of the two and would ensure that the iRule is executed in the same TMM core.

    One more thing to note, is that using subtables will impact performance of the virtual server, so it's not advisable performance wise if your virtual server is/will be very busy and you're having low margins in terms of capacity.

    If you still get nothing in the LTM log after this I'd contact F5.

    And please post your findings. 🙂

    when CLIENT_ACCEPTED {
    
        set tbl "connlimit:[IP::client_addr]"
        set key "[TCP::client_port]"
    
        table set -subtable metatable "connlimit:[IP::client_addr]" 1
    
        table set -subtable $tbl $key "ignored" 180
    
        if { [table keys -subtable $tbl -count] > 5000 } {
            table delete -subtable $tbl $key
            event CLIENT_CLOSED disable
          reject
        } else {
            set timer [after 60000 -periodic { table lookup -subtable $tbl $key }] 
        }
    }
    
    when CLIENT_CLOSED {
        after cancel $timer
        table delete -subtable $tbl $key 
    }
    
    when HTTP_REQUEST {
    
        set response ""
    
        foreach tablename [table keys -subtable "metatable"] {
            foreach key [table keys -subtable $tablename] {
                set value [table lookup -notouch -subtable $tablename $key]
                set response "$response
    $key = $value"
            }
        }
        log local0. "HTTP RESPONSE: $response"
    }
    
  • Thanks. I applied that rule to the same VS that was performing my load balancing. Since the VS was an http VS, I wasn't able to see the metatable page at all...I was just hitting my pool of web servers.

    I did see the following in the logs though...

    Tue Aug 18 08:02:52 CDT 2015    info    SJ305DCF52  tmm2[16844]     Rule /Common/TEST_View_Tables_3 : HTTP RESPONSE: 
    29084 = ignored
    Tue Aug 18 08:02:52 CDT 2015    info    SJ305DCF52  tmm2[16844]     Rule /Common/TEST_View_Tables_3 : HTTP RESPONSE: 
    29083 = ignored
    Tue Aug 18 08:02:52 CDT 2015    info    SJ305DCF52  tmm3[16844]     Rule /Common/TEST_View_Tables_3 : HTTP RESPONSE: 
    29082 = ignored
    Tue Aug 18 08:02:51 CDT 2015    info    SJ305DCF52  tmm[16844]      Rule /Common/TEST_View_Tables_3 : HTTP RESPONSE: 
    29081 = ignored
    Tue Aug 18 08:02:51 CDT 2015    info    SJ305DCF52  tmm1[16844]     Rule /Common/TEST_View_Tables_3 : HTTP RESPONSE: 
    29080 = ignored
    Tue Aug 18 08:02:51 CDT 2015    info    SJ305DCF52  tmm[16844]      Rule /Common/TEST_View_Tables_3 : HTTP RESPONSE: 
    29079 = ignored
    Tue Aug 18 08:02:51 CDT 2015    info    SJ305DCF52  tmm1[16844]     Rule /Common/TEST_View_Tables_3 : HTTP RESPONSE: 
    29078 = ignored
    Tue Aug 18 08:02:51 CDT 2015    info    SJ305DCF52  tmm2[16844]     Rule /Common/TEST_View_Tables_3 : HTTP RESPONSE: 
    29077 = ignored
    Tue Aug 18 08:02:51 CDT 2015    info    SJ305DCF52  tmm3[16844]     Rule /Common/TEST_View_Tables_3 : HTTP RESPONSE: 
    29076 = ignored
    Tue Aug 18 08:02:50 CDT 2015    info    SJ305DCF52  tmm3[16844]     Rule /Common/TEST_View_Tables_3 : HTTP RESPONSE: 
    29075 = ignored
    Tue Aug 18 08:02:50 CDT 2015    info    SJ305DCF52  tmm2[16844]     Rule /Common/TEST_View_Tables_3 : HTTP RESPONSE: 
    29074 = ignored
    Tue Aug 18 08:02:50 CDT 2015    info    SJ305DCF52  tmm1[16844]     Rule /Common/TEST_View_Tables_3 : HTTP RESPONSE: 
    29074 = ignored
    29073 = ignored
    Tue Aug 18 08:02:50 CDT 2015    info    SJ305DCF52  tmm[16844]      Rule /Common/TEST_View_Tables_3 : HTTP RESPONSE: 
    29074 = ignored
    29073 = ignored
    29071 = ignored
    Tue Aug 18 08:02:50 CDT 2015    info    SJ305DCF52  tmm3[16844]     Rule /Common/TEST_View_Tables_3 : HTTP RESPONSE: 
    29073 = ignored
    29071 = ignored
    29072 = ignored
    Tue Aug 18 08:02:50 CDT 2015    info    SJ305DCF52  tmm2[16844]     Rule /Common/TEST_View_Tables_3 : HTTP RESPONSE: 
    29073 = ignored
    29071 = ignored
    29072 = ignored
    29070 = ignored
    Tue Aug 18 08:02:49 CDT 2015    info    SJ305DCF52  tmm1[16844]     Rule /Common/TEST_View_Tables_3 : HTTP RESPONSE: 
    29070 = ignored
    29069 = ignored
    
  • The way I have heard that subtables works is that they are owned by one TMM process, but accessible from other TMM processes, so they should be visible from the other VIP (after all, it worked for me).

     

    My final theory is that the web servers close the connections quite fast which would explain why you do not have any entries in the table as the entries are deleted after the connection has been closed. Can you check in ie. Chrome developer tools to see if the server responds with a header called "Connection: close"? Also, can you check with wireshark/tcpdump if the TCP connection is closed after the request has been served?

     

    /Patrik

     

  • I do not see a connection closed header in the Chrome dev tools. I see mostly 200s with an occasional 304.

     

    I did a wireshark capture and also do not see a close, but I do see a reset everytime coming from the VS.

     

     

  • That does not look really normal. Do you get any entries in the LTM log? Can you expand packet 109 and check for the HTTP response data? If you can't see it you can re-run the capture with the s0 flag.

     

    Kind regards, Patrik