Forum Discussion

scottjf8_82523's avatar
scottjf8_82523
Icon for Nimbostratus rankNimbostratus
Dec 13, 2010

How to log what IP a "snat automap" is using

All

 

 

Using the "snat automap" command in an iRule - if we have more than 1 Self IP, how can we log which IP is being used for a snat?

 

5 Replies

  • Hi Scott,

     

     

    You can log [IP::local_addr] in SERVER_CONNECTED to get the source IP LTM uses for the serverside connection. This will work for SNAT or no translation.

     

     

    Aaron
  • Hi,

     

     

    I am implementig something similar. For security reasons, our client whants to log all the snat conections of the clients. They want to know what snat ip was assigned to which client at what time, and the time that connection was clossed.

     

     

    For the start of the session I have used SERVER_CONNECTED event, and for the close of the session: SERVER_CLOSED event.

     

     

    This is the first rule I am testing (quite simple):

     

     

    when SERVER_CONNECTED {

     

    set snat [IP::local_addr]

     

    log local0. $snat

     

    log local0. "[IP::client_addr], [IP::local_addr], [IP::server_addr]"

     

    }

     

     

    when SERVER_CLOSED {

     

    set snat [IP::local_addr]

     

    log local0. $snat

     

    log local0. "[IP::local_addr], [IP::server_addr]"

     

    }

     

     

     

    I have been making some tests using the virtual to http navigation, and I have seen that lots of messages are being logged in ltm.log, and i afraid in production, the log will be hugh. I expected virtual should make some kind of persistence, and once a client has oppened a connection, it will stay for a while. But in the test, lots of sessions are being stablished and clossed in a few secconds continusly.

     

     

    Do you think that behaviour is normal??? Or perhaps I am not using events correctly??

     

     

    Scott, Do you remember having problems with log size with that irule?? I think there is a maximum size of the log (not remember how much exactly), and I´m afraid system to go down due to the irule...

     

     

    In other kind of issue, always I add a log in an irule, it is written in ltm.log. Now I am thincking in the possibility of using an especific file for this irule, not ltm.log. Do you know if it is possible to write log on a diferent file ??? (for example in /var/tmp/snat.log) Or it is not possible via iRule??

     

     

    Thank you very much in advance.

     

     

    Best regards.
  • Hi Adrian,

     

     

    I would only log once per connection in SERVER_CONNECTED--not in both SERVER_CONNECTED and SERVER_CLOSED. If you want to log this for every connection, in production, you should consider logging directly to a syslog server (or syslog pool). In 10.1+, you can use the HSL::send command to do this:

     

     

    http://devcentral.f5.com/wiki/default.aspx/iRules/HSL__send.html

     

     

    For older versions, you can log remotely with the log command:

     

     

    http://devcentral.f5.com/Community/GroupDetails/tabid/1082223/aff/5/afv/topic/aft/1176784/afc/1201556/Default.aspx

     

     

    Aaron
  • Hi Aaron.

     

     

    Thank you very much!

     

     

    I also log in SERVER_CLOSED because customer wants to know exactly when a client starts and stops using an especific IP for snat.

     

     

    Regarding sending to a remote log. If log is so huge, do you think it is a good idea??? It seems to me to use more cpu sending each log to a remote syslog than writing in a local file....

     

     

    Thanks!!

     

     

    BR
  • Hi Adrian,

     

     

    I believe it's more efficient to send the syslog messages remotely using HSL than running them through syslog-ng and logging to local disk. You could compare this using two virtual servers: one configured to log locally and one logging remotely using HSL. You can check the resource utilization using top. If you do try this, can you report back what you find?

     

     

    Thanks, Aaron