nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Community
- Command Central
- MVP Program
- Monthly Mission
- Blogs
- Groups
- Events
- Media Vault
Products
- Observability
- Network Management
- Application Management
- IT Security
- IT Service Management
- System Management
- Database Management
Content Exchange
- SolarWinds Platform
- Server & Application Monitor
- Database Performance Analyzer
- Server Configuration Monitor
- Network Performance Monitor
- Network Configuration Manager
- SQL Sentry
- Web Help Desk
Free Tools & Trials
Store

v7.2 False Positives

kanned

I recently upgraded from 7.1.15 to 7.2. After this upgrade I continued to get a large number of false positives from Solarwinds. I changed the ICMP timeout to 5000 and byte size to 0, hoping this would solve my problem. It did not. I then changed the Polling rate to 5 minutes. This still resulted in a large number of false node down events.

Is anyone else experiencing these issues?

I have since rolled back to 7.1 and everything seems fine as before. I guess I'll wait a little longer next time before upgrading.

Joshua E. Morehouse
Senior Network Engineer
Friedman, Billings, Ramsey Group, Inc.
"Capital For Your Conquest"
jmorehouse@fbr.com

Find more posts tagged with

Accepted answers

All comments

pancamo

Another discovery: Packet loss on the same subnet gradually get worse each day. After going to 98% PL on the DG cisco 3750, we restarted the solarwinds and SQLserver services and the packet loss is now back down to 0%...

quote:Originally posted by kanned

I recently upgraded from 7.1.15 to 7.2. After this upgrade I continued to get a large number of false positives from Solarwinds. I changed the ICMP timeout to 5000 and byte size to 0, hoping this would solve my problem. It did not. I then changed the Polling rate to 5 minutes. This still resulted in a large number of false node down events.

Is anyone else experiencing these issues?

I have since rolled back to 7.1 and everything seems fine as before. I guess I'll wait a little longer next time before upgrading.

Joshua E. Morehouse
Senior Network Engineer
Friedman, Billings, Ramsey Group, Inc.
"Capital For Your Conquest"
jmorehouse@fbr.com

keist

What all of you should do is verify the packet loss by using a sniffer and using the debug log of orion, tech support can help you turn on the debug, Also i had the problem about 8 months ago and it turned out to be our cisco 6509 code had a bug in it, since orion sends only one ping packet initially if that gets lost then you see the 10% packet loss, even to this day i have some devices report packet loss of 10% then it goes away. What we discovered was that we use a program called altaris for pushing patch updates on workstations and the manager of that system was trying to use wake on lan. this wake on lan feature had a bug that would flood the network with broadcasts from multiple machines on the network simultaniously since a broadcast is serviced by the route processor and not fast switched our 6509 have a max rating of like 20,000 packets a sec on the supervisor engine, when these machines would broadcast at the same time it would create 50,000+ packets/sec thus causing input queue drops on vlans, thus causing a missed ping. this is not limited to altaris other mis-behaving applications could cause the same issue. everytime we have looked into the 10% packet loss thing we verified that in fact that orion was sending the first ping to the device however the response never got back to orion server. Hope this will help i have spent many hours troubleshooting my issues.

Dan

pancamo

This packet loss I and many of the posts from here are with devices that are on the same subnet as the solarwinds server.

I have the packet captures, and the ICMP packets are not leaving the solarwinds box for the local subnet devices. Restarting the solarwinds service resolves the issue for some time, however after a few hours/days the packet loss returns. The packet loss has been as high at 98% on the local subnet devices, however I know that this is not the case since no packets are leaving the solarwinds box to these local subnet devices(Win2K servers and a Cisco 3750)

Can someone post the instruction on how to turn on the debug. I talked to support, and it seems like they don't have the time(always rushing to get off the phone) to walk us through the issue, and simply want provide support via email...

quote:Originally posted by keist

