IBM Support

QRadar Managed Hosts intermittently display status Unknown



From the QRadar Console UI > Admin > System and License Management, some Managed Hosts display as Unknown status.
image 7214


If you perform a Full Configuration Deploy, the host temporarily displays Active or Standby instead of Unknown.


Typically the cause is a network overloaded with low bandwidth, high latency, or both.
  1. Test bandwidth, on the Console, by running the following commands:
    cd /store/configservices/configurationsets/
    scp globalset_list.xml ${managedhostIP}:/store/configservices/configurationsets
    If the file transfer completes in under 5 minutes, and bandwidth is greater than or equal to 12.5 MBps, or 100 Mbps, then bandwidth and latency are not the issues.
  2. Test latency by enabling ping and run the following ping command:
    1. QRadar: Enabling ping response on appliances
      ping -c 3 ${managedhostIP}
      If you are not getting good bandwidth or latency, talk to your Network Administrator. These files are transferred during each deploy. If you have more EPS you require more bandwidth, and if you use under 10K EPS less bandwidth is required.

Diagnosing The Problem

You can verify the issue by checking whether there are errors or dropped packets in the ifconfig command, under RX errors {N} dropped {N} or TX errors {N} dropped {N}.
# ifconfig
Example of the output:
ens192: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
inet x.x.x.x  netmask  broadcast x.x.x.x
inet6 xxxx::xxx:xxxx:xxxx:xxxx  prefixlen xx  scopeid 0x20<link>
ether xx:xx:xx:xx:xx:xx  txqueuelen 1000  (Ethernet)
RX packets 450896  bytes 132095086 (125.9 MiB)
RX errors 0  dropped 5  overruns 0  frame 0
TX packets 211830  bytes 1261565920 (1.1 GiB)
TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Resolving The Problem

  1. If network encryption is enabled, enable network compression:
    From the QRadar Console UI > Admin > System and License Management > Select host > Deployment Actions > Edit Host > Select Encryption Compression.

    Note: Encryption Compression alleviates some of the load on the network and increases the load on the appliance's CPU.
  2. Test the MTU by running the following ping command:
    ping -M do -s 1400 ${destinationIP}
    If the ping returns: ping: local error: Message too long, mtu=1400, then there is probably a VPN or some other networking making the default 1500 MTU have issues.

    Note: Another side effect, from MTU configuration issues, is when you SSH to the host it is slow to connect and respond to commands despite the CPU, RAM, and Disk IO being low.

    You can temporarily adjust the MTU to a lower value to see whether that helps, first in the ping test, then temporarily with the following command:
    ifconfig ${Interface} mtu ${SIZE}

    If the temporary value resolves the issue, you can make it permanent by editing or adding the following:

    /etc/sysconfig/network-scripts/ifcfg-{interface} :
    Note: For IPV6 set the dedicated MTU as follows:
    Save and close the file. Restart networking:
    Note: you lose your connection during this step, and it is important to have IMM, or other remote Console, configured.
    systemctl restart network
    Sometimes a restart of networking is not sufficient and a restart of the host is needed.
  3. Check whether one of the DNS servers is the issue.
    {IP of DNS}
    {Console IP}
    Nslookup needs to be successful for all DNS servers in use. Remove any failed DNS from the system. See the following qchange_netsetup technote to remove or change the DNS.

Document Location


[{"Line of Business":{"code":"LOB24","label":"Security Software"},"Business Unit":{"code":"BU059","label":"IBM Software w\/o TPS"},"Product":{"code":"SSBQAC","label":"IBM Security QRadar SIEM"},"ARM Category":[{"code":"a8m0z000000cwtNAAQ","label":"Deployment"}],"ARM Case Number":"","Platform":[{"code":"PF016","label":"Linux"}],"Version":"7.3.3;7.4.0;7.4.1"}]

Document Information

Modified date:
14 December 2020