Skip to main content
Esteemed Contributor III
May 28, 2007
Question

logging allowed traffic delay

Hi all! We are testing our 2 new Fortigate1000 and our Fortianalyzer800 and we have some promblems logging the accepted traffic. We have detected a delay in the allowed traffic logging of about 2 minutes and a half, while denied traffic appears inmediatly in our FortiAnalyzer. We' ve been analyzing the traffic out from Fortigates and we think that the problem is not in the Fortianalyzer. Fortigates seem to delay the logs' sending. Is anyone experiencing something like this? Thanks in advanced! Maria

    11 replies

    rwpatterson
    New Member
    May 29, 2007
    What builds are on the boxes, and how many services are you logging? With my one 1000a, I' m having marginal performance issues, because the FGT is weighted heavier then the FAZ. The model of the FGT should be equal to or lower than that of the FAZ for optimal performance.
    Esteemed Contributor III
    May 29, 2007
    Hi Bob! We have in our Fortigates 3.00 MR4 patch 3 (build 479) and in our Fortianalyzer 3.00 MR4 patch 2 (build 507) We are not logging much services right now, because we are just testing the devices... Not IPS running either antivirus or web filtering, just 6 firewalling policies. Do you know if it is possible that the FGT are waiting for the session to finish or expire to logg the traffic? Thanks! Maria.
    rwpatterson
    New Member
    May 29, 2007
    Log into your FAZ from the CLI. Execute the command
    FAZ-800 # diagnose sys top
    and post the results.
    Esteemed Contributor III
    June 1, 2007
    Hi all! Sorry for my delay. This is the result I' ve get after executing ' diagnose sys top' Run Time: 2 days, 0 hours and 28 minutes 0U, 0N, 0S, 99I; 503T, 426F, 0KF cli 19487 R 0.1 0.4 fortilogd 781 S 0.0 5.8 fortilogd 796 S 0.0 5.8 fortilogd 795 S 0.0 5.8 fortilogd 794 S 0.0 5.8 fortilogd 797 S 0.0 5.8 init 1 S 0.0 1.3 httpsd 778 S 0.0 1.3 httpsd 1303 S 0.0 1.2 httpsd 767 S 0.0 1.1 cmdbsvr 722 S 0.0 1.1 oftpd 788 S 0.0 0.8 log_indexer 771 S N 0.0 0.7 smbd 785 S 0.0 0.7 miglogd 763 S 0.0 0.6 nmbd 784 S 0.0 0.6 rvsagent 759 S 0.0 0.6 cli 19482 S 0.0 0.6 rvsupdated 762 S 0.0 0.6 Everything seems OK, isn' t it? Thanks in advanced for your support!
    rwpatterson
    New Member
    June 1, 2007
    I was expecting something more like this:
      Run Time:  43 days, 23 hours and 48 minutes  26U, 0N, 72S, 0I; 503T, 337F, 0KF                 oftpd      791      R      56.3     0.4              rvsagent    20267      R      24.9     0.6                 oftpd      802      D      13.3     0.3             [kswapd0]       78      SW<     2.3     0.0              logfiled      784      S       1.9     0.3           [md0_raid5]      717      SW<     0.5     0.0           log_indexer    27176      R N     0.3     3.1             fortilogd      800      S       0.1     4.3                alertd      790      R N     0.1     0.4             fortilogd      799      S       0.0     4.3             fortilogd      783      S       0.0     4.3             fortilogd      798      S       0.0     4.3             fortilogd      801      S       0.0     4.3            log_binrpt    27247      R N     0.0     1.6                httpsd      804      S       0.0     0.9                httpsd      797      S       0.0     0.8              rvsagent      764      S       0.0     0.8                   cli    27291      S       0.0     0.6           log_indexer      776      S N     0.0     0.5               cmdbsvr      723      S       0.0     0.4                  sshd    27290      S       0.0     0.4                   cli    27311      R       0.0     0.4               uploadd    21257      S       0.0     0.4               miglogd      767      S       0.0     0.4                httpsd      771      S       0.0     0.4            rvsupdated      766      S       0.0     0.4                  fdpd      792      S       0.0     0.3                lcdapp      769      S       0.0     0.3             alertmail      789      S       0.0     0.3                flgdns      780      S       0.0     0.3                flgdns      796      S       0.0     0.3                flgdns      795      S       0.0     0.3                  ntpd      786      S       0.0     0.3                  init        1      S       0.0     0.3                 snmpd      785      S       0.0     0.3                hwmond      777      S N     0.0     0.2            log_binrpt    20087      S       0.0     0.2                ipsecd      772      S       0.0     0.2                 getty    20931      S       0.0     0.2                  sshd      782      S       0.0     0.1                  cron      781      S       0.0     0.1                  nmbd      787      S       0.0     0.1                  smbd      788      S       0.0     0.1             sftp_scpd      779      S       0.0     0.1                  CRON    20086      S       0.0     0.1    FAZ-800 #  
    The first column is the process name. The second is the process ID (PID). The third (I believe) is the process state. Not sure what the letters represent. The next is the percentage of the CPU that the process is using. If that column was added top to bottom, it should equal 100%. Yours is a wee bit light. I have seen in mine where the top is like yours, and there seems to be less than 100%, but wait for a couple of refreshes to see what comes out on top. Fortinet fixed an FTPD problem in your build and I wanted to see if two 1000A' s pointing to the box was overloading the connection. Try it again, and post please.
    abelio
    SuperUser
    SuperUser
    June 1, 2007
    The third (I believe) is the process state. Not sure what the letters represent.
    The same meaning of Unix' s top command: ’D’ = uninterruptible sleep ’R’ = running ’S’ = sleeping ’T’ = traced or stopped ’Z’ = zombie
    Esteemed Contributor III
    June 1, 2007
    Yes, I guess my Fortianalyzer WILL use a little bit more of the CPU, but I' m just testing the devices with a few PCs... They are not in production yet. That' s why it seems so strange to me the delay!!!! Do you thing it' s possible to be because of the accounting of bytes received/sended of finished sessions? Do yo think Fortigate waits till the session has expired to show the logging?
    abelio
    SuperUser
    SuperUser
    June 1, 2007
    Try to reconfirm that delay by looking your traffic directly: log into your FGT CLI, and issue this command:
      diagnose sniffer packet any ' src host <your1000_IP> and dst host <your_FAZ_ip> and udp and port 514'    
    If you' ve so few traffic from your hosts you could see and test your logging.
    Esteemed Contributor III
    June 5, 2007
    Sniffing between FG and FA was one of the first steps... we did it with tcpdump and a hub between the devices. FG doesn' t send the " accepted" log traffic to FA until some time has passed. I just wanted to know if it is a normal way of working in this kind of devices. We used real time logging with our old firewalls for the troubleshooting. If Real Time logging is not working properly in " real" real time, we will sniff traffic in the FG to troubleshoot. Thanks for your time and responses -Maria.
    red_adair
    New Member
    June 6, 2007
    could it be that only a " session" is logged. eg f it' s closed again ?
    Esteemed Contributor III
    June 7, 2007
    Yes, I think so!
    Thought Leadership. Security Summit. Thursday, November 12th, PGA National Resort, Palm Beach Gardens, FL.
    Thought Leadership. Security Summit. Thursday, October 8th. Disney's Grand Californian Hotel & SPA, Anaheim, CA.
    Security Operations Summit: Modernize SecOps. Operate AI-Native.AMER: November 4 | 9:00 AM PST. India and SAARC: November 5 | 10:00 AM IST. EMEA: November 5 | 10:30 AM CET. APAC: November 5 | 11:00 AM SGT