Support Forum
The Forums are a place to find answers on a range of Fortinet products from peers and product experts.
Not applicable

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 11
rwpatterson
Valued Contributor III

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.

Bob - self proclaimed posting junkie!
See my Fortigate related scripts at: http://fortigate.camerabob.com

Bob - self proclaimed posting junkie!See my Fortigate related scripts at: http://fortigate.camerabob.com
Not applicable

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
Valued Contributor III

Log into your FAZ from the CLI. Execute the command
FAZ-800 # diagnose sys top
and post the results.

Bob - self proclaimed posting junkie!
See my Fortigate related scripts at: http://fortigate.camerabob.com

Bob - self proclaimed posting junkie!See my Fortigate related scripts at: http://fortigate.camerabob.com
Not applicable

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
Valued Contributor III

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.

Bob - self proclaimed posting junkie!
See my Fortigate related scripts at: http://fortigate.camerabob.com

Bob - self proclaimed posting junkie!See my Fortigate related scripts at: http://fortigate.camerabob.com
abelio

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

regards




/ Abel

regards / Abel
Not applicable

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

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.

regards




/ Abel

regards / Abel
Not applicable

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.
Announcements
Check out our Community Chatter Blog! Click here to get involved
Labels
Top Kudoed Authors