cisco system health other sensor

Hi Yiannis,

Thank you for the post.

This error message occurs since the index of the required OIDs changed. However, we also had a bug in a old version of PRTG that triggered this error. Therefore, please follow these steps:

1. Update PRTG to the latest Version
2. (If the Sensors does not work again) Change the SNMP request mode to "Single Get" - This is defined in the corresponding device settings (under "SNMP Compatibility Options")
3. Recreate the Sensor

Best Regards,
Moritz Heller
Paessler Support Team

This has been broken on my Cisco 3850 switches since the PRTG version in stable release on 4/15/2019. After upgrade to 20.2.58.1629+ today and trying all the noted steps again (recreate sensor, switch to single get) this still does not work and I continue to get flapping PE269 errors.

Hey there,

• What scanning interval do you use?
• Is the iOS version up-to-date?

Kind regards,
Felix Saure, Tech Support Team

Any update on this issue we have have the same issue?

Hello there,

I'm afraid there is no update to this. We are still working on this issue. When there is a fix, you will find it in our release notes.

Kind regards

Felix Wiesneth - Team Tech Support

Hello Felix, We are also experiencing this issue on various CAT9K model switches/Wireless controller.

Cisco 9600, 9300 and 9800 series.

When is there going to be a fix?

Hello One,

May I ask for the PRTG version which you are using? If it's the latest version 21.3.69.1333+, also check if re-adding the sensor works properly for the new sensor.

Kind regards,
Felix Saure, Tech Support Team

Is this still a known issue? We are currently running 22.3.79.2108 x64 and are seeing this on devices being scanned on a remote probe. The Cisco devices themselves appear to be fine.

Hi there,

I'm afraid this is an ongoing issue. Occasionally the device does not send the data for all the queried OIDs, which then leads to the error listing the channels that did not received the data.

Kind regards

Felix Wiesneth - Team Tech Support

For everyone elses edification who have been battling this issue, I'll share my findings in my environment.

I've identified that the Cisco System Health Sensors do not honor the globally configured sensor settings for down condition. Although we have sensors configured to warn on first poll failure, Cisco SHS do not. This is a bug being worked on by Paessler.

The more interesting part is what I discovered with Netflow, seems when Cisco Prime Infrastructure runs backup on the device, either triggered by a network engineer making an ad hoc config change or scheduled backups, SSH backups appear to create a block condition on SNMP polling. I have a case open with Cisco TAC on this issue to determine if this is expected behavior. I have a very large and diverse environment gear wise so its basically every class of device that is manifesting this behavior during backup.

Effectively, if PRTG is polling during a SSH backup, the SSH block condition combined with the afore mentioned bug with the Cisco SHS, you're getting an immediate red flare in your monitoring environment...

Hi there,

Thank you for sharing your findings.

Kind regards

Felix Wiesneth - Team Tech Support

Just an update, on a 7 month long case with Cisco, seems Cisco Prime Infrastructure Inventory Collection is the actual culprit.

Troubleshoot Done and Analysis:

• On today's call, we got a more concise perspective of the issue, we found that the Error in PRTG is not caused by a configuration archive from Prime Infrastructure, instead it is caused by the regular inventory collection in some devices.

• The device is responding normally to the SNMP queries from PRTG tool, but. once we trigger the Inventory Collection from Prime Infrastructure it throws the PE269 error in PRTG

• From the debugs on the device, we can see requests and responses from the SNMP tools, however once the inventory collection is triggered from Prime Infrastructure, we stop seeing responses, and all we see are packets received:

• Once the inventory collection completes in Prime Infrastructure, the alarm in PRTG is cleared out, and the device again shows responses to the SNMP requests even in the debugs.

• We identified that some of the devices facing this behavior, are in "Partial Collection Status" in Prime Infrastructure, however this condition is not always true, as we identified some other devices with the Collection Status "Complete" and were also throwing the PE269 Error in PRTG.

Hello TJ,

Unfortunatly we do not use Prime. We also had a case with Cisco all the way up to the business unit and developers. Currently they stated the issue is in the software and requires development to fix. Let me check with our contact in the Business Unit of Cisco about the actual status.

TJ,

That information was extremely helpful

I do see a PRTG collection just as our PE269 codes start firing off.

What did you do to remediate

now that I know it's Prime causing the problem, I do not necessarily want to disable the PRTG alerts, but I also do not want to have Prime stop collecting.

Thank you, -Travis R.

Hello there,

This issue is still ongoing as we try to find the solution.

Kind regards,

Jeremiah Katatumba - Technical Support

After a full calendar year and 118 hours of troubleshooting with Cisco, seems we discovered a root cause in our environment today.

To recreate the PE269/SNMP 2003 errors I would initiate "Sync Device" from Cisco Prime Infrastructure, then persistently run a poll refresh (repeatedly from the GUI every second or so) from PRTG until the errors surfaced in PRTG.

On a Cisco 9k device manifesting the above issue, support had us enabled the SNMP mib flash cache in the switch configuration. After enabling the flash cache mib, the device no longer threw the PE269 errors during a PI Inventory, and coincidentally, resolved a partial inventory collection error in PI as well.

Hopefully this helps others with all the false positive firing in their environment

Hello there,

Thank you for the insightful finding after a considerable duration and for the heads-up.

We will internally take note of this.

Best regards,

Jeremiah Katatumba - Technical Support

Hello @TJ

Many thanks for your response to this case. As mentioned before we are not using Prime in our setups. Can you please let us know, either here or via PM what Cisco had you do on your end so we can test on ours.

We notice the issues mainly when in our setups where we either have a Stackwise Virtual or switch stack where the primary/active member fails or transfers its roles to the standy/slave.