100% CPU Utilization on VNA Collector
search cancel

100% CPU Utilization on VNA Collector

book

Article ID: 265989

calendar_today

Updated On: 02-14-2024

Products

Virtual Network Assurance

Issue/Introduction

  • The VNA collector CPU is reporting 100% for Wildlfy even though there is minimal load on the system.
  • The VNA server.log (VNAHOME/wildfly/standalone/log) shows repeat QUALYS related error messages:

Example:

2023-03-09 21:25:31,497 ERROR [io.undertow.request] (management I/O-1) UT005071: Undertow request failed HttpServerExchange{ GET /}: java.lang.NumberFormatException: For input string: "40029/QUALYSTEST}"
    at java.base/java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
    at java.base/java.lang.Integer.parseInt(Integer.java:652)
    at java.base/java.lang.Integer.parseInt(Integer.java:770)
    at org.jboss.as.domain-http-interface@18.1.1.Final//org.jboss.as.domain.http.server.cors.CorsUtil.sanitizeDefaultPort(CorsUtil.java:119)
    at org.jboss.as.domain-http-interface@18.1.1.Final//org.jboss.as.domain.http.server.cors.CorsUtil.matchOrigin(CorsUtil.java:69)
    at org.jboss.as.domain-http-interface@18.1.1.Final//org.jboss.as.domain.http.server.cors.CorsHttpHandler.setCorsResponseHeaders(CorsHttpHandler.java:87)
    at org.jboss.as.domain-http-interface@18.1.1.Final//org.jboss.as.domain.http.server.cors.CorsHttpHandler.handleRequest(CorsHttpHandler.java:74)
    at org.jboss.as.domain-http-interface@18.1.1.Final//org.jboss.as.domain.http.server.ManagementHttpServer$UpgradeFixHandler.handleRequest(ManagementHttpServer.java:660)
    at io.undertow.core@2.2.17.Final//io.undertow.server.Connectors.executeRootHandler(Connectors.java:387)
    at io.undertow.core@2.2.17.Final//io.undertow.server.protocol.http.HttpReadListener.handleEventWithNoRunningRequest(HttpReadListener.java:256)
    at io.undertow.core@2.2.17.Final//io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:136)
    at io.undertow.core@2.2.17.Final//io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:162)
    at io.undertow.core@2.2.17.Final//io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:100)
    at io.undertow.core@2.2.17.Final//io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:57)
    at org.jboss.xnio@3.8.7.Final//org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
    at org.jboss.xnio@3.8.7.Final//org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:291)
    at org.jboss.xnio@3.8.7.Final//org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:286)
    at org.jboss.xnio@3.8.7.Final//org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
    at org.jboss.xnio.nio@3.8.7.Final//org.xnio.nio.QueuedNioTcpServer2.acceptTask(QueuedNioTcpServer2.java:178)

 

Environment

Release: VNA 21.2.9 through 22.2.11, and 23.3.2

Cause

  • There is a denial of service attack that exists in Wildfly when Java 11 version 11.0.18+ is used.
  • The root cause of the issue is in a third-party library called Undertow which was introduced in Java 11.0.18. 

Jstack analysis of Wildfly when it is in a bad state shows the following:

at sun.security.ssl.SSLEngineImpl.writeRecord(java.base@11.0.19/SSLEngineImpl.java:213)
at sun.security.ssl.SSLEngineImpl.wrap(java.base@11.0.19/SSLEngineImpl.java:136)
- locked <0x00007f2111f30520> (a sun.security.ssl.SSLEngineImpl)
at sun.security.ssl.SSLEngineImpl.wrap(java.base@11.0.19/SSLEngineImpl.java:116)
- locked <0x00007f2111f30520> (a sun.security.ssl.SSLEngineImpl)
at javax.net.ssl.SSLEngine.wrap(java.base@11.0.19/SSLEngine.java:482)

The above points to the following issues :


https://bugzilla.redhat.com/show_bug.cgi?id=2174246

