Differences

This shows you the differences between two versions of the page.

--- en:dpi:faq:fastdpi:administrator:start [2024/07/29 15:10] – created elena.krasnobryzh
+++ en:dpi:faq:fastdpi:administrator:start [Unknown date] (current) – removed - external edit (Unknown date) 127.0.0.1
@@ Line 1: / Line 1: @@
-====== Administration Questions ======
-{{indexmenu_n>5}}
-<accordion autoclose>
-<accordion-item title="1. How to check the current release (CCC)?">
-By using the command <code bash>fastdpi -re</code>
-</accordion-item>
-<accordion-item title="2. How to check the current version?">
-By using the command <code bash>fastdpi -ve</code>
-</accordion-item>
-<accordion-item title="3. How to roll back to a previous version?">
-Example of rolling back from version 2.7 to 2.6: <code bash>yum downgrade fastdpi-2.6</code>
-</accordion-item>
-<accordion-item title="4. What does the error 'error loading DSCP settings, res=-4' mean?">
-The error occurs due to the absence of DSCP by autonomous systems. It can be ignored.
-</accordion-item>
-<accordion-item title="5. What to do if not all commands are processed and the error 'ERROR : Can't connect to 127.0.0.1:29000, errcode=99 : Cannot assign requested address Autodetected fastdpi params : dev='lo', port=29000 connecting 127.0.0.1:29000 ...' appears?">
-''fdpi_ctrl'' uses the regular Linux stack to communicate with DPI, so tuning recommendations are similar to those for web servers (like nginx) under high load.\\
-The settings are similar to those recommended for nginx and should be added to the ''/etc/sysctl.conf'' file to persist after reboot:\\
-<code bash>
-# OS network stack optimization
-net.core.netdev_max_backlog=10000
-net.core.somaxconn=262144
-net.ipv4.tcp_syncookies=1
-net.ipv4.tcp_max_syn_backlog = 262144
-net.ipv4.tcp_max_tw_buckets = 720000
-net.ipv4.tcp_tw_recycle = 1
-net.ipv4.tcp_timestamps = 1
-net.ipv4.tcp_tw_reuse = 1
-net.ipv4.tcp_fin_timeout = 30
-net.ipv4.tcp_keepalive_time = 1800
-net.ipv4.tcp_keepalive_probes = 7
-net.ipv4.tcp_keepalive_intvl = 30
-net.core.wmem_max = 33554432
-net.core.rmem_max = 33554432
-net.core.rmem_default = 8388608
-net.core.wmem_default = 4194394
-net.ipv4.tcp_rmem = 4096 8388608 16777216
-net.ipv4.tcp_wmem = 4096 4194394 16777216
-</code>
-for a 1 Gbps interface: <code bash>net.core.netdev_max_backlog=10000</code>
-for a 10 Gbps interface: <code bash>net.core.netdev_max_backlog=30000</code>
-To apply the changes without rebooting, you can change them on the fly by using the command <code bash>sysctl -w <setting></code>
-For example: <code bash>sysctl -w net.ipv4.tcp_tw_reuse=1</code>
-This should resolve the issue.
-**For CentOS 7**\\
-Example:
-<code bash>
-# OS network stack optimization
-net.core.netdev_max_backlog=65536
-net.core.optmem_max=25165824
-net.core.somaxconn=1024
-net.ipv4.tcp_max_orphans = 60000
-net.ipv4.tcp_no_metrics_save = 1
-net.ipv4.tcp_window_scaling = 1
-net.ipv4.tcp_timestamps = 1
-net.ipv4.tcp_sack = 1
-net.ipv4.tcp_syncookies=1
-net.ipv4.tcp_max_syn_backlog = 262144
-net.ipv4.tcp_max_tw_buckets = 720000
-net.ipv4.tcp_tw_recycle = 1
-net.ipv4.tcp_timestamps = 1
-net.ipv4.tcp_tw_reuse = 1
-net.ipv4.tcp_fin_timeout = 30
-net.ipv4.tcp_keepalive_time = 1800
-net.ipv4.tcp_keepalive_probes = 7
-net.ipv4.tcp_keepalive_intvl = 30
-net.core.wmem_max = 33554432
-net.core.rmem_max = 33554432
-net.core.rmem_default = 8388608
-net.core.wmem_default = 4194394
-net.ipv4.tcp_rmem = 4096 8388608 16777216
-net.ipv4.tcp_wmem = 4096 4194394 16777216
-</code>
-Update command: <code bash>sysctl –system</code>
-[[https://christophermonzon.wordpress.com/2016/10/04/centos-7-network-performance/|More information on CentOS7]]
-[[http://www.vasexperts.ru/upload/SCESM2СКАТ.zip|Scripts for migrating from SCE SM to SSG database, description inside]]
-</accordion-item>
-<accordion-item title="6. How to check the load by cores and understand why they are unevenly loaded?">
-To view CPU load by cores in the ''top'' utility, press 1.\\
-To view load by DPI tasks, use the command: <code bash>ps -p `pidof fastdpi` H -o %cpu,lwp,pri,psr,comm</code>
-**Example** output:
-<code bash>  %CPU   LWP PRI PSR COMMAND
-.0  23141  41   0 fastdpi_main
-.0  23146  41   0 fastdpi_dl
-.3  23147  41   0 fastdpi_ctrl
-.8 23148  41   0 fastdpi_ajb
-.7 23152  41   1 fastdpi_rx_1
-.1 23165  41   2 fastdpi_wrk0
-.1 23170  41   3 fastdpi_wrk1</code>
-In DPI, the COMMAND tasks are functionally separated by cores (PSR) to avoid interfering with each other's work:
-  - ''wrk'' threads perform data analysis in network packets
-  - ''rx'' thread handles data transit between network ports
-  - other threads perform application and auxiliary tasks (generating Netflow, receiving control commands, loading lists, writing PCAP, etc.) and can create peak loads on the CPU, so they are assigned to a separate core.
-</accordion-item>
-<accordion-item title="7. What to do if the error in fastdpi_alert.log '[CRITICAL][2017/10/06-16:36:44:616019][0x7fdb297ac700] metadata_storage : Can't allocate memory [repeat 1], cntr=188889, allocated=188889' appears?">
-In DPI, everything is pre-allocated, by default for the number of subscribers specified in the error (188889). This is controlled by the parameter in the configuration file ''mem_ip_metadata_recs''.\\
-**For example,** to increase to 500000 subscribers, set in the ''/etc/dpi/fastdpi.conf'' configuration file:
-<code bash>mem_ip_metadata_recs=500000</code>
-After changing the parameter, a restart is required: <code bash>service fastdpi restart</code>
-</accordion-item>
-<accordion-item title="8. Which files are recommended to be archived?">
-<code bash>
-cp /etc/pf_ring/ /BACKUPDIR/pf_ring
-cp /etc/dpi /BACKUPDIR/etc/
-mdb_copy /var/db/dpi /BACKUPDIR/db/
-</code>
-With ''mdb_copy'', you can make a backup while fastDPI is running.
-</accordion-item>
-<accordion-item title="9. What to do if ipmi uses 100% CPU and interferes with DPI operation?">
-Run the command
-<code bash>echo 100 > /sys/module/ipmi_si/parameters/kipmid_max_busy_us</code>
-To ensure the setting is not lost after a server reboot, add this command to ''/etc/rc.local''
-</accordion-item>
-<accordion-item title="10. What to do if an error in the alert log '[ERROR ] bpm : thread #1 - does not change self-monitoring counters', DPI restarted and generated a core or switched to bypass?">
-DPI performs self-diagnostics during operation, and if one of the working threads hangs and can no longer process traffic, DPI detects this state and restarts with core generation on Abort signal.
-<note important>**Important:** trace and dbg settings in ''fastdpi.conf'' are intended for diagnostics and debugging, not for permanent operation. If disk write is blocked by another process (e.g., log rotation, which typically occurs from 3 to 4 AM), enabling tracing may cause the working thread to block on writing to the diagnostic (slave) log, leading to DPI switching to bypass or restarting. After diagnostics, remember to disable these settings. </note>
-The problem occurs only on certain servers. If your server is affected, we recommend changing the standard disk scheduler to deadline:
-<code bash>echo deadline > /sys/block/sda/queue/scheduler
-echo deadline > /sys/block/sdb/queue/scheduler</code>
-</accordion-item>
-<accordion-item title="11
-. Why does the memory consumption of the process increase during operation?">
-DPI allocates memory statically: at process start and when creating certain service profiles (such as NAT, black and white lists). During operation, additional memory is not allocated. So why does consumption increase?\\
-Linux distinguishes between resident (RES in top) and virtual (VIRT in top) process memory. The peculiarity is that while memory is uninitialized (actually initialized to zero), Linux does not record it as resident and moves it there as it is initialized.\\
-Setting ''mem_preset=1'' in ''/etc/dpi/fastdpi.conf'' instructs DPI to initialize all allocated memory (almost all), preventing the resident part from growing during operation. This option slows down the startup and is good when there is enough physical RAM. It is better to consider this factor and monitor virtual (VIRT) and resident (RES) memory separately.
-</accordion-item>
-<accordion-item title="12. What to do if there are many "zombie" processes with names ''wd_*'' on one of the SSG?">
-<code bash>
-?        Z      0:00  \_ [wd_fastdpi.sh] <defunct>
-?        Z      0:00  \_ [wd_fastpcrf.sh] <defunct>
-</code>
-Simply restart the watchdog: <code bash> service watchdog restart</code>
-</accordion-item>
-<accordion-item title="13. Protocol or signature detection problem">
-In case of protocol or signature detection issues, perform three tests on each of the following devices:
-  * Personal computer
-  * Smartphone on iOS
-  * Smartphone on Android
-The following recommendations help eliminate unnecessary traffic:
-  * It is recommended to conduct the test on a PC in incognito mode.
-  * When testing on a smartphone, enable power-saving mode.
-Test execution:
-  - Check if the following parameters are enabled in the ''/etc/dpi/fastdpi.conf'' file:<code bash>trace_ip=“subscriber's IP”
-ajb_save_ip=“subscriber's IP”
-plc_trace_ip=“subscriber's IP”
-</code> If any of these parameters are enabled, comment them out and perform ''service fastdpi reload''.
-  - Execute the command <code bash>find /var/log/dpi -type f -name "fastdpi_slave_*.log" -exec sh -c 'cat /dev/null > {}'  \;</code> The command should clear the ''fastdpi_slave_*.log'' files.
-  - Delete all files from ''/var/dump/dpi/''.
-  - Open the ''/etc/dpi/fastdpi.conf'' file in a text editor. Add the parameters: <code bash>trace_ip=“subscriber's IP”
-ajb_save_ip=“subscriber's IP”
-plc_trace_ip=“subscriber's IP” #For this parameter to work, the test subscriber must have a policing profile
-</code>
-  - Prepare the test subscriber for launch to generate problematic traffic.
-  - Perform ''service fastdpi reload''.
-  - Start generating traffic. Record traffic for 1 minute.
-  - Open the ''fastdpi.conf'' file. Comment out the parameters: <code bash>trace_ip=“subscriber's IP”
-ajb_save_ip=“subscriber's IP”
-plc_trace_ip=“subscriber's IP”
-</code>
-  - Perform ''service fastdpi reload''.
-  - Prepare the output of the following commands into files: <code bash>“fastdpi -ve”
-“dscp2lst /etc/dpi/protocols.dscp”
-“fdpi_ctrl list --policing --ip “subscriber's IP”
-“dscp2as /etc/dpi/asnum.dscp”.
-</code>
-  - Prepare an archive with the files from point 10 and the ''fastdpi.conf'' file.\\ From ''/var/log/dpi'' — ''fastdpi_stat.log'', ''fastdpi_slave_*.log''.\\ From ''/var/dump/dpi'' — ''udp_*.pcap''.
-  - Repeat the required number of tests with different devices. Indicate in the archive name or in a ''readme.txt'' file within the archive the types of devices used for testing.
-  - Attach the archives to the ticket. If the archives are too large, upload them to any cloud file sharing service and send us the link.
-</accordion-item>
-</accordion>

Profile

Settings

Differences