There isn't a monitor specifically for monitoring modules like this within WUG.  However, there may be other ways to accomplish this.  One thought that comes to mind would be to use SNMP traps.  Not sure if the device supports it or not, but I would think that it could send out a trap when the module went bad.  You could use WUG to watch for events like this and then get notification that a problem has arised.

Thanks for the responses.

I am wondering more about my 4507 and 6506 VSS switches.  But with this information I am at least partially there.

Jason - I looked up the MIB library, and thought I saw something there, but I don't know how to get that particular trap into the monitor.  Can you explain?

I will look into it.  Thank you!

Looks like I have some other SNMP configuration to do on these switches first.  How can I get WUG to rediscover my existing devices, but just with updated information?

So, that didn't get me all of my Active Monitors available to me (interfaces, fan, etc on the switch) but if I do a discover, it finds all the correct snmp objects to monitor.

Why the difference?  Do I need to reimport and set everything else up again?

If you ran discovery again, you don't have to start over, reimporting will simply update the existing device in the database with the newly dicsovered information.

Not sure why there is a difference, the rescan option should have found all of those monitors for you.

I need more help with this than the Help screen is providing.  I have not worked with this at all.  Are there STEP-BY-STEP procedures for SNMP trap setups?  For example, I looked in the \data\mibs folder and I actually saw the mib responsible for these type of traps, but it doesn't make sense why I am not getting them.  This is quite frustrating.  :(

What do these interfaces mean?  Perhaps StackPort1 means the entire switch, and StackSub-St1-1 means port 1 of the switch stack cables?

If your stack is connected in a ring (as recommended by Cisco) you just need to monitor the StackSub interfaces. If one interface goes DOWN you get an alert from WhatsUp (if configured). If a module fails, two StackSub interfaces will go DOWN and you will know which module has failed because of the two DOWN interfaces.

To get SNMP traps from the switch it is not only necessary to set up a trap listener in WhatsUp, you also have to tell the switch to send SNMP traps to the WhatsUp server. You can accomplish this with the following IOS command:

snmp-server host 10.10.10.10 version 2c SNMPcommunity
snmp-server enable traps traptype

Replace

10.10.10.10 with the IP address of your WhatsUp server
SNMPcommunity with your SNMPv2 community string
traptype with the types of traps you want to get ("snmp-server enable traps ?" in config-mode to get a list)

Hope this helps.

Regards, Leonardo

Leonardo, it does help.  The Cisco side seems rather easy.  It's the listener side that's making me crazy...

OK, let's start at the beginning:

Seems that WUG isn't set up to monitor modules.  Something has to be added, which I guess is either a MIB or an OID.  Problem is, when I look in the data\mibs folder, the correct one is there...

According to Cisco the trap needs to be set up on WUG --

These traps are from the
ciscoEntityFRUControlMIB (.1.3.6.1.4.1.9.9.117).  You can download the
whole MIB from here:

 http://tools.cisco.com/Support/SNMP/do/BrowseMIB.do?local=en&step=2&mibName=CISCO-ENTITY-FRU-CONTROL-MIB

 The exact OIDs that is
sent as the trap is 1.3.6.1.4.1.9.9.117.2 which contains these varbinds:

 1 cefcModuleStatusChange

              
2 cefcPowerStatusChange

               
3 cefcFRUInserted

               
4 cefcFRURemoved

               
5 cefcUnrecognizedFRU

               
6 cefcFanTrayStatusChange

               
7 cefcPowerSupplyOutputChange

  See:

ftp://ftp.cisco.com/pub/mibs/traps/CISCO-ENTITY-FRU-CONTROL-MIB.traps

Please explain... I don't know what I'm doing here....  I need step by step instructions please.

Scott,

That OID isn't going to work for you, as it is not the exact OID of the actual traps.  Take a look at the Traps screenshot attached.  Now if you want to monitor for all of those traps, you will need to create a passive monitor for each one.  The configuration screenshot shows what the configuration should look like, you will just need to adjust the last number in the OID for each of the different traps.

