3 Replies Latest reply on Feb 13, 2010 2:47 PM by epository

    RSD Sensor Throttle on DHCP

      I have recently added RSD 2.0 to our ePO 4.0 server. I'm starting fresh in an environment of anywhere between 2,000-4,000 different PC's. Our Active Directory OU's haven't been updated very well, so we have a lot of machines listed that may or may not exist.

      RSD looks promising to get this started correctly, so I installed RSD and installed a single sensor on the DHCP server. It picked up several subnets fine, but others it still has not after running nearly a week.

      Also, every 5 minutes or so the CPU on the DHCP server maxes out at 100% CPU. I double checked all of my ports for communication and they all match on the sensor policy and the ePO server.

      I read the support article indicating the CPU might top out when detecting new subnets initially, but it has been running nearly a week and is still topping out the CPU about every 5 minutes or so. When it isn't topping out, it sits idle usually around 2-3%. This was the normal behavior before installing the sensor. It also goes away when I disable or uninstall the sensor. I think the CPU topping out may be related to the below error, as that is the time set to communicate back to the ePO server.

      I checked the sensor log on the DHCP server and repeatedly get the below error message.

       

      11-12-08 16:22:26,165 [3812] INFO RSDSensor.ServerCom <> - Queueing host detection message for later transmission, due to sensor throttle.



      Has anyone seen this or have any ideas on what is going on?

      Thanks in advance!
        • 1. RE: RSD Sensor Throttle on DHCP
          Ok, so I thought I'd just start throwing sensors inside of subnets to push things along a bit while I'm trying to figure this other situation out, so I installed the sensor on my PC as a test for my subnet.

          I'm seeing the same spiking in CPU usage and receiving the same errors. The errors aren't nearly as large in number because I am in a small subnet, so I noticed a couple other notifications it was giving.

           

          [5404] INFO RSDSensor.ServerCom <> - The server returned HTTP status: 200



          I've tried doing some searching on that, but I can't seem to find what that exactly means.
          • 2. RE: RSD Sensor Throttle on DHCP
            Ok so apparently the 200 status means communication was ok.

            What does the sensor throttle message mean? Does anyone know?
            • 3. Re: RE: RSD Sensor Throttle on DHCP
              epository

              We saw entries like this on the RSD_out.log on all of our Rogue Sensors

               

              02-13-10 22:06:03,828 [3500] WARN RSDSensor.ServerCom <> - The sensor throttle period has expired, sending the retry queue.

               

               

              02-13-10 22:06:08,328 [3500] WARN RSDSensor.ServerCom <> -

              SocketException: Failed to resolve remote hostname XXX.XXX.xxx.xxx

               

              11004: The requested name is valid and was found in the database, but it does not have the correct associated data being resolved for.

               

               

              HTTP POST failed, adding the request to the retry queue.

               

               

              02-13-10 22:06:37,830 [5360] INFO RSDSensor.ServerCom <> - Queueing host detection message for later transmission, due to sensor throttle.

               

               

               

              Turned out the issue was that our reverse lookup entry in the DNS had been deleted.  After we fixed that, it was good.

               

              I tried  the command telnet xxx.xxx.10.99 8843 from my workstation to the ePo server and watched the HBSS firewall and saw it was accepting connections.

               

              I also noticed no other 8443 connections were coming in.  That's when I went to the RSD_out.log on a few of the RSD's we had and saw the above entry.

               

              Added in the reverse lookup to DNS and all of our sensors are now reporting in successfully.

               

              Now, why does it need the hostname when it has the IP????????