What all of you should do is verify the packet loss by using a sniffer and using the debug log of orion, tech support can help you turn on the debug, Also i had the problem about 8 months ago and it turned out to be our cisco 6509 code had a bug in it, since orion sends only one ping packet initially if that gets lost then you see the 10% packet loss, even to this day i have some devices report packet loss of 10% then it goes away. What we discovered was that we use a program called altaris for pushing patch updates on workstations and the manager of that system was trying to use wake on lan. this wake on lan feature had a bug that would flood the network with broadcasts from multiple machines on the network simultaniously since a broadcast is serviced by the route processor and not fast switched our 6509 have a max rating of like 20,000 packets a sec on the supervisor engine, when these machines would broadcast at the same time it would create 50,000+ packets/sec thus causing input queue drops on vlans, thus causing a missed ping. this is not limited to altaris other mis-behaving applications could cause the same issue. everytime we have looked into the 10% packet loss thing we verified that in fact that orion was sending the first ping to the device however the response never got back to orion server. Hope this will help i have spent many hours troubleshooting my issues.

Dan

toko

Ok, how do you remove warning events as an alert. I can't seem to get rid of them.

Haley

To turn on Debugging, perform the following steps:
1. From a command line, type regedit.
2. Move to the HKEY_LOCAL_MACHINE->SOFTWARE->SolarWinds.Net->SWNetPerfMon->Settings folder.
3. Add a new string called Debug Polling.
4. Give the string the value of True.
5. Restart the SolarWinds Network Performance Monitor service.
6. Refer to the ..\Program Files\SolarWinds\Network Performance Monitor V7\PollDebug.txt file.

Josh_Stephens

There is a Beta Release of the Orion NPM SLX Version 7.3 at:

ftp.solarwinds.net/.../SolarWinds-NetPerfMon-V7-SLX.exe

Version 7.3 includes changes that should minimize the false positives that you are seeing.

Please send any feedback on this beta release to support@solarwinds.net

pancamo

Are 7.3 release notes available?

quote:Originally posted by josh@solarwinds.net

There is a Beta Release of the Orion NPM SLX Version 7.3 at:

ftp.solarwinds.net/.../SolarWinds-NetPerfMon-V7-SLX.exe

Version 7.3 includes changes that should minimize the false positives that you are seeing.

Please send any feedback on this beta release to support@solarwinds.net

pancamo

From 20-40% to 0% packet loss on same-subnet nodes since upgrading to the 7.3 Beta!!!!!!

Great job! Finally looks like a real fix!

Now we have a LSASS high CPU problem...

quote:Originally posted by josh@solarwinds.net

There is a Beta Release of the Orion NPM SLX Version 7.3 at:

ftp.solarwinds.net/.../SolarWinds-NetPerfMon-V7-SLX.exe

Version 7.3 includes changes that should minimize the false positives that you are seeing.

Please send any feedback on this beta release to support@solarwinds.net

Network_Guru

pancamo,

The LSASS is usually caused by quitting your RDP session to the server without
first closing NetPerfMon Manger (SysManager). Restarting the polling service will
bring LSASS back under control. Apparently it is a Microsoft bug.

Is this the same issue you are having, or is this something different?

-=Cheers=-
NG

pancamo

This sounds like the problem... So we need to quit NetPerfMon Manger before killing the TS.... thanks!

and restarting the SW service does clear the problem...

d

quote:Originally posted by Network_Guru

pancamo,

The LSASS is usually caused by quitting your RDP session to the server without
first closing NetPerfMon Manger (SysManager). Restarting the polling service will
bring LSASS back under control. Apparently it is a Microsoft bug.

Is this the same issue you are having, or is this something different?

-=Cheers=-
NG

Debbi

I would like to know exactly what was changed to minimize the false positives. -Debbi

quote:Originally posted by josh@solarwinds.net

There is a Beta Release of the Orion NPM SLX Version 7.3 at:

ftp.solarwinds.net/.../SolarWinds-NetPerfMon-V7-SLX.exe

Version 7.3 includes changes that should minimize the false positives that you are seeing.

Please send any feedback on this beta release to support@solarwinds.net

ggardner1

I am still seeing frequent packet loss statistics on only one of my sites. When I keep a running manual ping to the router in question, i get 0% packet loss, but Orion keeps reporting 40%+

Has everyone elses problems with this gone away?