New Question
 
 
PRTG Network Monitor

Intuitive to Use.
Easy to manage.

200.000 administrators have chosen PRTG to monitor their network. Find out how you can reduce cost, increase QoS and ease planning, as well.

Free PRTG
Download >>

 

What is this?

This knowledgebase contains questions and answers about PRTG Network Monitor and network monitoring in general. You are invited to get involved by asking and answering questions!

Learn more

 

Top Tags


View all Tags


How can I get PRTG to recognize Cisco switches in stack that utilize only 1 IP address?

Votes:

0

Your Vote:

Up

Down

We have multiple stacks of Cisco 2960 switches across campus that we would like to be monitored in PRTG. The problem is that only the top switch has an IP address. In a stack of 3 switches, only the top switch is being monitored as far as we can see. Is there a way for PRTG to recognize the other 2 switches that reside in the stack?

cisco-2960 devicetemplate paetemplate prtg stack

Created on Sep 12, 2012 3:54:14 PM by  verizonengr (0) 1

Last change on Aug 10, 2017 8:23:49 AM by  Luciano Lingnau [Paessler Support]



Best Answer

Accepted Answer

Votes:

7

Your Vote:

Up

Down

This article applies to PRTG Network Monitor 16.3.25 or later

Monitoring the status of Cisco switches in a Stack

You can easily monitor a stack of Cisco Switches/devices using the device template below.

This device template can be used to automate the deployment of these sensors using auto-discovery. The sensors will report the Stack Unit's status according to the provided lookup file.

Adding Custom Sensors using the Auto-Discovery + Template

You can use the device template that we provide below to automatically create custom sensors with the PRTG auto-discovery.

The metrics that are available can vary. The sensors can monitor the following if the data is available:

  • Stack Unit
    • State
    • Role

The device template creates the available and compatible sensors based on the data at hand. The sensors implement default alerts whenever possible, but you can still fine-tune most channels by defining additional limits in the sensor channels settings or modifying the lookups included by default.

Requirements

  • PRTG Network Monitor 16.3.25 or later
  • Because the device template relies on the auto-discovery process, the device you want to monitor needs to be reachable via PING.
  • SNMP must be enabled and the device must support the CISCO-STACKWISE-MIB.

Known Issues and Limitations

  • PRTG shows some of the alerts as reported by the monitored device via SNMP using lookups. If the status is not reported correctly via SNMP, PRTG cannot detect any issues. For additional alerts, please set up limits for additional channels.
  • This device template was created based on data collected from other customers, so we cannot guarantee that the sensors described above will work on your systems or that the default thresholds are optimal for your use case. Use these components at your own risk. Please test and validate the sensors in your environment after deploying them.

Deployment and Usage

  1. Download the required zip archive containing the template's files here.
  2. Extract the archive to your PRTG program directory. By default, this is %Program Files (x86)%\PRTG Network Monitor\.
  3. In PRTG, restart the core server: open Setup | System Administration | Administrative Tools | Restart Core Server and click Go!. This ensures that the MIB and lookups are loaded before you run the auto-discovery.
  4. Create a new device in PRTG with the address (IP or FQDN) of the device that you want to monitor and configure the SNMP credentials accordingly.
  5. Right-click your new device, select Run Auto Discovery with Template, browse for stack and select the Custom Cisco Stack v0.x template from the list.
    Note: Using the auto-discovery with a dedicated device template is convenient here because it automates the creation of the custom sensors in an organized fashion.
  6. The sensors are deployed after a couple of seconds.
  7. You can adjust the channel limits or lookups to your needs later.

Result

The resulting sensors look like this:

Sensor's Overview

Virtual Drive

Click for full-screen view