Jason,

Thank you very much for the follow up.  I too did some follow up, with Cisco.  I opened a TAC case.

What you wrote here is very interesting but let's take a step back... Because there is some missing information in how to do all of this.  Here are the steps we took, PLEASE correct me if I am wrong:

1.  Find the MIB you need - do a Google search for what you want to monitor and the type of device.

2.  Check the WUG \Data\Mibs folder to determine if the MIB is already in WUG.  If it's not, copy the MIB to the \Data\Mibs folder.  Then restart WUG's services.

3.  Go to Tools > Import Trap Definitions.  Find the OID name you are looking for.  (The OID is a number, you may be able to find the name associated with it. -- again Google it.)  Click on "Import to passive monitor library".

Now you can go into a device and add a passive monitor.

If you go into the Passive Monitor Library (click on Configure > Passive Monitor Library) and edit an SNMP Trap Passive Monitor Instance to make it more readable.

Then you can go into a device and add that specific Passive Monitor and send some kind of notification if that event occurs.

*******

Now if that is more or less correct, I have a question about what you sent me--

Why is yours correct and mine not?  They are in the same tree structure.

More importantly, how did you find and CHOOSE this one??

Scott,

Your method is absolutely correct, and using the Import Trap Definitions tool is a much easier way to get the passive monitors created, but much harder to try and explain.  As for how I found the trap, I simply used the OID that you provided and using the MIB walker within the passive monitor creator, I was able to locate the trap definitions that you have been talking about.

Ok, so I think you have the passive monitors created correctely.  Have you assigned them to the device or devices?

Jason, I have, but I have no way of testing it yet, unless i pull a module out of a production box -- ummm... I'll pass right now... :-)

And..... you didn't answer how you know that yours is correct and mine isn't... 

I also like the idea of being able to rename the Trap Definition to something easier.

How do you get to the MIB Walker?

What would cause the model field to be empty on just one switch?  All other SNMP fields are working...

We are both correct, but without a way to test it we won't know for sure.  Using the trap definitions utility takes the manual process of what I explained out.  The end result is the same regardless of which way the passive monitor was created.

As for the MIB walker, if you take a look at the configuration screen shot above, you will see the browse button next to the OID field.  This is where you can navigate through the installed MIBs on the WUG machine.  Note that the lightning bolt icon indicates a trap.

Wait, are you saying both OIDs are correct?

If you used the Trap Definitions tool, then they should be the same.  The original OID that you posted was the route level and not the actual Trap OIDs.

As for the missing SNMP information, where did this device come from a WhatsConnected discovery or a WUG discovery?  What happens if you rediscover the device?  You can see the device info from the discover window and should be able to tell if the missing data is there or not.

WUG discovery.  I am actually having to delete EVERY device I am rescanning with SNMP in order to get them in correctly.  Updating doesn't do it... :(

Not sure if that is a bug or a feature request - either way, that should be changed.  You could manually enter the information though instead of deleting the devices.

I have this same issue, but with Cisco 2960s - FlexStack switches.  I also agree that a small how-to document or video should be created to help demonstrate the best practice approach to monitoring Stacked switches.  These switches will become, if they haven't already, the industry standard.

In a perfect world, an Active Monitor not reliant on SNMP would be preferred.  In testing, if the master switch goes down, no SNMP trap was sent (or at least not one for the OID I was monitoring).  Resulting in the need to not only watch for the SNMP Trap, you also have to monitor the management IP Address so you know if the Master Switch has failed.

This doesn't make sense. In a stack when the master switch goes down, another switch will take over. So the management IP address should always be UP, as long as at least one switch of the stack is online (haven't tested that with 2960 switches).

Besides that you'll need SNMP to monitor the switch. The only other method would be to create a scripted telnet monitor which would be a rather complicated task... With SNMP you just need to poll the OID of the stack-interfaces (which should never change) regarless if switch members go down.