You can run the following netsat commands:

  • netstat - anp | grep 8443
  • netstat -anp | grep 8080
  • netstat -anp | grep 9990
  • netstat -anp | grep 9993

 If any of the above returns many entries CLOSE_WAIT status this is a good indication you are experiencing this issue.

Example:

netstat -anp | grep 8443
tcp        0      0 0.0.0.0:8443            0.0.0.0:*               LISTEN      -                   
tcp      249      0 xx.xx.xx.xx:8443      xx.xx.xx.xx:42786      CLOSE_WAIT  -                   
tcp      202      0 xx.xx.xx.xx:8443      xx.xx.xx.xx:59346      CLOSE_WAIT  -                   
tcp      249      0 xx.xx.xx.xx:8443      xx.xx.xx.xx:40112      CLOSE_WAIT  -                   
tcp      249      0 xx.xx.xx.xx:8443      xx.xx.xx.xx:56660      CLOSE_WAIT  -                   
tcp        0      0 xx.xx.xx.xx:8443      xx.xx.xx.xx:53026      CLOSE_WAIT  -                   
tcp      249      0 xx.xx.xx.xx:8443      xx.xx.xx.xx:50074      CLOSE_WAIT  -                   
tcp      249      0 xx.xx.xx.xx:8443      xx.xx.xx.xx:50894      CLOSE_WAIT  -                   
tcp      249      0 xx.xx.xx.xx:8443      xx.xx.xx.xx:43550      CLOSE_WAIT  -                   
tcp      249      0 xx.xx.xx.xx:8443      xx.xx.xx.xx:60160      CLOSE_WAIT  -                   
tcp        0      0 xx.xx.xx.xx:8443      xx.xx.xx.xx:37578      CLOSE_WAIT  -                   
tcp      142      0 xx.xx.xx.xx:8443      xx.xx.xx.xx:48264      CLOSE_WAIT  -                   
tcp      249      0 xx.xx.xx.xx:8443      xx.xx.xx.xx:38654      CLOSE_WAIT  -                   
tcp      249      0 xx.xx.xx.xx:8443      xx.xx.xx.xx:33120      CLOSE_WAIT  -                   
tcp      202      0 xx.xx.xx.xx:8443      xx.xx.xx.xx:53132      CLOSE_WAIT  -                   
tcp      249      0 xx.xx.xx.xx:8443      xx.xx.xx.xx:35260      CLOSE_WAIT  -                   
tcp      148      0 xx.xx.xx.xx:8443      xx.xx.xx.xx:33478      CLOSE_WAIT  -                   
tcp        0      0 xx.xx.xx.xx:8443      xx.xx.xx.xx:32786      CLOSE_WAIT  -                   
tcp      206      0 xx.xx.xx.xx:8443      xx.xx.xx.xx:57030      CLOSE_WAIT  -                   
tcp      249      0 xx.xx.xx.xx:8443      xx.xx.xx.xx:40796      CLOSE_WAIT  -                   
tcp      249      0 xx.xx.xx.xx:8443      xx.xx.xx.xx:58750      CLOSE_WAIT  -                   
tcp      249      0 xx.xx.xx.xx:8443      xx.xx.xx.xx:38886      CLOSE_WAIT  -                   
tcp      249      0 xx.xx.xx.xx:8443      xx.xx.xx.xx:38642      CLOSE_WAIT  -                   
tcp      249      0 xx.xx.xx.xx:8443      xx.xx.xx.xx:55758      CLOSE_WAIT  -                   
tcp      249      0 xx.xx.xx.xx:8443      xx.xx.xx.xx:56470      CLOSE_WAIT  -                   
tcp      249      0 xx.xx.xx.xx:8443      xx.xx.xx.xx:44630      CLOSE_WAIT  -                   
tcp        0      0 xx.xx.xx.xx:8443      xx.xx.xx.xx:35232      CLOSE_WAIT  -                   
tcp      518      0 xx.xx.xx.xx:8443      xx.xx.xx.xx:49506      CLOSE_WAIT  -                   
tcp      249      0 xx.xx.xx.xx:8443      xx.xx.xx.xx:35876      CLOSE_WAIT  -                   
tcp      248      0 xx.xx.xx.xx:8443      xx.xx.xx.xx:49576      CLOSE_WAIT  -                   
tcp      249      0 xx.xx.xx.xx:8443      xx.xx.xx.xx:42716      CLOSE_WAIT  -                   
tcp        0      0 xx.xx.xx.xx:8443      xx.xx.xx.xx:37354      CLOSE_WAIT  -                   
tcp      249      0 xx.xx.xx.xx:8443      xx.xx.xx.xx:36704      CLOSE_WAIT  -                   
tcp      249      0 xx.xx.xx.xx:8443      xx.xx.xx.xx:53442      CLOSE_WAIT  -                   
tcp      249      0 xx.xx.xx.xx:8443      xx.xx.xx.xx:48940      CLOSE_WAIT  -                   
tcp      249      0 xx.xx.xx.xx:8443      xx.xx.xx.xx:53340      CLOSE_WAIT  -                   
tcp      249      0 xx.xx.xx.xx:8443      xx.xx.xx.xx:34974      CLOSE_WAIT  -                   
tcp      249      0 xx.xx.xx.xx:8443      xx.xx.xx.xx:56474      CLOSE_WAIT  -                   
tcp      235      0 xx.xx.xx.xx:8443      xx.xx.xx.xx:33166      CLOSE_WAIT  -                   
tcp      518      0 xx.xx.xx.xx:8443      xx.xx.xx.xx:37982      CLOSE_WAIT  -                   
tcp      249      0 xx.xx.xx.xx:8443      xx.xx.xx.xx:55218      CLOSE_WAIT  -                   
tcp      249      0 xx.xx.xx.xx:8443      xx.xx.xx.xx:47696      CLOSE_WAIT  -                   
tcp        0      0 xx.xx.xx.xx:8443      xx.xx.xx.xx:35262      CLOSE_WAIT  -                   
tcp      249      0 xx.xx.xx.xx:8443      xx.xx.xx.xx:57052      CLOSE_WAIT  -                   
tcp      249      0 xx.xx.xx.xx:8443      xx.xx.xx.xx:33758      CLOSE_WAIT  -                   
tcp      249      0 xx.xx.xx.xx:8443      xx.xx.xx.xx:47770      CLOSE_WAIT  -                   
tcp      249      0 xx.xx.xx.xx:8443      xx.xx.xx.xx:50230      CLOSE_WAIT  -                   
tcp      530      0 xx.xx.xx.xx:8443      xx.xx.xx.xx:35582      CLOSE_WAIT  -                   
tcp        0      0 xx.xx.xx.xx:8443      xx.xx.xx.xx:44398      CLOSE_WAIT  -                   
tcp      241      0 xx.xx.xx.xx:8443      xx.xx.xx.xx:44268      CLOSE_WAIT  -                   
tcp      249      0 xx.xx.xx.xx:8443      xx.xx.xx.xx:43430      CLOSE_WAIT  -                    

 

 

Resolution

Revert the version to Java 11.0.17:

1. Stop Wildlfly

systemctl stop wildfly

2. Revert to Java 11.0.17

   a) To show the available packages:

       yum search --showduplicates java-11-openjdk

   b) Example of installing JDK 11.0.17.0.8-2.el7_9:

       yum install java-11-openjdk-11.0.17.0.8-2.el7_9.x86_64

      NOTE: any version of java-11-openjdk-11.0.17.0.8 can be used, if e17 is not in your search results. E.G. java-11-openjdk-11.0.17.0.8-2.xxxxx.x86_64

3. Verify the correct version is selected

alternatives --config java

4. Start Wildfly

systemctl start wildfly


Please Note:  The above steps may be slightly different depending on the version of Linux you have installed.

  • Engineering is working on incorporating WIldfly 22.2.5+ into the VNA Base installation which will remedy this issue.
  • As of VNA 22.2.11 GA Release, this is not yet included.

 

Additional Information

this issue is fixed in VNA 23.3.3 +