No sensors deployed? :(
Please read ahead for troubleshooting.


Troubleshooting

Have any issues? Please don't hesitate to contact us by replying to this post or via a support ticket. Please make sure to mention this KB post. Please read ahead for troubleshooting steps that you can take in advance.

Auto-Discovery Log

Your auto-discovery log tells you a lot about what went wrong during the sensor's deployment. You can troubleshoot the auto-discovery by inspecting the auto-discovery log. If you get entries like the one below (NOT FOUND), it means that the required protocol or Object Identifier (OID) is not available and the sensors can't be deployed.

[...]
21.08.2017 09:17:17: Template Loaded; Device ID: 22848; Name: Custom Cisco Stack v0.1
21.08.2017 09:17:18: Template Check; Device ID: 22848; Check ID: ping; FOUND
21.08.2017 09:17:19: Template Check; Device ID: 22848; Check ID: snmp; FOUND
21.08.2017 09:17:20: Template Check; Device ID: 22848; Check ID: snmp_cswSwitchInfoTable; NOT FOUND
[...]

In the example above, some sensors were skipped because the device did not respond to the snmp_cswSwitchInfoTable check. This means that this data is probably not available on your device. You can track this data by looking for the name after snmp_. In this case, a search for cswSwitchInfoTable will tell you what OID from what MIB is missing.

You can also use this log to identify if the discovery was interrupted because the device did not respond to PING or to a basic SNMP check.

SNMP Data

If the discovery log is not sufficient, you can review the SNMP data directly from your device. To do so, save the text below (in the white box) as .txt and use it with the Scan Script option in our SNMP Tester. This will allow you to review which SNMP queries succeed and which do not deliver any data. Please have this information at hand when contacting our support team.

--------
Walk Default
--------
hrSystemUptime
walk=1.3.6.1.2.1.25.1.1
--------
MIB-2 System
walk=1.3.6.1.2.1.1
--------
Sensor Specific Queries
----
walk=1.3.6.1.4.1.9.9.500.1.2.1
---

Version History

VersionDescription
0.1Initial Release



Best Regards,
Luciano Lingnau [Paessler Support]

Created on Jun 3, 2016 2:39:29 PM by  Luciano Lingnau [Paessler Support]

Last change on Feb 15, 2018 2:00:35 PM by  Luciano Lingnau [Paessler Support]



10 Replies

Votes:

0

Your Vote:

Up

Down

What sensor type are you using, please?

Created on Sep 20, 2012 12:32:58 PM by  Patrick Hutter [Paessler Support] (7,094) 3 3



Votes:

0

Your Vote:

Up

Down

Did you ever work out how to do this? I'm faced with the same problem with multiple stacks of 3750x switches. I can monitor the overall stack health but have no idea about the health of individual stack members.

How do you do it?

Created on May 29, 2014 6:47:33 AM by  jb (0)



Votes:

0

Your Vote:

Up

Down

I'm sorry, it is necessary that the individual stacks have individual IPs, for them to be monitorable with PRTG.

Created on May 29, 2014 11:06:04 AM by  Torsten Lindner [Paessler Support]



Votes:

0

Your Vote:

Up

Down

It is not possible for each physical switch in the stack to have an individual IP address. The whole idea of the stack is you manage it as one logical unit.

Sorry but this is a major problem with PRTG monitoring a Cisco switch stack. You can have up to 9 physical switches in a stack (3750's) and with the current setup we have no idea if any one of those physical switches has failed, let alone any of the hardware monitoring suck as power supplies, temperature, cpu, memory etc.

Could you please investigate and add this as a new sensor type?

The only way I can do it now is to put a sensor on a port on the switch, such as a port to a server, and monitor if that is up or down.

Thanks Jon

Created on Jun 9, 2014 10:35:06 AM by  jb (0)



Votes:

0

Your Vote:

Up

Down

We understand this, but 'm very sorry, but in the moment, the sensors in PRTG cannot identify individual switches in a stack. We do have this in our wishlist. Please bear with us.

Created on Jun 9, 2014 12:36:24 PM by  Torsten Lindner [Paessler Support]

Last change on Jun 9, 2014 12:36:42 PM by  Torsten Lindner [Paessler Support]



Votes:

0

Your Vote:

Up

Down

Are there any updates on this please? I've just noticed the following sensor types that I don't recall seeing before: "StackPort1" and "StackSub-St1-1" and "StackSub-St1-2" which I believe to be the physical stack ports on the individual switches. I will monitor these and test next chance I get to pull a stack cable on a production switch stack.

Not the simplest or most straightforward way of monitoring, but at least it should alert me if one switch is down or the stack ring is broken.

Created on Jul 27, 2014 11:34:45 PM by  jb (0)



Votes:

0

Your Vote:

Up

Down

There should have been no changes to the support of stacked switches so far I'm afraid. Presumably the "Stack..."-Sensors there are SNMP Traffic Sensors? Those are just added according to the list of interfaces the (stacked) switch.

You could try importing the Cisco-Stack-MIB though with our MIB-Importer to monitor the target then with SNMP Library Sensors.

One thing though that could help us to look into this, would be a SNMP Walk over 1.3.6.1 against the stacked switch from SNMP Tester. Please be aware the walk will most likely run over some minutes (possibly 15 or more). Please then send us the result logfile via email to support@paessler.com

Created on Jul 28, 2014 1:55:46 PM by  Torsten Lindner [Paessler Support]

Last change on Aug 10, 2015 8:13:40 AM by  Luciano Lingnau [Paessler Support]



Votes:

9

Your Vote:

Up

Down

Use these OID´s values:

  • 1.3.6.1.4.1.9.9.500.1.2.1.1.1 (Number of devices of the stack)
  • 1.3.6.1.4.1.9.9.500.1.2.1.1.6 (Status of each device)

Monitor the stack with the values obtanied, for instance:

These are the resulting OID´s value of a snmpwalk that informs us that we have 3 switches in a stack :

iso.3.6.1.4.1.9.9.500.1.2.1.1.1.1001 = Gauge32: 1
iso.3.6.1.4.1.9.9.500.1.2.1.1.1.2001 = Gauge32: 2
iso.3.6.1.4.1.9.9.500.1.2.1.1.1.3001 = Gauge32: 3

With these values we can run a snmpwalk with 1.3.6.1.4.1.9.9.500.1.2.1.1.6, and we will obtain (for this case) these values:

iso.3.6.1.4.1.9.9.500.1.2.1.1.6.1001 = INTEGER: 4
iso.3.6.1.4.1.9.9.500.1.2.1.1.6.2001 = INTEGER: 4
iso.3.6.1.4.1.9.9.500.1.2.1.1.6.3001 = INTEGER: 4

PRTG will show you this value. The value=4, represents a Ready value for each member of the stack.

Here you can obtain more information about every value obtained:

1waiting
2progressing
3added
4ready
5sdmMismatch
6verMismatch
7featureMismatch
8newMasterInit
9provisioned
10invalid
11removed

For more details from Cisco's documentation:
tools.cisco.com: SNMP Object Navigator

Admin Edit/Add by Luciano Lingnau [Paessler Support]:

It is possible to create a Lookup File based on the table above so that PRTG can provide you status mapping for each status (Ex.: 4 = OK, everything else would be Warning or Error). Create one SNMP Custom Sensor for each stack member, assign the lookupfile and that should provide comprehensive stack status monitoring.

Ps.: Thank you novolyus for the excellent post.

Created on Aug 28, 2014 2:21:34 PM by  novolyus (90) 1

Last change on Aug 10, 2015 8:08:47 AM by  Luciano Lingnau [Paessler Support]



Accepted Answer

Votes:

7

Your Vote:

Up

Down

This article applies to PRTG Network Monitor 16.3.25 or later

Monitoring the status of Cisco switches in a Stack

You can easily monitor a stack of Cisco Switches/devices using the device template below.

This device template can be used to automate the deployment of these sensors using auto-discovery. The sensors will report the Stack Unit's status according to the provided lookup file.

Adding Custom Sensors using the Auto-Discovery + Template

You can use the device template that we provide below to automatically create custom sensors with the PRTG auto-discovery.

The metrics that are available can vary. The sensors can monitor the following if the data is available:

  • Stack Unit
    • State
    • Role

The device template creates the available and compatible sensors based on the data at hand. The sensors implement default alerts whenever possible, but you can still fine-tune most channels by defining additional limits in the sensor channels settings or modifying the lookups included by default.

Requirements

  • PRTG Network Monitor 16.3.25 or later
  • Because the device template relies on the auto-discovery process, the device you want to monitor needs to be reachable via PING.
  • SNMP must be enabled and the device must support the CISCO-STACKWISE-MIB.

Known Issues and Limitations

  • PRTG shows some of the alerts as reported by the monitored device via SNMP using lookups. If the status is not reported correctly via SNMP, PRTG cannot detect any issues. For additional alerts, please set up limits for additional channels.
  • This device template was created based on data collected from other customers, so we cannot guarantee that the sensors described above will work on your systems or that the default thresholds are optimal for your use case. Use these components at your own risk. Please test and validate the sensors in your environment after deploying them.

Deployment and Usage

  1. Download the required zip archive containing the template's files here.
  2. Extract the archive to your PRTG program directory. By default, this is %Program Files (x86)%\PRTG Network Monitor\.
  3. In PRTG, restart the core server: open Setup | System Administration | Administrative Tools | Restart Core Server and click Go!. This ensures that the MIB and lookups are loaded before you run the auto-discovery.
  4. Create a new device in PRTG with the address (IP or FQDN) of the device that you want to monitor and configure the SNMP credentials accordingly.
  5. Right-click your new device, select Run Auto Discovery with Template, browse for stack and select the Custom Cisco Stack v0.x template from the list.
    Note: Using the auto-discovery with a dedicated device template is convenient here because it automates the creation of the custom sensors in an organized fashion.
  6. The sensors are deployed after a couple of seconds.
  7. You can adjust the channel limits or lookups to your needs later.

Result

The resulting sensors look like this:

Sensor's Overview

Virtual Drive

Click for full-screen view

No sensors deployed? :(
Please read ahead for troubleshooting.


Troubleshooting

Have any issues? Please don't hesitate to contact us by replying to this post or via a support ticket. Please make sure to mention this KB post. Please read ahead for troubleshooting steps that you can take in advance.

Auto-Discovery Log

Your auto-discovery log tells you a lot about what went wrong during the sensor's deployment. You can troubleshoot the auto-discovery by inspecting the auto-discovery log. If you get entries like the one below (NOT FOUND), it means that the required protocol or Object Identifier (OID) is not available and the sensors can't be deployed.

[...]
21.08.2017 09:17:17: Template Loaded; Device ID: 22848; Name: Custom Cisco Stack v0.1
21.08.2017 09:17:18: Template Check; Device ID: 22848; Check ID: ping; FOUND
21.08.2017 09:17:19: Template Check; Device ID: 22848; Check ID: snmp; FOUND
21.08.2017 09:17:20: Template Check; Device ID: 22848; Check ID: snmp_cswSwitchInfoTable; NOT FOUND
[...]

In the example above, some sensors were skipped because the device did not respond to the snmp_cswSwitchInfoTable check. This means that this data is probably not available on your device. You can track this data by looking for the name after snmp_. In this case, a search for cswSwitchInfoTable will tell you what OID from what MIB is missing.

You can also use this log to identify if the discovery was interrupted because the device did not respond to PING or to a basic SNMP check.

SNMP Data

If the discovery log is not sufficient, you can review the SNMP data directly from your device. To do so, save the text below (in the white box) as .txt and use it with the Scan Script option in our SNMP Tester. This will allow you to review which SNMP queries succeed and which do not deliver any data. Please have this information at hand when contacting our support team.

--------
Walk Default
--------
hrSystemUptime
walk=1.3.6.1.2.1.25.1.1
--------
MIB-2 System
walk=1.3.6.1.2.1.1
--------
Sensor Specific Queries
----
walk=1.3.6.1.4.1.9.9.500.1.2.1
---

Version History

VersionDescription
0.1Initial Release



Best Regards,
Luciano Lingnau [Paessler Support]

Created on Jun 3, 2016 2:39:29 PM by  Luciano Lingnau [Paessler Support]

Last change on Feb 15, 2018 2:00:35 PM by  Luciano Lingnau [Paessler Support]



Votes:

0

Your Vote:

Up

Down

Compatibility with versions prior to 16.3.25

This template will cause the following error in older PRTG Versions:

Could not find a table row matching the index you specified when adding the sensor (1000). The value of the column you selected might have changed. (code: PE247)

To workaround the issue, download and copy the CISCO-STACKWISE-MIB.my to C:\Program Files (x86)\PRTG Network Monitor\MIB on your core server and restart the Core Server before performing the auto-discovery.

Created on Jun 13, 2016 10:47:50 AM by  Luciano Lingnau [Paessler Support]

Last change on Oct 7, 2016 7:35:22 AM by  Luciano Lingnau [Paessler Support]



Please log in or register to enter your reply.


Disclaimer: The information in the Paessler Knowledge Base comes without warranty of any kind. Use at your own risk. Before applying any instructions please exercise proper system administrator housekeeping. You must make sure that a proper backup of all your data is available.